no matching key exchange method found in OpenSSH handshake

Answer the exact question first

Use a Match block in sshd_config (or a per‑host KexAlgorithms in ssh_config) to enable only the algorithms you need for the legacy host. Do not add the deprecated diffie-hellman-group1-sha1 or group14-sha1 unless you absolutely must; the safest fallback is [contact removed], ecdh-sha2-nistp256, and diffie-hellman-group-exchange-sha256, all of which provide forward secrecy.

Why this works

• OpenSSH ≥ 8.8 disables the weak DH groups by default to mitigate Logjam.
• The Match directive is evaluated in order; only the hosts that match the block will see the overridden list.
• Both client and server must list at least one common algorithm; the intersection of the global list and the per‑host list is what the handshake uses.
• Forward‑secrecy algorithms keep session keys independent of long‑term keys, so even if a legacy host is compromised, past sessions remain safe.

Server‑side configuration (sshd)

1. Open /etc/ssh/sshd_config as root.
2. Add a block that matches the legacy device’s address or hostname:

Match Host 10.0.0.42
    KexAlgorithms [contact removed],ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

3. Save the file and reload the daemon:

systemctl reload sshd

4. Verify the change with:

ssh -vvv user@10.0.0.42

The verbose output should show the negotiated KEX algorithm (e.g., [contact removed]) and no error about “no matching key exchange method”.

Client‑side configuration (ssh)

1. Edit /etc/ssh/ssh_config (or ~/.ssh/config) and add a per‑host override:

Host legacy-device
    HostName 10.0.0.42
    KexAlgorithms [contact removed],ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

2. Alternatively, use the -o option for a one‑shot connection:

ssh -o KexAlgorithms=[contact removed],ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256 user@10.0.0.42

3. Again, confirm with ssh -vvv that the chosen algorithm matches the server’s list.

Minimal secure baseline to consider for legacy hosts

Algorithm	Why it’s safe
[contact removed]	Fast, proven forward secrecy, no known weaknesses.
ecdh-sha2-nistp256	Standard ECDH with 256‑bit security, widely supported.
diffie-hellman-group-exchange-sha256	Supports larger groups, mitigates Logjam, still forward‑secrecy.

When you still need the old DH groups

• Only enable diffie-hellman-group1-sha1 or group14-sha1 if the device refuses all modern algorithms and you have a secure network path.
• Wrap the configuration in a very specific Match block that limits the change to the exact host or subnet.
• After use, revert the block or remove the weak algorithms to avoid accidental exposure.

Verification checklist

• Run ssh -Q kex on both client and server to list supported algorithms.
• Confirm the intersection contains at least one of the forward‑secrecy algorithms listed above.
• Use ssh -vvv to see the negotiated algorithm and ensure no “no matching key exchange method” error appears.
• Check /var/log/auth.log (or the equivalent) for the KEX line to verify the correct algorithm was used.

Missing diagnostic detail that may change the recommendation

What does ssh -Q kex output on the legacy server? If it lists only diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1, you will need to enable those weak algorithms for that host and then isolate them with a Match block as described.