When you’re trying to use ssh to get in touch with a remote server, you might receive an error that reads no matching key exchange method found before giving you a suggestion as to which encryption algorithm you’ll want to be using. You won’t be able to connect to the remote server whenever you experience the error. This process can be really frustrating, but the error is so common that you’ll often find Unix types talking about how they’re experiencing it and giving the same advice to get out of the woods.
The following methods to fix the error have been tested on everything that ssh works on, but you’ll most likely find this problem on Unix and Linux systems. You should be able to use the same process to correct it if you’re running ssh on Windows or something exotic, but you might find that the switch options are slightly different.
Method 1: Recontacting the Server and Regenerating Keys
Before you do anything else, make sure that you can reproduce the error. Sometimes this error message is just because there is some remote-side service that isn’t currently running, which might have been corrected in the meantime. While we were running ssh in a virtual machine that allowed the connection to a bogus server address that was set to the documentation-approved example.org, but you’ll want to substitute a real networking address instead.
If you still receive it, then try regenerating keys with ssh-keygen -A from the command prompt. This will refresh the cache that the ssh application uses to connect to the remote server. Barring that, you might want to try restarting ssh by running service ssh restart and giving it a few moments.
Should you still be having issues, then it means that the server and client weren’t ever able to come to terms with the right protocol to use. OpenSSH implements a dizzying array of different protocols, but it disables a number of these because they’re now known to be compromised and therefore unsafe. You’ll want to update all the ssh packages at the server end of the equation, so make sure the system administrator is aware of what’s going on. If it’s your own server, then take a moment to update them.
If this isn’t an option and you recognize the dangers of using a compromised algorithm, then there’s a client-side way to bypass this error message.
Method 2: Enabling Legacy Options in OpenSSH
Take a look at what the error message reads after the words Their offer: to see what algorithm the remote server prefers. While most systems should be using openssh7, which has already disabled the older obsolete diffie-hellman-group1-sha1 technology, you’ll be told to use sha1 if they’re still stuck on openssh6 or something similar.
Run ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 email@example.com with whatever the actual networking host or IP address of the remote server is to fix this issue on the client-side. If this fixes the issue, then it was looking for an older sha1-based protocol to connect. This older sha1-based solution was disabled for a good reason, but you can more permanently bypassing it by using the nano or vim editors to open up the ~/.ssh/config file and add the lines:
Keep in mind that you’ll want to make sure that the plus sign is there since it means that ssh will append rather than replace the more secure defaults. When the server updates the packages, you’ll be using the safer protocols in most cases.
If you received an error before that mentioned the ssh-dss protocol instead of the sha1 version, then you can instead try this command followed by the name of your host: ssh -oHostKeyAlgorithms=+ssh-dss, which if it works you’ll need to edit the ~/.ssh/config file again. After the Host line, add a tab and the following:
Remember that just like the sha1 system, the ssh-dss key has been deprecated for extremely rational security problems associated with it. Using this could introduce vulnerabilities into your connection, so it should be looked at only as a temporary fix if even that. Make sure to get the server updated as soon as possible.