How to fix ssh_exchange_identification: Connection closed by remote host in SSH

Run your SSH command with maximum verbosity to see exactly where the connection is failing:

ssh -vvv user@hostname

Look for output like:
- 'debug1: Local version string: OpenSSH_X.X'
- 'debug1: Remote protocol version X.X, remote software version OpenSSH_X.X'
- 'debug1: match: OpenSSH_X.X'

If you don't see 'Remote protocol version', the server is closing before SSH negotiation completes.

Because this error appears before authentication, an automated ban is the single most common cause. If you have server access, check the Fail2ban status and the list of currently banned IPs:

# Show jail status, including the 'Banned IP list'
sudo fail2ban-client status sshd

On newer Fail2ban versions you can also list bans directly:

sudo fail2ban-client get sshd banned

If your IP appears in the list, unban it:

sudo fail2ban-client set sshd unbanip YOUR_IP_ADDRESS

If this is a repeated issue, ask your administrator to adjust Fail2ban sensitivity or whitelist your IP range via the ignoreip directive in /etc/fail2ban/jail.local.

Log into the server (or ask your administrator) and examine the TCP wrapper rules:

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

If you see lines like 'sshd: ALL' in hosts.deny or specific IP restrictions in hosts.allow, your IP may be blocked. Ask your administrator to add your IP to hosts.allow:

# Add to /etc/hosts.allow
sshd: YOUR_IP_ADDRESS
sshd: 192.168.1.0/24

Note: TCP wrapper support (libwrap) was removed from OpenSSH 6.7+, so these files only apply if your sshd was explicitly built with libwrap or another wrapped service is involved.

On the remote server, verify the SSH daemon is running:

sudo systemctl status sshd

Restart the SSH service to clear potential stuck connections:

sudo systemctl restart sshd

Examine SSH logs for clues:

# Debian/Ubuntu
sudo tail -f /var/log/auth.log

# RHEL/CentOS/Fedora
sudo tail -f /var/log/secure

# systemd journal (any distro)
sudo journalctl -u sshd -f

# Look for messages like:
# sshd[xxxx]: Connection closed by authenticating user
# sshd[xxxx]: fatal: setgroups: Cannot allocate memory
# sshd[xxxx]: error: beginning MaxStartups throttling
# sshd[xxxx]: Connection reset by peer

Examine /etc/ssh/sshd_config for overly restrictive settings:

sudo grep -E 'MaxStartups|MaxSessions|LoginGraceTime|UseDNS' /etc/ssh/sshd_config

If MaxStartups is too low (default is 10:30:100), increase it:

# Edit /etc/ssh/sshd_config
MaxStartups 30:30:100

Validate the configuration before applying it, then reload:

sudo sshd -t && sudo systemctl reload sshd

If DNS lookups are slow or failing, they can delay or drop incoming connections. Add this to /etc/ssh/sshd_config:

UseDNS no

Then validate and reload SSH:

sudo sshd -t && sudo systemctl reload sshd

The server might be out of memory or system resources, which can cause sshd to fail to fork new sessions. Check:

free -m          # Check available memory
df -h            # Check disk space
top -bn1 | head  # Check CPU and memory usage

If the server is low on resources, free up memory or disk space first. Then restart the SSH daemon:

sudo systemctl restart sshd

Missing or corrupted host keys can cause sshd to fail to start its protocol. Check whether they exist:

ls -la /etc/ssh/ssh_host_*

If they're missing or corrupted, regenerate them:

# Debian/Ubuntu
sudo dpkg-reconfigure openssh-server

# RHEL/CentOS/Fedora (generates any missing default host keys)
sudo ssh-keygen -A

Then restart SSH:

sudo systemctl restart sshd

Note: if a host key changed, clients will see a separate host-key-verification warning the next time they connect; that is expected after regeneration.