ssh_exchange_identification: Connection closed by remote host (not using hosts.deny)

Originally posted on Ask Ubuntu

If you have ruled out any "external" factors, the following set of steps usually helps to narrow it down. So while this doesn't directly answer your question, it may help tracking down the error cause.

Troubleshooting sshd

What I find generally very useful in any such cases is to start sshd without letting it daemonize. The problem in my case was that neither syslog nor auth.log showed anything meaningful.

When I started it from the terminal I got:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Much better! This error message allowed me to see what's wrong and fix it. Neither of the log files contained this output.

NB: at least on Ubuntu the $(which sshd) is the best method to satisfy sshd requirement of an absolute path. Otherwise you'll get the following error: sshd re-exec requires execution with an absolute path. The -p 10222 makes sshd listen on that alternative port, overriding the configuration file - this is so that it doesn't clash with potentially running sshd instances. Make sure to choose a free port here.

Finally: connect to the alternative port (ssh -p 10222 user@server).

This method has helped me many many times in finding issues, be it authentication issues or other types. To get really verbose output to stdout, use $(which sshd) -Ddddp 10222 (note the added dd to increase verbosity). For more debugging goodness check man sshd.

---

The main advantage of this method is that it allows you to check the sshd configuration without having to restart the sshd on the default port. Normally this should not interfere with existing SSH-connections, but I've seen it. So this allows one to validate the configuration file prior to - potentially - cutting off ones access to a remote server (for example I have that for some VPS and even for physical servers where I need to pay extra to get out-of-band access to the machine).

You can also have a host who's memory is so badly fragmented that it can't allocate a page a contiguous memory to fork the process for hosting an SSH session.

In such a case, you can get either of the messages:

ssh_exchange_identification: read: Connection reset by peer

or:

Connection closed by aaa.bbb.ccc.ddd

depending on how far the host gets before it bails out.

If memory fragmenting is the apparent cause, the solution is to access the server via other means and to restart some of the pertinent services. I have found Apache and MySQL to be the culprit on VM's since VM's don't have a swap partition. Failing that, reboot the host.

Just in case, because this happened to me. Get sure you have sshd running in the host!

It's a stupid failure, but might be really be your problem.