With older SSH servers, you will occasionally run into errors where the encryption algorithms offered are incompatible with your client. In this article, I will cover some of the most common and how to get around them using OpenSSH.
These errors will, in most cases, be because the server or client is outdated. That means it is most likely using algorithms that are no longer considered secure. It is important to note that a permanent fix in these situations is to update your software.
Of course, things are not always this simple. An example of this would be if the server is not under your control or it is some networking equipment that does not have a firmware update available. And, of course, you will at least need access to the server to update it. In this article, I will try to help you do that.
“sign_and_send_pubkey: no mutual signature supported”
The server wants the client to send its public key using a signature algorithm that the client does not support. When this is written, likely, the algorithm in question is ssh-rsa. The ssh-rsa algorithm was deprecated in OpenSSH in version 8.7.
The reason for this is that the original ssh-rsa algorithm in the SSH protocol uses SHA1. With more recent hardware, it is possible to crack SHA1 encryption.
Newer servers will try to use rsa-sha2-256 or rsa-sha2-256 if you have a rsa key. If you are using some other type of SSH key, such as ed25519, the connection will use that algorithm and bypass this problem.
Your client will still allow you to use the older ssh-rsa algorithm if you specify it. Either on the command line:
ssh -o PubkeyAcceptedKeyTypes=+ssh-rsa user@host
You can also add this to the bottom of your configuration file at /etc/ssh/ssh_config
PubkeyAcceptedKeyTypes +ssh-rsa
Unable to negotiate with brokenhost port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
This error is basically because of the same as above. For DH negotiation, the server is only offering SHA1-based algorithms.
To temporarily get around this, you should pick one of the algorithms listed in the error message and have the client accept that.
ssh -o KexAlgorithms=+diffie-hellman-group-exchange-sha1 user@host
You can also add the algorithm to your /etc/ssh/ssh_config file. This will enable it for all hosts.
KexAlgorithms +diffie-hellman-group-exchange-sha1
You could also just enable it for this particular host in your ~/.ssh/config file
Host brokenhost.example.com
KexAlgorithms +diffie-hellman-group-exchange-sha1
Unable to negotiate with brokenhost: no matching host key type found. Their offer: ssh-dss
In this example, the SSH server is trying to send its host key with a type the client does not support. Here we can specify the allowed host key types with the HostKeyAlgorithms parameter.
ssh -o HostKeyAlgorithms=+ssh-dss user@brokenhost
As before, you can also enable the algorithm globally by adding the option to the bottom of your /etc/ssh/ssh_config file:
HostKeyAlgorithms +ssh-dss
Or just enable it for this particular host in your ~/ssh/config file:
Host brokenhost.example.com
HostKeyAlgorithms +ssh-dss
Some ways to debug an algorithm mismatch
If the options above don’t solve your problem, there are some ways to get more detailed information from your client.
The first thing I would try is to connect to the server in verbose mode. This should show you where in the process the negotiation failed and hopefully show what algorithms are offered.
ssh -v user@brokenhost
To get your SSH client to dump all the parameters, it is using to connect, you can use the -G option. This will show you what algorithms the client accepts.
ssh -G user@brokenhost