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
I received this error because /dev/null has become a regular file instead of a character device. I have absolutely no idea why this happended but I could log in again after deleting /dev/null and recreating it as a character device using mknod./tigaente on 21 May 2012
You will also recieve this message if the permissions of /var/log/btmp on the server are anything other than 600/Harsha on 05 Jun 2012
I also had this problem when I had the proxy settings incorrectly configured in the ~/.ssh/config file. I had specified the Host property by name to just one Host when it should have applied to several. This meant the ProxyCommand didn't apply./Matt Copperwaite on 08 Jun 2012
I got this error when there was a wrong configuration option in sshd_config. sshd from the command line worked, but not from inetd.conf./Kyle on 25 Jun 2012
For my instance of this error, it seems that the server is too overloaded or being restarted./Uriel on 24 Jun 2012
An other cause for this error is that something other than an ssh daemon is listening to the port you're trying to connect to.
For example if you ssh -p 80 www.google.com you'll get the same behaviour./Nick Demou on 04 Jul 2012
I confirm that :
1] Set /var/run/ssh in 755
2] Restart /etc/init.d/sshd (or restart the server)
worked for me.
Thanks a lot ! :)/Denis TRUFFAUT on 23 Jul 2012
This webpage solved my ssh problem - excellent!
thanks./Larry Wren on 31 Jul 2012
After a double check we found our own local IP at hosts.deny list./Rodrigo on 04 Aug 2012
denyhosts was the problem. In the process of screwing around with a completely unrelated network problem I convinced denyhosts that I was a bad guy, and it listed my local (192.168.1.15) address in hosts.deny./James Hofmann on 05 Aug 2012
My client keys were indeed messed up so deleting the appropriate fingerprint fixed it. Thanks!/Jon on 14 Sep 2012
My case was after doing "apt-get upgrade", caused by some important packages remain uninstalled ("The following packages have been kept back" message).
I manually installed these stalled updates and message dissapears. Luckyly i didn't close the SSH session./Mr. Mong. on 21 Sep 2012
Also happens when an over-zealous brute force dictionary attach against ssh happens. Check /var/log/auth.log or /var/log/secure. If you're seeing lots of connection attempts per second from the same hosts, you're under attack. If you're using a debian-style package manager, perform a 'sudo apt-get install -y fail2ban'. Should clear up once fail2ban is installed. Or block the IP at the firewall./Alec on 27 Sep 2012
make sure hosts.deny ends with a newline - if n ot everything will fail closed. This should be noted in /var/log/auth.log/john harper on 06 Oct 2012
On VMS, this can happen if the sys$manager:sylogin.com file doesn't have world:execute permissions. Running "set security sys$manager:sylogin.com/prot=(w:e)" resolves the problem./alwayslurking on 11 Oct 2012
missing a colon in my /etc/hosts.deny caused this issue for months./raijin on 16 Oct 2012
Restarting ssh daemon on client cleared the error. (service ssh restart)/bernpuc on 25 Oct 2012
Hello, i replaced my /etc/hosts.deny for a new one and it worked, in my case, i have denyhosts software installed which might have added an IP in the /etc/hosts.deny file wich restricts any acces from the network im working on right now./Ernesto Butto on 07 Jan 2013
In my case , it turned out permissions on /var/empty/sshd had somehow become 777 . sshd doesnt like group or other to have write . chmod go-rw made it ok again ./Maerlyn on 17 Jan 2013
I'll add another random thing to the long list of voices... my server recently got moved to another network, the gateway changed so after some reconfiguration it was all back with the exception of ssh which displayed symptoms above; keys accepted but the connection closed.
Turns out the gateway and search were not set correctly in /etc/resolv.conf - the settings still pointed to the wrong domain and DHCP gateway. Found via a single entry in the system log./spacey on 07 Feb 2013
thank you. /etc/hosts.deny was the problem for me. there are some entries in this file that i have not added (i am the only one with access to this machine). any idea what program might be adding these entries?
thanks again for the great help!
cheers!/charlee.papah on 16 Feb 2013
My trouble-maker was /etc/tcp.ssh which only allows certain IP address to SSH into the server./kmok1 on 26 Mar 2013
The message is from the client and happens because of a failure to exchange identities. This happens when the ssh server doesn't perform the first step. In my case, this was because it had never been installed. Ubuntu 12.04 LTS apparently doesn't come with an SSH server./Dave on 16 May 2013
portsentry modified /etc/hosts.deny (addingmy IP address) because it thought I was hacking into the site/Marlin Forbes on 17 May 2013
It was MaxStarts. Thanks!/Sean on 31 May 2013
You can also get this message (as I found out today) if you delete the sshd user either via userdel or by removing the sshd entry in /etc/passwd. Silly clients!/break/fix on 03 Jun 2013