Securing PuTTY Connections: Choosing the Right Key Exchange Algorithm for Modern SSH

The Problem: Legacy Key Exchange Weakens Your SSH Sessions

When you connect to a server through PuTTY, the key exchange (KEX) algorithm determines how the client and server agree on shared encryption keys for the session. If either side falls back to a weak algorithm, the session can be exposed to downgrade or cryptanalytic attacks. The classic offender is diffie-hellman-group1-sha1: its fixed 1024-bit modulus and SHA-1 hashing are no longer considered safe against well-resourced attackers, as demonstrated by research such as the Logjam analysis of weak Diffie-Hellman parameters.

The useful takeaway: you can explicitly control which KEX algorithms PuTTY offers, and doing so takes only a few minutes. This article shows how to pick a strong algorithm, configure it, and verify what was actually negotiated.

Which Algorithms to Prefer

Modern SSH implementations support several key exchange methods. In rough order of preference for current PuTTY releases:

• curve25519-sha256 (also listed as [contact removed] on some servers) — based on the Curve25519 elliptic curve; the current default choice in OpenSSH and modern PuTTY builds.
• ecdh-sha2-nistp256 — NIST P-256 elliptic curve Diffie-Hellman; widely supported and still considered secure.
• diffie-hellman-group14-sha256 — 2048-bit finite-field Diffie-Hellman with SHA-256; a reasonable fallback for servers without elliptic-curve support.

Avoid diffie-hellman-group1-sha1 (and generally group14-sha1) unless you have no other option for a legacy device.

Configuring PuTTY's Key Exchange

GUI method

1. Open PuTTY and load your saved session.
2. Navigate to Connection > SSH > Kex.
3. In the algorithm preference list, use the Up/Down buttons to move curve25519-sha256 (or ecdh-sha2-nistp256) to the top.
4. Return to the Session panel and click Save so the setting persists.

PuTTY's Kex panel also has a policy option for what to do when the server offers an algorithm below your configured warning threshold — leave it at the default prompting behavior unless you have a reason to change it.

Command-line method

For scripted or ad-hoc connections, run this from a Windows command prompt or PowerShell (no elevated privileges needed):

putty.exe -ssh [contact removed]

The order of algorithms in the GUI list is what PuTTY offers to the server; the first mutually supported algorithm wins. There is no -o KexAlgorithms= flag in PuTTY itself — that syntax belongs to OpenSSH's ssh client. In PuTTY, algorithm preference is controlled through the saved session settings described above.

Worked Example: Verifying the Negotiated Algorithm

Assume PuTTY 0.78 on Windows, connecting to a Linux server running a recent OpenSSH.

1. Check the PuTTY version

In a command prompt, run:

putty.exe -V

Expect 0.74 or later — earlier releases had known vulnerabilities in SSH key handling and lack some modern algorithms. Upgrade first if needed.

2. Check what the server supports

On the server (or any machine with OpenSSH that can reach it), run:

ssh -Q kex

This lists the KEX algorithms that build of OpenSSH supports. Look for curve25519-sha256 near the top.

3. Connect and inspect the Event Log

Connect with PuTTY, then right-click the window title bar and choose Event Log. Look for lines similar to:

Doing ECDH key exchange with curve Curve25519 and hash SHA-256

The exact wording varies by PuTTY version, but the log always names the algorithm actually negotiated. If you see group1 or sha1 here, your preference order or the server's configuration needs attention.

Trade-offs and Limitations

• Legacy servers: Old OpenSSH versions and embedded devices may only offer group14-sha1 or group1-sha1. You can lower PuTTY's preference to connect, but treat that as a temporary exception and plan to upgrade or isolate the device.
• Version differences: Algorithm availability varies across PuTTY releases; verify with the Event Log rather than assuming.
• Saved sessions: KEX preferences are stored per session. Changing the default settings does not retroactively update existing saved sessions — edit and re-save each one you care about.

Actionable Closing

Update PuTTY to a current release, move curve25519-sha256 to the top of the Kex preference list in your saved sessions, and confirm via the Event Log that your next connection actually negotiates it. For any server that forces a fallback to SHA-1-based exchange, file a ticket to modernize it — that fallback is your list of technical debt, written for you by the SSH handshake.