SSH No Matching Key Exchange Method Found Causes and Fixes

You update your laptop and the connection to an old switch, NAS or router stops working with Unable to negotiate with 192.0.2.5 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1. The message is accurate: the two sides share no algorithm. OpenSSH removes weak algorithms over time, so a device that has not been updated falls off the list. The reading and fixes are below, using OpenSSH 9.x as the client.

Read the offer

ssh [email protected]
ssh -Q kex
ssh -vv [email protected] 2>&1 | grep -E 'kex_algorithms|peer server KEXINIT'

Unable to negotiate with 192.0.2.5 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
sntrup761x25519-sha512
curve25519-sha256
[email protected]
diffie-hellman-group-exchange-sha256
diffie-hellman-group14-sha256

The line "Their offer" lists what the server supports. ssh -Q kex lists what your client supports. If no item is on both lists, negotiation fails. The server's list here has only the SHA-1 based groups, which current OpenSSH no longer enables by default: diffie-hellman-group1-sha1 was removed in 7.0 and group14-sha1 is off by default since 8.8. The sample addresses are documentation addresses.

The right fix: update the server

sudo apt update && sudo apt install --only-upgrade openssh-server
sudo sshd -T | grep -E '^kexalgorithms'
ssh -V

If the server is a Linux machine, update OpenSSH and the system. Check its supported algorithms with sshd -T. For network appliances, the vendor's firmware update usually adds modern algorithms; in the meantime check for a setting such as "SSH security level" or "crypto policy". An old device on a management network may not be worth exposing to anything else.

The stopgap: allow it for one host

Host old-switch
    HostName 192.0.2.5
    User admin
    KexAlgorithms +diffie-hellman-group14-sha1
    HostKeyAlgorithms +ssh-rsa

ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 [email protected]

The leading + appends the algorithm to the default list instead of replacing it, so modern algorithms still win where the server supports them. Pick the strongest algorithm the server offers: group14-sha1 over group1-sha1, because the latter uses a 1024-bit group that is within reach of well-funded attackers. Limit the exception to the old host's entry in the SSH config. Never put it under Host *.

Related errors with the same cause

no matching host key type found. Their offer: ssh-rsa,ssh-dss
no matching cipher found. Their offer: aes128-cbc,3des-cbc
no matching MAC found. Their offer: hmac-md5

The same negotiation applies to host key types, ciphers and MACs, and the same pattern of reading the offer and adding the minimum needed fixes each. The host key version is covered in no matching host key type found; ciphers use Ciphers +aes128-cbc and MACs use MACs +hmac-sha1. Look at all lines of the error, as a device may need several overrides.

The opposite direction: a new server and an old client

If a hardened server rejects an old client (a legacy tool, an embedded device or an old library), the message is the same with the roles reversed, and you see it from the client side as "Their offer" with modern algorithms only. The fix is updating the client. The server settings that decide this are KexAlgorithms, Ciphers and MACs in sshd_config, described in hardening sshd.

How algorithm negotiation works

At the start of an SSH connection, each side sends a list of supported algorithms for key exchange, host keys, ciphers and message authentication, in order of preference. The first algorithm on the client's list that the server also supports is chosen for each category. If a category has no overlap, the connection ends with the "no matching" error for that category. This design lets the protocol evolve: new algorithms are added to the front of the lists, old ones are dropped, and two peers of different ages still find common ground when any exists.

The trouble arises because defaults change in only one direction. OpenSSH removes algorithms when attacks make them unsafe, and a device frozen at an old firmware keeps offering only what it was built with. Eventually the lists no longer intersect. The error is the protocol working as designed, and it tells you the age of the device more clearly than any inventory spreadsheet.

Judging the risk of re-enabling an old algorithm

Not all old algorithms are equally risky, and the decision should be informed. The SHA-1 based key exchanges are weak against attackers who can capture and later analyse traffic, and the weakest group, with a 1024-bit prime, is the one practical attacks have targeted. Within a closed management network, with only administrators able to reach the device, the exposure is limited. Across the internet, it is not. The same applies to CBC ciphers and old MACs, where the practical weaknesses depend on how much traffic an attacker can observe and tamper with.

Make the exception as narrow as you can. Scope it to one host, allow only the specific algorithm needed, and add a comment with the reason and a date to review. Prefer reaching the device through a jump host or VPN, so that the weak connection crosses only a small trusted segment instead of a wide network. If the device is exposed to the internet, treat the old algorithms as a reason to replace or isolate it.

Finding the minimum change

Work from the error. Each message names the category and lists what the other side offers, so choose one item from that list that your client can enable, check with ssh -Q kex that it exists in your build, and add it with the plus sign. Retry. If another category fails, repeat. Resist the urge to paste a long block of weak algorithms from a forum post; each extra entry widens the exception. When the connection works, run it with -v once and note the algorithms actually used, then trim the configuration to exactly those.

Different OpenSSH builds disable different things. A client from a distribution may still carry a patch that keeps an algorithm another build removed, and an old option such as -o KexAlgorithms=diffie-hellman-group1-sha1 might need the plus form to work at all. Check the version with ssh -V and read its release notes if the behaviour does not match your expectation.

Planning the replacement

An old device that needs exceptions is a maintenance debt. Put it on the list of things to upgrade, with an owner and a date. In the meantime, record the exception in version control, restrict the device's network exposure, change its credentials to something unique and monitor its logins. When the firmware is finally updated, remove the exception from the config so the stronger defaults apply again; an exception that outlives its reason is a hole nobody remembers digging.

Where this does not apply

For scripts running in CI against old devices, pin the exception in the job's config rather than in the runner image, and note an expiry date to replace the device. Do not treat disabled algorithms as a nuisance: they were removed because attacks became practical. See the OpenSSH release notes for the versions in which each was disabled, and the ssh_config KexAlgorithms description.