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

Notes & Comments

The problem is not on the client end but on servers end, so removing or renaming the known_hosts file will not help./Irfan TOOR on 02 Feb 2010
This does not Always fix this problem. I'm running into this issue, during large numbers of parallel connections... still investigating./Geoff on 03 Feb 2010
Yeah, this doesn't work for me either. I am encountering it on Debian Lenny boxes on which I have apt-pinned a few packages from Squeeze. I'm beginning to think this is the cause, somehow./Brian on 06 Feb 2010
Look at the hosts.allow or hosts.deny/morphey on 02 Jun 2010
Also, this maybe caused by the files:
/etc/hosts.allow and /etc/hosts.deny/B!n@ry on 06 Jun 2010
On the server, modify "/etc/hosts.allow" to allow your daemons to accept connections.
"sshd: ALL: ALLOW" will allow connections from anywhere and anyone (provided they have the correct credentials)
See "man hosts.allow" for other patterns; there's a lot you can do with it (ex: only allow connections from the local network, etc.)./Chimo on 07 Jun 2010
i had problem with my permissions for /var/run was 777 which caused the error/grefel on 15 Apr 2010
This doesn't work, the first comment is correct/Philby John on 10 Feb 2010
Dont be dumb asses :P this error is because of the file /etc/hosts.allow, just correct this file and everything works/MV on 02 Mar 2010
In my case the problem was that /var/empty/sshd on the server was not owned by root (errant chown -R on my part). Stopping and attempting to restart the service enlightened:
"Starting sshd: /var/empty/sshd must be owned by root and not group or world-writable."/joe on 25 Jan 2012
on AIX 5.3, could be an out of resource problem (CPU, memory).. a boot will probably solve the problem (it solved on my box). Regards/barataaway on 01 Feb 2012
This error may appear if you have denyhosts in your system./Pablo on 23 Apr 2010
I found that (on the server) spamassassin had re-owned the "empty" folder; in my case /var/empty. sshd wants the empty folder to be owned by root. when I chown'd /var/empty to root, sshd NOW worked as I expected (no funny error re exchange_identification) and spamassassin didn't seem to mind either/Jim Pazarena on 06 May 2010
have the problem with an ubuntu server. only restarting the server seems to help (memory seems to be a problem). Still investigating/gunnar on 22 May 2010
Running the following on your ssh server will probably fix your problem:

echo "sshd:all" | sudo tee -a /etc/hosts.allow/jhalfmoon on 30 May 2010
/DNS lookup issue ? on 08 Jan 2011
I have several servers and several clients. I get also that message, but not for every client. I had possibility to remove all keys from one server and from the clients but the problem did not disappear. It seems that one server have started to reject some clients, but not all clients.

Some of the clients are identical embedded systems with identical settings. The only difference is the IP. When one embedded Linux was rejected, then also the other identical devices were rejected.

The rejected computers were my laptop and the embedded systems. Before this occasion I had changed the keys in my laptop and in the embedded systems and in the server. After this problem I removed all keys, but it did not fix the problem. After it a put new keys everywhere using a non-rejected computer, but the problem did not disappear.

So it seems when the host rejects some clients, the rejecting criteria is possible the computer name? And it possible starts to reject the client when it first time detects false keys? (The/Tron on 15 Feb 2010
I tried to open up multiple connections to host ,without waiting for any one to connect , on doing 'ps' i found that sshd had some entries with state as [net] and [priv] . after killing them i was able to connect to the host/dimrix on 22 Apr 2010
For me it was the host.allow/deny stuff. I was able to ssh in from all hosts by my PC. This is Cygwin to Cygwin, btw. SSH server running on a Windoze 2003 server. Pulled the plugs on the hosts.allow and deny and I'm it. If you HAVE to live in the Windoze world and don't have root or admin, cygwin is the way./Charles Stepp on 13 Feb 2012
This issue is also happen due to insufficient swap space on server so to overcome this issue need to bounce the server./rehan on 21 Mar 2012
On the server side, add this line to sshd_config to not require a DNS lookup on the incoming connection: useDNS no/Ron on 26 Mar 2012
The same error "ssh_exchange_identification: Connection closed by remote host" happens when private key files are readable by all, i.e. have the wrong permissions. For example if any of the private keys "ssh_host_key ssh_host_dsa_key ssh_host_rsa_key" in /etc/ssh/ are chmod 644 (should be chmod 600)./Jonas Jensen on 25 Apr 2012
I've had this problem a few days ago in several servers running different distributions all at the same time. After regenerating authorized_keys files the problem disappeared./Master of Digital Puppets on 13 Apr 2012
You saved my time.
This is good article if someone caught in such problem after tried so much options/Prashant Bhosale on 26 Apr 2012
All I did was restart my server and voila problem solved.../jake on 01 May 2012
Thank you very much for this concise, and correct, solution! I was banging my head against a wall, re-configuring over & over again ONE of my security measures, but totally forgot about /etc/hosts.allow. doh! :-P/captain on 05 May 2012

Add Comment or Note