How to fix Connection closed by remote host in SSH

SSHINTERMEDIATEHIGHUpdated Jan 4, 2026· 295 views

This error occurs when the SSH server abruptly closes the connection during the protocol handshake, before authentication is completed. It typically indicates server-side configuration issues, resource constraints, or firewall restrictions rather than a networking connectivity problem.

Quick fix

Fixes Connection closed by remote host

ping -c 4 remote.example.com
telnet remote.example.com 22
  1. Verify basic network connectivity first
  2. Check TCP Wrapper restrictions on the server
  3. Increase MaxStartups if you're under load
  4. Check firewall rules on the server
ssh — error
ping -c 4 remote.example.com
telnet remote.example.com 22
Connection closed by remote host

What this error means

When SSH displays "Connection closed by remote host," the remote server has established the TCP connection but then terminated it during the SSH protocol exchange (before username/password authentication even begins). This differs from "Connection refused" or "Connection timed out"—those errors occur at the network layer, while this error happens after successful TCP handshake but during SSH negotiation. The server is actively rejecting the connection, often due to configuration restrictions, resource limits, or security policies on the server side.

Typical symptoms

  • SSH connection drops immediately with 'Connection closed by remote host' message
  • Error occurs before any password or key prompt appears
  • TCP handshake succeeds (you can ping the server) but SSH fails
  • Some clients can connect while others cannot (suggesting IP-based restrictions)
  • Problem began after server updates or configuration changes
  • Multiple rapid SSH attempts get blocked (MaxStartups triggered)

Common causes

  1. TCP Wrapper configuration (/etc/hosts.deny) blocking your IP or all SSH connections
  2. MaxStartups limit exceeded on the server (defaults to 10, easily hit with slow connections)
  3. SSH host keys corrupted or deleted on the server
  4. Server under heavy load or memory exhaustion preventing SSH daemon from handling connections
  5. Firewall rules on the server (iptables/firewalld) dropping SSH packets after initial handshake
  6. SSH daemon crashed, restarting, or hung from recent library updates (glibc, OpenSSL)
  7. SELinux or AppArmor policies blocking sshd from accepting connections
  8. Known_hosts file contains invalid or old fingerprint causing server rejection

How to fix "Connection closed by remote host"

1Verify basic network connectivity first

Before troubleshooting SSH specifically, confirm the server is reachable:

bash
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):

bash
ssh -v username@remote.example.com

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

2Check TCP Wrapper restrictions on the server

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

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

If /etc/hosts.deny contains:

bash
sshd: ALL

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

bash
sudo systemctl restart sshd

If your IP is specifically blocked, remove that line:

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

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

bash
sshd: ALL
3Increase MaxStartups if you're under load

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:

bash
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:

bash
sudo nano /etc/ssh/sshd_config

Change or add:

bash
MaxStartups 200:30:400

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

bash
sudo systemctl restart sshd
4Check firewall rules on the server

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

bash
# 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:

bash
sudo ufw allow 22/tcp
sudo systemctl restart ufw

For iptables, insert a rule allowing SSH:

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

For firewalld:

bash
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
5Regenerate SSH host keys if corrupted

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

bash
sudo ls -la /etc/ssh/ssh_host_*

If files are missing or corrupted, regenerate them:

bash
sudo ssh-keygen -A

Then restart the SSH daemon:

bash
sudo systemctl restart sshd

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

6Check server resources and restart sshd

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

bash
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:

bash
sudo systemctl restart sshd

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

bash
sudo systemctl kill sshd
sudo systemctl start sshd
7Check SELinux or AppArmor if present

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

bash
# SELinux
getenforce

# AppArmor
sudo aa-status | grep sshd

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

bash
sudo setenforce 0
# Try SSH again
sudo setenforce 1

If AppArmor is blocking sshd, check logs:

bash
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).

8Use verbose mode on client for detailed diagnostics

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

bash
ssh -vvv username@remote.example.com

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)

Advanced notes

Advanced troubleshooting:

Library Update Issues: After glibc or OpenSSL updates, the SSH daemon might not auto-reload the new libraries. A simple systemctl restart sshd forces the daemon to use the updated libraries. If that fails, try systemctl kill sshd && systemctl start sshd.

Network Path Issues: Rarely, intermediate routers or NAT devices may be dropping SSH packets after the 3-way handshake (especially if SSH negotiation is slow). This can happen on satellite links or very slow networks. Test with ssh -o ConnectTimeout=30 to allow more time for negotiation.

Custom SSH Ports: If SSH runs on a non-standard port (not 22), ensure your connection attempt specifies the correct port:

bash
ssh -p 2222 username@remote.example.com

Brute Force Protection: Some servers use tools like fail2ban or DDoS protection that may temporarily ban IPs after multiple failed SSH attempts. Check if your IP is banned:

bash
sudo fail2ban-client status sshd

If banned, wait for the ban to expire or ask an admin to manually unban the IP.

Frequently asked questions

What does "Connection closed by remote host" mean?
When SSH displays "Connection closed by remote host," the remote server has established the TCP connection but then terminated it during the SSH protocol exchange (before username/password authentication even begins). This differs from "Connection refused" or "Connection timed out"—those errors occur at the network layer, while this error happens after successful TCP handshake but during SSH negotiation. The server is actively rejecting the connection, often due to configuration restrictions, resource limits, or security policies on the server side.
How do I fix "Connection closed by remote host"?
This error occurs when the SSH server abruptly closes the connection during the protocol handshake, before authentication is completed. It typically indicates server-side configuration issues, resource constraints, or firewall restrictions rather than a networking connectivity problem.
What causes "Connection closed by remote host"?
TCP Wrapper configuration (/etc/hosts.deny) blocking your IP or all SSH connections MaxStartups limit exceeded on the server (defaults to 10, easily hit with slow connections) SSH host keys corrupted or deleted on the server
Is the "Connection closed by remote host" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading