Troubleshooting ssh connection problems

 

2 – Incompatibility of cryptographic algorithms between client and server

Over the years, some of the encryption algorithms used by ssh have changed: older ones have been found to be vulnerable and have been replaced by newer, more robust algorithms. As a result it can happen that the client and server cannot negotiate a common encryption algorithm and therefore the connection cannot be established. If the client used for the connection is newer than the server, then in many cases it is possible to force it to use one of the algorithms available on the server. Conversely, when the server is much newer than the client, there is no other solution than to upgrade the client or use an intermediate server that accepts connections from the old client and is able to connect to the desired server.

Let’s see some examples.

Recent client, old server

Here you can see that the old server only supports ssh-rsa and ssh-dss algorithms for the host key. You can force the client to use them via the HostKeyAlgorithms option:

In other cases, the client and server fail to negotiate a method to exchange keys used to encrypt the connection:

This time, using the KexAlgorithms option we can force the client to use one of the obsolete algorithms supported by the server:

Here we see that we have solved the cryptographic key exchange problem, but now we have the host key type incompatibility problem, already seen in the previous case, which we know how to solve with the HostKeyAlgorithms option. So using both options we can connect:

Another typical error that can be encountered when using a recent client to connect to an old server is

The reason is that the server uses an RSA-type identification key that is too small in length (usually 1024 bit instead of 2048 or more).

In such cases, we can use the -o PubkeyAcceptedAlgorithms=ssh-dss option to force the client to use DSS keys instead of RSA (provided the server supports them). On RedHat and derivative systems, the ssh client also supports the -o RSAMinSize=1024 option to lower the minimum allowed length of the ssh RSA key.

Once we have found the options needed to connect to a certain host, we can insert them into the ~/.ssh/config configuration file so that we do not have to write them every time. In the file we can indicate the options needed for each host like this:

After the Host directive, you can enter multiple host names separated by spaces and even the same host with and without domain, so that the directive is used regardless of how we write the host name on the command line.

More information about the options to provide to the ssh command or to insert into the configuration file can be found in the ssh_config(5) man page:

Old client, new server

The opposite situation can also occur if we use an old client to connect to a server updated with the latest versions of ssh:

In this case we don’t have many options: the server refuses the connection because our client uses obsolete algorithms. If we don’t have a way to reconfigure the server to allow access with old and less secure algorithms (which is not advisable anyway), the only way to solve the problem is to update the client; or, if possible, use an intermediate server that accepts the connection from our old client and in turn has a client recent enough to be accepted by the server we want to connect to.