Upgrade to OpenSSH 10.3 on Client and Server for Post-Quantum SSH

Many teams have not yet modernized SSH cryptography defaults. This is the right time to upgrade proactively, set a preferred hybrid KEX policy, and verify negotiation across both server and client tools.

Upgrade Goal

For modern OpenSSH, the preferred hybrid algorithm is mlkem768x25519-sha256. A valid fallback is sntrup761x25519-sha512.

• mlkem768x25519-sha256 — added in OpenSSH 9.9, made the default in OpenSSH 10.0 (April 2025).
• sntrup761x25519-sha512 — available since OpenSSH 9.0 (April 2022), remains a valid fallback.

OpenSSH 10.1 actively warns when a connection does not use a post-quantum KEX algorithm: "This session may be vulnerable to 'store now, decrypt later' attacks." This warning can be suppressed per-host using WarnWeakCrypto in ssh_config with a Match directive for legacy hosts.

Target state: successful negotiation of either mlkem768x25519-sha256 (preferred) or sntrup761x25519-sha512, with ML-KEM first in policy order.

Why Act Now

Post-quantum key exchange is urgent in a way that post-quantum signatures are not. Traffic captured today can be stored and decrypted later once a cryptographically-relevant quantum computer exists — a threat known as "store now, decrypt later."

Signature algorithms only matter when keys are actively in use, so their retirement can wait. Key exchange affects every session in flight right now.

Estimates for cryptographically-relevant quantum computers range from 5 to 20 years out, with the mid-2030s as a commonly cited window. Any sensitive session recorded today may be decryptable within that timeframe.

Migrating key exchange now eliminates the store-now risk entirely. Waiting means every session recorded in the interim is permanently at risk.

Why OpenSSH

OpenSSH is the only SSH client installed by default on most operating systems — including Linux, macOS, and Windows 10/11 — making it the lowest-friction path to post-quantum SSH for end users and administrators alike.

Additional reasons to standardize on OpenSSH for both client and server:

• Fastest PQ adoption. OpenSSH ships ML-KEM hybrid support before most third-party clients, and version 10.0+ enables it by default with no config change needed.
• Policy control. KexAlgorithms in ssh_config and sshd_config gives precise, auditable control over algorithm order on both ends of the connection.
• Scriptable verification. Verbose flags (-vv) and ssh -Q kex make it straightforward to confirm negotiated algorithms in automated checks and compliance evidence.
• No licensing cost. OpenSSH is free and open source, removing a barrier to broad fleet rollout.
• Uniform toolchain. Using the same client everywhere simplifies key management, config distribution, and troubleshooting across platforms.

Why Hybrid Algorithms

Both supported algorithms are hybrids — they combine a post-quantum scheme with a classical elliptic-curve algorithm (x25519):

• mlkem768x25519-sha256 combines ML-KEM-768 (NIST-standardized) with x25519 ECDH.
• sntrup761x25519-sha512 combines NTRU Prime with x25519 ECDH.

The hybrid design means security cannot be worse than classical-only approaches. If either component is unbroken, the session key is safe. This makes the transition low-risk: adopting hybrid KEX today provides quantum resistance without giving up classical security guarantees.

Post-quantum signature algorithm support is planned for future OpenSSH releases. Key exchange is the current priority because it protects sessions in flight now.

Why Move Away from Proprietary Clients

Many commonly deployed SSH clients lag behind OpenSSH on post-quantum support, carry per-seat licensing costs, and offer less auditability than a plain-text config file.

The migration to post-quantum SSH is a practical forcing function: if a client cannot clearly confirm ML-KEM hybrid negotiation today, plan to replace it rather than wait for a vendor update that may not arrive on schedule.

Version Snapshot

• OpenSSH: 10.0+ makes ML-KEM hybrid the default.
• PuTTY: NTRU Prime in 0.78, ML-KEM in 0.83.
• MobaXterm: NTRU Prime in 23.2, ML-KEM in 25.2.
• SecureCRT: public changelog does not clearly confirm ML-KEM/NTRU Prime KEX support.

Why Use the Latest OpenSSH

Every version below 10.3 leaves at least one known security issue open. The table covers all documented releases with security relevance from the OpenSSH security page.

Each row above represents vulnerabilities that remain open if you are running the version below it. Running the latest available release closes all of them simultaneously.

OpenSSH and the CISA KEV Catalog

No OpenSSH CVEs appear in the CISA Known Exploited Vulnerabilities (KEV) catalog — including the Critical-rated sshd race condition RCE (9.8) and CVE-2023-38408 (CVSS 9.8). CISA adds vulnerabilities to KEV only when there is confirmed evidence of active exploitation in the wild. The absence of OpenSSH entries is a meaningful signal: despite a long CVE history, OpenSSH vulnerabilities have not been observed being actively exploited at scale.

This does not eliminate upgrade urgency — unpatched systems remain exposed — but it does distinguish OpenSSH's risk profile from products with confirmed in-the-wild exploitation.

The KEV catalog does contain SSH-adjacent entries where the SSH protocol or SSH tooling was the attack vector in other products:

The Erlang/OTP entry (CVE-2025-32433) is the most significant: an SSH server implementation flaw leading to unauthenticated RCE that was actively exploited. It illustrates exactly the class of risk that non-OpenSSH SSH implementations carry — and why standardising on a well-maintained, widely-audited implementation matters.

OpenSSH Server Upgrade

1. Confirm current server version

sshd -V 2>&1
ssh -V

2. Upgrade OpenSSH package

Use your OS package manager and move to a release line that supports modern PQ hybrid defaults (newer OpenSSH recommended).

# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade openssh-server openssh-client

# RHEL/Rocky/Alma
sudo dnf upgrade openssh-server openssh-clients

3. Set KEX order in sshd_config

# /etc/ssh/sshd_config
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

4. Validate and reload safely

sudo sshd -t
sudo systemctl reload sshd

5. Verify from a modern client

ssh -vv user@server
# Confirm negotiated kex algorithm in debug output.

Support Matrix

Verify in OpenSSH

1. Check client version

ssh -V

2. List client KEX support

ssh -Q kex

3. Inspect negotiated KEX on connect

ssh -vv user@server
# Look for lines mentioning kex algorithm negotiation.

4. Optional policy test (preferred first)

ssh -o KexAlgorithms=mlkem768x25519-sha256,sntrup761x25519-sha512 user@server

Verify in PuTTY

1. Open PuTTY and verify version in About.
2. Connect using your normal saved session/host.
3. Right-click the title bar or terminal area and select Event Log.
4. Find the key exchange line. Confirm it is mlkem768x25519-sha256 or sntrup761x25519-sha512.

Verify in SecureCRT

1. Use File → Trace Options, then File → Log Session.
2. Optionally, in Session Options → Log File, set trace level to 9 and enable timestamps.
3. Connect and inspect the trace/log file for negotiated SSH key exchange algorithm details.
4. If no ML-KEM/NTRU hybrid appears, your build or config likely does not negotiate PQ hybrid KEX yet.

Verify in MobaXterm

1. Use a build where the changelog includes ML-KEM support (25.2+).
2. Start your normal SSH session to the server.
3. From the terminal context menu, open Event log (MoTTY/PuTTY engine details).
4. Look for the line naming the key exchange algorithm and verify a PQ hybrid value.

Rollout Order

1. Upgrade OpenSSH servers first in staging, then production tiers.
2. Set and test server-side KEX ordering before broad client rollout.
3. Upgrade clients by fleet or team, prioritizing admin/jump-host users.
4. Capture verification evidence from each client family and archive it.