Fix SSH Connection Closed by Authenticating User (2026)

SSH’s Connection closed by authenticating user error means the client initiated a disconnect after authentication succeeded, but before the shell prompt appeared. The server saw the user log in, but then the user’s SSH client abruptly said "never mind."

Here are the common culprits:

1. Client-side ExitOnForwardFailure Setting:

• Diagnosis: Check your client’s ssh_config file (usually ~/.ssh/config or /etc/ssh/ssh_config). Look for ExitOnForwardFailure yes.
• Fix: Change ExitOnForwardFailure yes to ExitOnForwardFailure no in your client’s ssh_config.
• Why it works: If you have port forwarding configured (e.g., LocalForward or RemoteForward), and any of those forwarded ports fail to bind or connect, ExitOnForwardFailure yes will cause the SSH client to immediately terminate the connection. Setting it to no allows the SSH session to continue even if forwarding setup fails.

2. .bash_logout Script Execution:

• Diagnosis: Examine the user’s .bash_logout file on the server. If this file exists and contains commands that cause an immediate exit (like exit, kill, or calls to other scripts that exit), it will trigger the error.
• Fix: Temporarily rename or empty the .bash_logout file on the server for the affected user (e.g., mv ~/.bash_logout ~/.bash_logout.bak).
• Why it works: The .bash_logout script is executed by Bash after the user exits a login shell but before the SSH daemon fully disconnects. If this script terminates the shell prematurely, the SSH client sees the connection close unexpectedly.

3. .profile or .bash_profile Script Exiting Prematurely:

• Diagnosis: Inspect the user’s .profile or .bash_profile file on the server. Look for any commands that might cause an immediate exit or redirect the session in a way that terminates it. This is less common than .bash_logout but can happen.
• Fix: Comment out or remove any suspicious exit commands or script calls within .profile or .bash_profile on the server.
• Why it works: These initialization files are executed when a login shell starts. If they contain a command that forces an exit, the shell will close before the user can interact with it, leading to the "Connection closed" message.

4. ForceCommand in Server sshd_config with an Exiting Command:

• Diagnosis: Check the server’s /etc/ssh/sshd_config file for a ForceCommand directive. If it’s set to a command that immediately exits (e.g., ForceCommand /usr/bin/true or ForceCommand exit), this will cause the connection to close after authentication.
• Fix: Modify or remove the ForceCommand directive in /etc/ssh/sshd_config on the server. If you need to restrict commands, use a more sophisticated method like ForceCommand that invokes a specific shell or script that doesn’t exit immediately. For example, ForceCommand /usr/bin/rssh or ForceCommand /bin/bash.
• Why it works: ForceCommand overrides the user’s default shell and executes a specific command. If that command is designed to exit, the SSH session will terminate as soon as it’s run.

5. PAM Module Issues (e.g., pam_exec):

• Diagnosis: Examine the Pluggable Authentication Modules (PAM) configuration for SSH on the server, typically found in /etc/pam.d/sshd. Look for lines using pam_exec.so. If pam_exec.so is configured to run a script that exits, it can cause this. Check the script itself for exit commands.
• Fix: Comment out the problematic pam_exec.so line in /etc/pam.d/sshd or modify the executed script to not exit prematurely.
• Why it works: PAM modules are executed during the authentication process. If a PAM module, specifically pam_exec calling an external script, causes the session to terminate, the SSH client will report the connection closed.

6. Client-side PermitLocalCommand with a Shell:

• Diagnosis: On the client side, check ssh_config for PermitLocalCommand yes. If this is set, and your LocalCommand directive in ssh_config (or on the command line) is set to a command that exits immediately, it can cause the disconnect.
• Fix: Set PermitLocalCommand no in your client’s ssh_config or remove the LocalCommand directive if it’s not needed.
• Why it works: PermitLocalCommand yes allows the client to execute local commands during the SSH session. If such a command is executed and exits, the client might interpret this as a session termination signal.

7. Subsystem Configuration on Server:

• Diagnosis: Review the Subsystem directive in the server’s /etc/ssh/sshd_config. If the configured subsystem (e.g., sftp) is not properly set up or its executable path is incorrect, it might lead to an immediate disconnect upon attempting to start the session.
• Fix: Ensure the Subsystem directive points to a valid and executable path for the subsystem, typically /usr/lib/openssh/sftp-server or similar. Example: Subsystem sftp /usr/lib/openssh/sftp-server.
• Why it works: SSH uses subsystems for functionalities like SFTP. If the server cannot start the specified subsystem, it might close the connection rather than proceeding to a shell.

After addressing these, you might encounter channel_input_failed or broken pipe if the underlying network connection is unstable, but the Connection closed by authenticating user specific error should be resolved.