ssh_exchange_identification ‘connection closed by remote host’

While in many cases the ssh_exchange_identification: Connection closed by remote host error can be caused by issues related to the hosts.deny and hosts.allow configuration files, there are other things that can cause the problem. If you’re reading this, then chances are you’ve already checked to make sure that both of these files weren’t blocking your IP address from trying to use ssh on a remote server.

Assuming this is the case, then you might be looking at a dependency issue, something related to memory fragmentation or even an excessive number of sessions coming from individual clients. The good news is that once you’ve taken care of the problem you shouldn’t see the error again.

Method 1: Fixing Missing Dependencies

If you’ve gotten the ssh_exchange_identification: connection closed by remote host error only after updating OpenSSL or glibc, then you might be looking at a missing dependency. Run sudo lsof -n | grep ssh | grep DEL from the command line in this situation. This will give you a list of open files, then look only for ones that were recently deleted related to the ssh daemon.

Should you not get anything back, then you can still try restarting the daemon or the system itself. You’ll want to give a restart a try if a number of errors did get thrown back at you, though you can safely ignore those related to /run/user/1000/gvfs messages as these are caused by an unrelated issue that has to do with a virtual file system.

You could attempt to use apt-get, pacman or yum to update your packages as well if you suspect dependencies are a problem. If you’re on a Debian or Ubuntu based system, then you might want to try sudo apt-get -f upgrade and see if that fixes any broken packages that you might have fallen afoul of.

Method 2: Correcting Memory Fragmentation

If this didn’t help, then you might have an issue on the host side of the equation. Hosts that run inside of a VM don’t always have a swap partition, which can lead to memory fragmentation. Access the host by some other means, perhaps physically if possible, and then restart any services suffering from problems. MySQL, Apache, nginx and other such services might be the culprits.

While it might not always be feasible to reboot the host, this can correct the problem and might be a good idea if you’ve been alternating between this error message and one that returns an IP address. Keep in mind that if you have any sort of access to the server, then you can run the vmstat -s command and get some important stats on how memory is getting used even as a regular user in many instances.

Method 3: Check for Extra ssh Instances

Barring this, then check to see if hosts are trying to connect to the server. You might have exceeded the maximum number of ssh sessions without knowing it. Clear up the old sessions and then try to reconnect. One easy way to do this is run the who command to see which user processes are logged in. You should only see one or two users logged in. If there are a number of parallel ones, then kill the user processes and try logging back in.

This may happen if sshd can’t keep up with a script that starts many different ssh sessions in a loop. If this ever happened to you, then add the sleep 0.3 command to the loop so that the sshd daemon has time to keep up.

Method 4: Find the sshd Connection Limit

Connection problems like this are especially prevalent when attempting to use ssh to access a router or another type of discrete boxed switch since the default maximum number of connections is so small. While you don’t want to permit yourself to overload the server, you can have a look at what the default setting is.

Try running on the server to find how many connections that sshd can handle. In most cases, the system should default to 10 simultaneous connections, which should be plenty for most server structures that a majority of users are likely to need to use ssh on regularly.