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.
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
This can be caused by a number of issues, steps to test are as follows.
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
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.
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.
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
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
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
