The SSH server on the remote host unexpectedly terminated the connection, indicating a problem on that end rather than a network issue.

Common Causes and Fixes:

1. SSH Daemon Crashed or Restarted:

  • Diagnosis: Check the SSH daemon’s status on the server.
    sudo systemctl status sshd
    
    Look for recent restarts or error messages.
  • Fix: If the daemon is not running, start it.
    sudo systemctl start sshd
    
    If it crashed, investigate the logs (sudo journalctl -u sshd) for the root cause of the crash.
  • Why it works: The sshd process is responsible for handling incoming SSH connections. If it’s not running or has crashed, it cannot maintain the connection.

2. Excessive Resource Usage on the Server:

  • Diagnosis: Log into the server via another method (e.g., console, another SSH session if possible) and check system resource utilization.
    top -n 1 -o %CPU
    # or
    free -h
    
    Look for processes consuming high CPU or memory, or if the system is out of swap.
  • Fix: Identify and, if necessary, terminate or optimize the resource-hogging process. If memory is the issue, consider increasing server RAM or reducing the load.
  • Why it works: The SSH daemon, like any other process, can be killed by the operating system’s Out-Of-Memory (OOM) killer if the system is critically low on memory. High CPU can also lead to unresponsiveness and timeouts.

3. sshd_config File Errors or Changes:

  • Diagnosis: On the server, check the syntax of the sshd_config file.
    sudo sshd -t
    
    This command tests the configuration file for syntax errors. Also, review recent changes to /etc/ssh/sshd_config.
  • Fix: Correct any syntax errors found. If a recent change caused the issue, revert it or consult the sshd_config man page for correct syntax and options. For example, if MaxSessions was set too low and multiple clients were connecting, increasing it might be necessary:
    MaxSessions 10
    
    Then restart sshd:
    sudo systemctl restart sshd
    
  • Why it works: Incorrectly formatted configuration directives or restrictive settings can cause the sshd daemon to reject connections or terminate them prematurely.

4. UsePAM yes and PAM Module Issues:

  • Diagnosis: If UsePAM yes is set in /etc/ssh/sshd_config, issues with Pluggable Authentication Modules (PAM) can cause connections to drop. Check PAM logs, often found in /var/log/auth.log or via journalctl -f -u sshd.
  • Fix: Examine the PAM configuration files (e.g., /etc/pam.d/sshd) for errors or misconfigurations. Ensure all required PAM modules are installed and correctly configured. Sometimes, simply restarting sshd after PAM configuration changes is sufficient.
  • Why it works: PAM handles authentication and session management. If a PAM module fails or is misconfigured, it can prevent a successful session from being established, leading to the connection being closed.

5. Host Key Issues or Changes:

  • Diagnosis: If the server’s host key has changed since the client last connected, the client will typically warn about a potential man-in-the-middle attack and refuse to connect or disconnect. Check the client’s ~/.ssh/known_hosts file for the server’s entry. On the server, compare the key (sudo ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub) with what the client expects.
  • Fix: On the client, remove the old entry for the server from ~/.ssh/known_hosts.
    ssh-keygen -R your_server_ip_or_hostname
    
    Then, attempt to reconnect. The client will prompt you to accept the new host key.
  • Why it works: SSH uses host keys to verify the identity of the server. A change in the host key signals that the server’s identity might have changed, prompting security measures that disconnect the client.

6. Client-Side SSH Configuration (ssh_config):

  • Diagnosis: While the error states "Remote Host," sometimes client-side settings can indirectly cause this. Check your local ~/.ssh/config or /etc/ssh/ssh_config for aggressive timeouts or other settings that might be prematurely closing the connection from the client’s perspective, which the server might interpret as a disconnection.
  • Fix: Temporarily comment out or remove potentially problematic client-side settings like ServerAliveInterval or ConnectTimeout to see if the issue persists.
    # ServerAliveInterval 60
    # ConnectTimeout 5
    
  • Why it works: Settings like ServerAliveInterval send keep-alive messages. If these are misconfigured or if the server is unresponsive to them, the client might close the connection.

7. Firewall or Network Intrusion Detection System (IDS) Blocking:

  • Diagnosis: Although less likely to manifest as "Connection closed by remote host" (often it’s a timeout), a very aggressive firewall or IDS on the server’s network could be terminating the session if it deems activity suspicious. Check server-side firewall logs (iptables -L, ufw status verbose) and any IDS logs.
  • Fix: Adjust firewall rules or IDS policies to allow the SSH traffic (typically port 22). This might involve whitelisting specific IPs or protocols.
  • Why it works: Firewalls and IDSs act as security layers. If they detect traffic patterns that violate their security policies, they can actively terminate connections.

The next error you’ll likely encounter if all these are resolved is a prompt for your password or an authentication failure if your credentials are no longer valid.

Want structured learning?

Take the full Ssh course →