PuTTY Couldn't Agree a Key Exchange Algorithm: How to Fix It

What you're seeing

A "PuTTY Fatal Error" dialog the moment the connection opens, before any password or key prompt:

Couldn't agree a key exchange algorithm (available: curve25519-sha256,[email protected],ecdh-sha2-nistp256,diffie-hellman-group16-sha512)

The list after available: is what the other side offered, and it tells you which of the two cases you're in:

• The list is full of modern names (curve25519-sha256, ecdh-sha2-*, diffie-hellman-group14-sha256): the server is fine and your PuTTY is too old to speak any of them. Update PuTTY. This is the majority case.
• The list is short and legacy (diffie-hellman-group1-sha1, maybe diffie-hellman-group14-sha1): the device is ancient and your current PuTTY won't use those algorithms by default. Enable the legacy algorithm for that one session.

Two close relatives of this error mean the same kind of mismatch at a different step of the handshake:

• Couldn't agree a host key algorithm: the negotiation failed over host-key types instead of key exchange. Same two cases, same fixes, but the panel is Connection > SSH > Host keys instead of Kex.
• Expected key exchange group packet from server: an old PuTTY tripping over a server that requires Diffie-Hellman group exchange. Updating PuTTY fixes it.

What's causing this error

At the start of every SSH connection, client and server each send a ranked list of the key-exchange algorithms they support, and the first entry both lists share wins. This error means the intersection was empty: there is literally no algorithm both sides are willing to use, so the connection cannot even be encrypted, let alone authenticated.

The two mirror-image causes:

1. Old PuTTY against a modern server. Current Linux distributions and hardened sshd configs have removed the SHA-1 based key exchanges (diffie-hellman-group1-sha1, diffie-hellman-group14-sha1) that old PuTTY relies on, and PuTTY builds from before 2017 don't offer curve25519-sha256 or the other modern replacements at all. This is why the error often appears right after a server OS upgrade (Ubuntu, Debian on a Raspberry Pi, RHEL) while "nothing changed" on your side. Your side is the problem: a 0.6x-era PuTTY.
2. Modern PuTTY against an ancient device. Old Cisco IOS switches and routers, ESXi hosts, out-of-band management cards, and appliances that never got firmware updates may offer only diffie-hellman-group1-sha1. Current PuTTY keeps that algorithm below its warning threshold, or refuses it outright depending on version and settings, because SHA-1 group1 exchange is considered breakable.

How to fix it

Case 1: your PuTTY is old (the one-minute fix)

Check your version under Help > About, or in the window title of the About box. Anything older than 0.85 is worth updating regardless; anything from the 0.6x era (2015 and before) is the direct cause of this error against modern servers.

Grab the current installer from our PuTTY download page, which lists the official builds with checksums. The installer upgrades in place: your saved sessions live in the registry and survive the update untouched.

After updating, just reconnect. No settings changes needed; new PuTTY offers the modern algorithms and the handshake succeeds.

Case 2: you're current and the device is ancient

If your PuTTY is up to date and the available: list in the error shows only legacy names, tell PuTTY to accept the algorithm the device offers, for this session only:

1. Open PuTTY and Load the saved session (don't just change Default Settings).
2. Go to Connection > SSH > Kex.
3. In the "Algorithm selection policy" list, find the algorithm from the error's available: list, usually Diffie-Hellman group 1.
4. Select it and click Up until it sits above the --- warn below here --- line.
5. Go back to Session, click Save, then Open.

If you instead get a warning dialog ("the first key-exchange algorithm supported by the server is diffie-hellman-group1-sha1, which is below the configured warning threshold"), that's the same situation one notch less severe: clicking Accept connects you once, and the Kex reorder above makes it permanent for that session.

Treat this as a workaround, not a fix. SHA-1 group1 key exchange is weak, which is exactly why PuTTY buries it. The real fix is a firmware or OS update on the device; keep the legacy setting scoped to that one saved session so every other connection stays on modern crypto.

The host key algorithm variant works the same way in Connection > SSH > Host keys: move the type the device supports (usually ssh-rsa) above the warn line for that session.

For server admins

If users with old PuTTY builds can't reach your server, the right answer is almost always "have them update PuTTY" rather than weakening the server. But you can see exactly what your sshd offers, and adjust it explicitly, with:

sudo sshd -T | grep -i kexalgorithms

To modernize an old server (the good direction), update OpenSSH via your distro. To temporarily re-enable a legacy exchange for clients you can't update (the bad direction, use sparingly):

# /etc/ssh/sshd_config
KexAlgorithms +diffie-hellman-group14-sha1

sudo systemctl restart sshd

The leading + appends to the default list instead of replacing it. Remove the line as soon as the last legacy client is gone.

Common edge cases