Fixing SSH Key Exchange Errors Without Weakening Every Connection

An SSH connection can fail before you enter a password or your private key is considered. If the error says no matching key exchange method found, the client and server could not agree on how to establish the encrypted session. It is not an authentication failure.

The error often includes a clue like this:

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

Their offer lists key exchange (KEX) algorithms advertised by the server. If none also appears in the client’s allowed list, negotiation stops.

First, identify which part of SSH failed

SSH negotiates the encrypted connection before it checks the server’s host key or authenticates your user. That order matters: similar-looking “no matching” errors can point to different settings.

• no matching key exchange method found concerns how the session keys are generated. The relevant option is KexAlgorithms.
• no matching host key type found concerns how the server proves its identity. That needs a host-key setting, not a KEX change. See this guide to the separate ssh-rsa host-key mismatch.
• An authentication error happens later, when SSH is trying to verify your account or key.

If you’re unsure which negotiation stage failed, verbose output can help show where the connection stops:

ssh -vv user@host

Don’t change authentication or host-key settings to address a KEX error. In particular, StrictHostKeyChecking=no does not fix key exchange; it disables a separate check that helps verify the server’s identity.

Apply a compatibility exception to one host

If the error names a legacy algorithm that the server still requires, you can try adding that algorithm for a single connection:

ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 user@host

Replace the example algorithm with one listed after Their offer: in your own error. If the server lists several, you only need to add one that it offers and your client supports.

The + is important: it appends the algorithm to the client’s existing defaults instead of replacing them. That preserves the modern defaults for this connection while adding a compatibility option.

For a server you connect to regularly, put the exception in a host-specific block in ~/.ssh/config:

Host legacy-server
    HostName 203.0.113.10
    User user
    KexAlgorithms +diffie-hellman-group1-sha1

Connect using the alias:

ssh legacy-server

A per-host block makes the exception easier to review and remove later. If you’re building a config with multiple hosts, keys, and ports, this SSH config example guide covers the structure and common options.

Why the client may reject the server’s offer

Current SSH clients avoid some older algorithms by default because they have security weaknesses. For example, diffie-hellman-group1-sha1 uses a fixed 768-bit group and is considered weak. diffie-hellman-group14-sha1 uses a 2048-bit group, but relies on SHA-1, which OpenSSH has phased out of its default client set.

These names may appear in errors from older servers, routers, switches, NAS devices, or other appliances. Enabling a legacy algorithm may restore access, but it is a compatibility workaround—not a security upgrade.

To see which KEX algorithms your OpenSSH client supports, run:

ssh -Q kex

This reports client capabilities; it does not show the final options used for a particular host. To inspect the effective configuration for a connection, run:

ssh -G user@host

Look for the kexalgorithms line. For the negotiation details, use ssh -vv user@host and check the output alongside the error’s server offer.

Avoid broad workarounds

Keep any legacy exception limited to the one server that needs it.

• Don’t add a weak algorithm under Host *. That can affect connections to every host, including servers that support modern KEX methods.
• Don’t enable every old algorithm “just in case.” Add only one that the server actually offers and the client supports.
• Don’t use a host-key or authentication option to try to solve a KEX mismatch. Each setting applies to a different stage.

When you can, update OpenSSH on the server or install updated firmware on the device. A server that offers modern KEX algorithms no longer needs the client-side exception. Once you’ve confirmed the server works without it, remove the override from your SSH config.

The useful distinction is simple: a KEX error means the client and server cannot agree on how to establish the encrypted session. A narrowly scoped compatibility option may help you connect, but updating the server is the lasting fix.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.