【转载】 ssh_exchange_identification: Connection closed by remote host

When using SSH this error may show it's ugly head on occasion. Many searches for the issues point to funny TCP connection tweaks or that sshd needs to be re-configured. This is not the case.

Symptoms

Connecting to SSH servers gives this message:

$ ssh atom@example.com
ssh_exchange_identification: Connection closed by remote host

Or maybe this if using verbose mode.

$ ssh -v atom@example.com
OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to example.com [10.65.0.2] port 22.
debug1: Connection established.
debug1: identity file /home/atom/.ssh/identity type -1
debug1: identity file /home/atom/.ssh/id_rsa type 1
debug1: identity file /home/atom/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host

Solutions

This can be caused by a number of issues, steps to test are as follows.

Check /etc/hosts.deny and /etc/hosts.allow

Many have reported configuring these to values properly has helped. However, we've seen this issue even when hosts.* files were not a factor.

root@host # grep sshd /etc/hosts.allow
sshd: ALL

Missing Dependencies

This one typically happens after a glibc or openssl upgrade. Many distros can install updates to glibc or openssl libs and not require a restart to sshd.

On any distro you can recognize it when after an update, then use lsof to see where sshd has open files. Some will be pointed to DEL, because those libs were deleted on update.

~ # lsof -n | grep ssh | grep DEL

When an SSH connection comes in the sshd daemon forks and attempts to attach (ld) these lib files, and fails resulting in this error.

Corrupted Fingerprint / Keys

Some how one or the other of the fingerprints or keys has become corrupted (did you manually edit one of these files?). Remove the server-side fingerprint in the clients ~/.ssh/known_hosts and try again. When you re-connect you will be prompted to accept the host identity again.

If you are able to access the machine another way you may want to back-out and re-create the server-side ~/.ssh/authorized_keys.

Along the same lines as this issue, if the files /etc/ssh/*key* are removed and sshd is not restarted then this error will show up too. Check for the key files in the sshd configuration directory.

Heavy Server Load

Have also seen this happen when server was under heavy load from for example, brute force attack. Increase the amount of connections sshd can run.

root@host # grep MaxStartups /etc/ssh/sshd_config
# Old Style
MaxStartups 12
# New Style
MaxStartups 10:20:30