SSH: 'Disconnected by remote host' error — causes and solutions

What Does the "Disconnected by remote host" Error Mean

The Connection closed by remote host (or Received disconnect from <IP> port 22:11: Bye Bye) error is a message from the SSH server that has intentionally terminated the established connection. The client (your local machine) receives this signal and ends the session. This is not always a failure; sometimes it's a normal action (e.g., shutting down sshd), but more often it's a sign of a problem with the server's configuration, network, or resources.

The message typically appears in the client console immediately after entering the password or after a period of inactivity.

Common Causes

1. Idle Timeout: The server terminates the connection after a period of inactivity (by default, in some distributions, this can be 5-10 minutes). The client sends no data, and the server considers the session dead.
2. Mismatched keepalive settings: The client and/or server are not configured to send periodic "keepalive" packets, which are used to detect a broken connection or maintain activity.
3. Authentication issues: Incorrect permissions on the server for ~/.ssh/authorized_keys (should be 600) or ~/.ssh (700). The server rejects the key and closes the connection.
4. Server overload or resource exhaustion: The server has hit process limits (MaxStartups), session limits, or memory limits (ulimit), and sshd forcibly closes new or existing connections.
5. Network problem or firewall trigger: An intermediate network device (router, corporate firewall) terminates an idle TCP connection after its own timeout. It may also be blocking (DROP) SSH packets.
6. Port or service conflict: Another daemon is already running on port 22 (or the custom SSH port) on the server, or sshd is being restarted (e.g., after a config update).
7. GSSAPI authentication issue: The GSSAPI mechanism, enabled by default in some OpenSSH versions, can cause delays and timeouts, leading to a disconnect.

Solutions

Method 1: Configure Client-Side Keepalive (Most Common & Simple)

This forces your SSH client to send empty packets periodically to "keep alive" the connection.

1. Open or create the client configuration file:

   nano ~/.ssh/config
   

2. Add a configuration block for the target host (or use Host * for all hosts):

   Host *
       ServerAliveInterval 60
       ServerAliveCountMax 3
   

   • ServerAliveInterval 60 — send a packet every 60 seconds.
   • ServerAliveCountMax 3 — if 3 consecutive packets receive no response, terminate the connection (total timeout ~3 minutes).
3. Save the file (Ctrl+O, Enter, Ctrl+X). Reconnect. This setting only applies to outgoing connections from your machine.

💡 Tip: If you connect to different servers with different policies, configure separate Host blocks for each.

Method 2: Configure Server-Side Keepalive

If you have administrative access to the server, modify its sshd configuration.

1. Connect to the server (you may need to use a console/control panel if SSH keeps failing).
2. Edit the main sshd config:

   sudo nano /etc/ssh/sshd_config
   

3. Find (or add) the parameters and set the values:

   ClientAliveInterval 60
   ClientAliveCountMax 3
   

   • ClientAliveInterval — the server will send a packet to the client every N seconds.
   • ClientAliveCountMax — the number of "keepalive" requests without a reply after which the server disconnects.
4. Restart the SSH service:

   sudo systemctl restart sshd
   

   ⚠️ Important: Do not close your current session until you've tested the new configuration! Open a second console to test.

Method 3: Check and Fix File Permissions on the Server

Incorrect permissions on ~/.ssh and authorized_keys are a frequent cause of an immediate disconnect after authentication.

On the server (for the user you are connecting as):

# Navigate to the target user's home directory
cd ~

# Set correct permissions
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

# Check the owner (should be the user, not root!)
ls -la .ssh/

If the owner is incorrect, fix it:

sudo chown -R <username>:<username> .ssh

Method 4: Network and Firewall Diagnostics

1. Check connection stability from the server to the client (or vice versa):

   ping -c 20 <server_ip>
   

   Look for packet loss. Even 1-2% can cause issues.
2. Check the route (traceroute) to identify nodes with high latency:

   traceroute <server_ip>
   

3. Check the firewall on the server (if you have access):

   # For firewalld (CentOS/RHEL/Fedora)
   sudo firewall-cmd --list-all
   
   # For ufw (Ubuntu/Debian)
   sudo ufw status verbose
   
   # For iptables (universal)
   sudo iptables -L -n -v
   

   Ensure the SSH port (default 22 or your custom port in sshd_config) is allowed for incoming connections (ACCEPT).
4. Check the firewall on the client (especially if you are on a corporate network). Outgoing traffic on port 22 might be blocked.

Method 5: Increase Server-Side Limits

If the server is under high load, the MaxStartups limit (maximum number of concurrent unauthenticated connections) might be triggered.

1. On the server, in /etc/ssh/sshd_config, find or add:

   MaxStartups 100:30:200
   

   • Format: initial:drop_percent:max. Example: allow 100 concurrent connections, start dropping 30% of new ones when reaching 150, hard limit 200.
2. Also check system limits (ulimit -n for file descriptors). Increase them in /etc/security/limits.conf if necessary and reboot the server.
3. Restart sshd:

   sudo systemctl restart sshd
   

Method 6: Disable GSSAPI (If It's the Culprit)

GSSAPI authentication (for Kerberos integration) can cause delays.

1. On the client in ~/.ssh/config, add for the problematic host:

   Host <server_alias_or_ip>
       GSSAPIAuthentication no
   

2. Or on the server in /etc/ssh/sshd_config:

   GSSAPIAuthentication no
   

   Then restart sshd.

Prevention

• Configure keepalive on both client and server (Methods 1 & 2) for all critical connections, especially over unstable networks.
• Regularly update OpenSSH (sudo apt update && sudo apt upgrade openssh-server on Debian/Ubuntu, sudo yum update openssh on RHEL/CentOS) for security and stability fixes.
• Monitor SSH logs (sudo journalctl -u sshd -f) when issues arise to see the cause immediately.
• Monitor server load (top, htop, free -h). Sudden spikes can lead to timeouts.
• Set permissions correctly (chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys) and ensure correct ownership (chown) for authentication files.