How to fix Connection closed by remote host in SSH

Before troubleshooting SSH specifically, confirm the server is reachable:

ping -c 4 remote.example.com
telnet remote.example.com 22

If ping works but telnet fails to even reach port 22, the problem is likely a firewall blocking SSH entirely. If telnet connects and shows SSH banner, SSH daemon is running and the issue is within SSH negotiation.

You can also try from a different client machine (different IP):

ssh -v [email protected]

The -v flag shows verbose output of where exactly the connection closes.

The most common cause is /etc/hosts.deny blocking SSH. If you have direct server access (console, panel), check:

sudo cat /etc/hosts.deny
sudo cat /etc/hosts.allow

If /etc/hosts.deny contains:

sshd: ALL

This blocks all SSH connections. Remove this line and restart SSH:

sudo systemctl restart sshd

If your IP is specifically blocked, remove that line:

# Remove the blocking line, then:
sudo systemctl restart sshd

To allow SSH from all IPs, add to /etc/hosts.allow:

sshd: ALL

If multiple SSH connections are failing simultaneously (or you're attempting rapid reconnects), the server's MaxStartups limit may be exceeded. Check the current setting:

sudo grep MaxStartups /etc/ssh/sshd_config

Default is usually 10:100. This means max 10 unauthenticated connections, dropping all new ones at 100% capacity. To increase:

sudo nano /etc/ssh/sshd_config

Change or add:

MaxStartups 200:30:400

This allows 200 concurrent connections before any are dropped. Save and restart:

sudo systemctl restart sshd

Firewall rules might drop SSH packets after the TCP connection. Check your active firewall:

# For iptables
sudo iptables -L -n | grep ssh

# For ufw
sudo ufw status

# For firewalld
sudo firewall-cmd --list-all

Ensure SSH (port 22) is not in any DROP or REJECT rules. For ufw:

sudo ufw allow 22/tcp
sudo systemctl restart ufw

For iptables, insert a rule allowing SSH:

sudo iptables -I INPUT -p tcp --dport 22 -j ACCEPT
sudo systemctl restart iptables  # or save rules

For firewalld:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Corrupted SSH host keys can cause the server to reject all connections. Check if keys exist and are valid:

sudo ls -la /etc/ssh/ssh_host_*

If files are missing or corrupted, regenerate them:

sudo ssh-keygen -A

Then restart the SSH daemon:

sudo systemctl restart sshd

This regenerates all standard host key types (RSA, ECDSA, ED25519). The server will now show a new fingerprint to clients.

If the server is out of memory or disk space, SSH daemon may fail to handle new connections. Check:

df -h /          # Disk space
free -h           # Memory
top -n 1          # Process load

If memory is exhausted, kill non-critical processes or reboot. If disk is full, remove old logs/files.

Then restart the SSH daemon:

sudo systemctl restart sshd

If sshd is running but misbehaving, try force-restarting:

sudo systemctl kill sshd
sudo systemctl start sshd

If your server uses SELinux or AppArmor, policies might block SSH. Check status:

# SELinux
getenforce

# AppArmor
sudo aa-status | grep sshd

If SELinux is in Enforcing mode, temporarily set to Permissive to test:

sudo setenforce 0
# Try SSH again
sudo setenforce 1

If AppArmor is blocking sshd, check logs:

sudo tail -f /var/log/syslog | grep apparmor

For permanent fixes, consult your distribution's SELinux/AppArmor documentation, or disable enforcement (not recommended in production).

When troubleshooting, run SSH with verbose output to see exactly where the connection closes:

ssh -vvv [email protected]

Look for the last line before "Connection closed by remote host"—it will show what phase of negotiation failed (key exchange, algorithm negotiation, etc.).

Common verbose output clues:
- "Received disconnect message (code 3)" = server actively killed the connection
- "Disconnect message from ... [lang] ..." = message from server explaining why
- No further output = server silently closed connection (suggests firewall/DOS protection)