SSH Modernization Guide

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 clients below represent the most common replacements teams are asked to evaluate:

Client Vendor PQ KEX Status Licensing Key Concerns
SecureCRT VanDyke Software Not clearly documented Per-seat, paid Public changelog does not confirm ML-KEM or NTRU Prime KEX support. Requires hands-on trace logging to verify algorithm negotiation. GUI session config is hard to enforce fleet-wide.
Xshell NetSarang Not clearly documented Free for home/school; per-seat for enterprise No public confirmation of ML-KEM support. NetSarang had a supply-chain compromise in 2017 (backdoor in nssock2.dll shipped across multiple products). Enterprise licensing adds renewal overhead.
SSH Tectia SSH Communications Security Vendor-specific timeline Per-seat, enterprise contract Original commercial SSH product. PQ roadmap is vendor-controlled and not publicly tracked per-release. High per-seat cost; negotiated enterprise contracts add procurement overhead.
Bitvise SSH Client Bitvise Not clearly documented Free personal; per-seat enterprise Windows-only. Free tier creates a split fleet where personal and enterprise users run different clients. PQ KEX adoption not publicly confirmed in changelog.
ZOC Terminal EmTec Not clearly documented Per-seat, paid Primarily a terminal emulator with SSH support. Cryptographic updates lag OpenSSH. No public confirmation of PQ hybrid KEX. macOS and Windows only.
Reflection for Secure Shell Micro Focus / OpenText Not clearly documented Enterprise contract Legacy enterprise terminal emulator. PQ KEX status not publicly documented. Upgrade cadence tied to enterprise contract renewals rather than open-source release cycles.
MobaXterm Mobatek ML-KEM in 25.2+ Free Home; per-seat Professional ML-KEM confirmed from 25.2 (April 2025). Uses an embedded MoTTY/PuTTY engine — algorithm support follows PuTTY's cadence. Professional edition adds licensing overhead.
PuTTY Simon Tatham (open source) ML-KEM in 0.83+ Free / MIT licence ML-KEM confirmed from 0.83. Free and open source, but Windows-focused and GUI-driven. Session config is not easily managed as code; lacks the ssh_config policy model of OpenSSH.
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.

Version Released CVEs / Security Fixes Notable Improvements
≤2.3.0 pre-2001 Critical CRC32 compensation attack detector buffer overflow (CAN-2001-0144) allowing remote root access.

High Malicious servers could access client X11 display or ssh-agent (CERT VU#363181).

High UseLogin remote arbitrary command execution (CERT VU#40327). 		SSH-1 protocol deficiencies addressed; RC4 and IDEA removed; unencrypted connection support removed.
2.9.9 2001-05-21 Medium Source IP access control weakness in SSH protocol v2 public key authentication.

Low X11 forwarding cookie file deletion vulnerability (CERT VU#655259). 		Source IP ACL fixes; X11 forwarding hardened.
3.0.2 2001-11-24 Medium Environment variable passing to login(1) via UseLogin (CERT VU#157447). UseLogin disabled by default. Environment variable sanitisation.
3.1 2002-03-07 High Off-by-one error in the channel code. Channel code bounds fix.
3.4 2002-06-26 High Remote challenge vulnerability in pre-authentication code. Pre-auth hardening.
3.7.1 / 3.7.1p2 2003-09-16 High Buffer management bug (CERT CA-2003-24).

High Multiple PAM vulnerabilities in Portable OpenSSH (portable only). 		Buffer management overhaul; PAM fixes.
4.3 2006-02-01 CVE-2006-0225 Medium — CVSS 4.6 Shell metacharacter expansion in scp local-local and remote-remote copies enabling command injection. scp metacharacter sanitisation.
4.4 2006-09-27 High Unsafe signal handler vulnerability.

Medium SSH protocol 1 denial-of-service attack. 		Signal handler safety; SSH-1 DoS mitigation.
4.5 2006-11-07 Medium Privilege separation monitor weakness allowing spoofing of successful authentication (requires prior compromise of network-facing sshd process). Privilege separation monitor hardened.
5.0 2008-04-03 CVE-2008-1483 High — CVSS 6.9 X11 hijacking attack. X11 forwarding socket protection.
5.2 2009-02-23 Low Plaintext recovery attack against SSH (CPNI-957037). Attack considered infeasible in most circumstances but theoretically valid. CBC mode hardening.
5.8 / 5.8p2 2011-01-24 High Potential private key data leak in legacy certificate handling (5.6–5.7).

Medium Local host key theft via keysign/rand-helper in Portable OpenSSH (pre-5.8p2). 		Certificate handling hardened; keysign privilege fix.
6.4 2013-11-08 High GCM rekey memory corruption in versions 6.2 and 6.3. GCM rekey fix.
6.5 2014-01-30 No CVEs. Ed25519 public key support introduced — ssh-keygen -t ed25519 generates Ed25519 user and host keys. Shorter keys, faster signatures, and stronger security properties than RSA or ECDSA at equivalent bit lengths.
6.9 2015-06-30 Medium X11 forwarding race condition allowing non-trusted sessions to be treated as trusted (pre-6.9).

Low Weak TTY device permissions (6.7–6.9). 		X11 forwarding race fix; TTY permissions tightened.
7.0 2015-08-11 Medium keyboard-interactive authentication allowed circumvention of MaxAuthTries (pre-7.0). MaxAuthTries enforcement.
7.1p2 2016-01-14 CVE-2016-0777 / CVE-2016-0778 High — CVSS 6.5 / 8.1 Client roaming feature allowed malicious servers to retrieve private key data from clients (affects 5.4–7.1). Mitigation: UseRoaming=no. Roaming feature removed; information disclosure closed.
7.2p2 2016-03-09 Medium X11 forwarding command injection — authenticated users could inject commands to xauth(1) via unvalidated X11 forwarding requests. xauth input sanitisation; X11Forwarding=no default.
7.6 2017-10-03 Low sftp-server read-only mode allowed creation of zero-length files when invoked with -R flag (affects 5.5–7.5). sftp-server read-only enforcement fixed.
8.2 2020-02-14 Medium ssh-agent double-free memory corruption (affects 8.2–8.4). Mitigated by socket peer identity checking and allocator protections; not considered easily exploitable. FIDO/U2F security key support introduced — both ssh-keygen -t ed25519-sk (preferred; Ed25519, supported by all FIDO2 security keys) and ssh-keygen -t ecdsa-sk (ECDSA-P256; included for compatibility with FIDO1-only hardware such as YubiKey 4 and earlier that do not support Ed25519) were added simultaneously. Both generate hardware-backed keys tied to a physical security key (YubiKey, etc.), requiring both the private key file and the physical device for authentication.
8.5 2021-03-03 Fixes the 8.2–8.4 ssh-agent double-free. FIDO resident key support (ssh-keygen -K to download keys stored on the device itself); no-touch-required option for automated FIDO use.
8.8 2021-09-26 Medium AuthorizedKeysCommand / AuthorizedPrincipalsCommand failed to correctly initialise supplemental groups when executing as non-root, inheriting sshd startup groups (affects 6.2–8.7). Supplemental group initialisation fixed; RSA-SHA1 disabled by default.
9.2 2023-02-02 Medium PermitRemoteOpen ignored its first argument unless it was any or none, causing the permission list to fail open with a single rule (affects 8.7–9.1).

Low DNS name validation bypass with CanonicalizeHostname enabled — attacker with DNS control could inject invalid characters into known_hosts (affects 6.5–9.1).

Low Pre-authentication double-free memory fault in sshd 9.1 (not believed exploitable; sandboxed unprivileged process). 		PermitRemoteOpen logic fixed; DNS canonicalisation hardened.
9.3 2023-03-15 Medium ssh-add smartcard destination constraints not communicated to agent when using -h flag — keys added without intended per-hop restrictions (affects 8.9–9.2). Smartcard destination constraint propagation fixed.
9.3p2 2023-07-19 CVE-2023-38408 Critical — CVSS 9.8 Remote code execution via forwarded ssh-agent socket — PKCS#11 provider loading could be abused by a malicious server to execute arbitrary code on the client if specific libraries were present (affects 5.5–9.3p1). PKCS#11 provider allowlist enforced; remote loading of arbitrary modules disabled.
9.5 2023-10-04 No CVEs. General bug fixes including scp directory symlink handling. ObscureKeystrokeTiming feature introduced; connection multiplexing improvements.
9.6 2023-12-18 Medium — CVSS 5.9 Terrapin Attack — protocol weakness allowing an on-path attacker to delete consecutive messages at the start of an encrypted channel, breaking keystroke timing obfuscation and other integrity properties (pre-9.6 with CBC/ChaCha20).

Medium ssh-agent smartcard constraint bypass — when loading multiple keys from a PKCS#11 token, per-key use constraints were only applied to the first key (affects 8.9–9.5).

High Command injection via shell metacharacters — user/hostname arguments were not sanitised before use in ProxyCommand and Match exec directives, enabling injection if a user could be tricked into connecting to a crafted host. 		Strict key exchange mode (strict-kex) to harden against Terrapin-class attacks; PKCS#11 constraint fix; hostname sanitisation.
9.7 2024-03-11 No CVEs. Primarily bug fixes. DSA deprecation warning added; preparatory work for DSA removal.
9.8 2024-07-01 Critical — CVSS 8.1 Race condition in sshd — signal handler race condition (affects 8.5p1–9.7p1) could allow unauthenticated remote code execution as root. Exploitation demonstrated on 32-bit Linux/glibc with ASLR, requiring ~6–8 hours of continuous connections.

Low ObscureKeystrokeTiming logic error — the keystroke timing obfuscation feature (9.5–9.7) sent both real and fake packets unconditionally, making it completely ineffective against passive traffic analysis. 		sshd split into listener and per-session binaries to reduce attack surface; PerSourcePenalties rate-limits repeatedly failing source addresses; DSA disabled at compile time.
9.9 2024-09-19 No CVEs. ML-KEM768x25519-sha256 hybrid post-quantum KEX introduced; private keys now prevented from appearing in core dumps (OpenBSD, Linux, FreeBSD); DSA removal planned for early 2025.
9.9p2 2025-02-18 CVE-2025-26465 Medium Logic error in VerifyHostKeyDNS — on-path attacker could impersonate any SSH server when the option is enabled (affects 6.8p1–9.9p1).

CVE-2025-26466 Medium Pre-authentication memory/CPU denial-of-service via SSH2_MSG_PING packet handling in sshd (affects 9.5p1–9.9p1). Mitigatable via PerSourcePenalties. 		Both CVEs fixed; PerSourcePenalties recommended as defence-in-depth against the DoS vector.
10.0 2025-04-09 Medium DisableForwarding bypass — directive failed to disable X11 and agent forwarding in certain configurations (affects 7.4–9.9). mlkem768x25519-sha256 made default KEX; DSA removed entirely; finite-field Diffie-Hellman disabled in sshd by default; sshd authentication split into separate sshd-auth binary for reduced privilege exposure.
10.1 2025-10-06 High Shell injection via username — control characters in usernames passed on the command-line were not rejected, allowing injection through %r expansion in ProxyCommand configurations. WarnWeakCrypto option for per-host post-quantum warnings; ssh-agent sockets moved from /tmp to ~/.ssh/agent; DSCP EF marking for interactive sessions.
10.2 2025-10-10 No CVEs. Regression fix release. Fixed critical ControlPersist terminal handling regression that rendered ssh unusable; restored PKCS#11 key downloads; fixed CA signing with ssh-agent-held keys.
10.3 2026-04-02 High Shell metacharacter validation too late — Match exec blocks in ssh_config validated user input after %-token expansion, enabling potential command injection in affected configurations.

High ProxyJump/-J injection — hostnames and usernames passed via ProxyJump or -J were not validated for shell metacharacters.

Medium scp setuid/setgid not cleared — legacy mode scp downloads as root did not clear setuid/setgid bits on downloaded files.

Medium PubkeyAcceptedAlgorithms ECDSA bypass — ECDSA algorithm restrictions in PubkeyAcceptedAlgorithms and HostbasedAcceptedAlgorithms were not fully enforced.

Medium authorized_keys principals matching error — comma-separated principals in certificates were matched incorrectly, potentially permitting unintended access. 		Empty certificate principals section no longer treated as wildcard; rekeying compatibility with non-compliant implementations removed; FIDO/WebAuthn certificate signing completed; multiple file support for RevokedHostKeys/RevokedKeys.
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:

CVE Date Added Product Description
CVE-2025-32433 2025-06-09 Erlang/OTP SSH Server Missing authentication for critical function in the Erlang/OTP SSH server — allows unauthenticated remote code execution by exploiting a flaw in SSH protocol message handling. Affects products embedding Erlang/OTP including Cisco, NetApp, and SUSE. Not OpenSSH.
CVE-2026-33634 2026-03-26 Aquasecurity Trivy Embedded malicious code (supply-chain compromise) that could expose SSH keys, cloud credentials, and CI/CD secrets stored in the environment. SSH keys are a target, not the vulnerability surface.
CVE-2025-64328 2026-02-03 Sangoma FreePBX OS command injection via the check_ssh_connect() function in Endpoint Manager. Post-authentication injection by an authenticated user. SSH connectivity is the vector, not an SSH implementation flaw.
CVE-2020-16846 2021-11-03 SaltStack Salt Unauthenticated shell injection via the Salt API SSH client. Attackers with network access to the Salt API could execute arbitrary code using the bundled SSH client. Not an OpenSSH vulnerability.
CVE-2004-1464 2023-05-19 Cisco IOS Unspecified vulnerability that could block SSH, telnet, RSH, and HTTP access to Cisco devices — a denial-of-service affecting Cisco's SSH stack, not OpenSSH.
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 (Primary)

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

Client PQ Hybrid Status Practical Target How to Confirm
OpenSSH Supported in newer versions Use OpenSSH 10.0+ when possible Verbose connect logs show negotiated KEX
PuTTY Confirmed Use 0.83+ Session Event Log shows key exchange algorithm
SecureCRT Not clearly documented Verify by trace/log output in your installed build Enable Trace Options + session log and inspect negotiated SSH details
MobaXterm Confirmed Use 25.2+ MoTTY Event log / SSH debug log shows negotiated KEX

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) Confirm version

Open PuTTY and verify version in About.

2) Connect to target server

Use your normal saved session/host.

3) Open Event Log

Right-click title bar or terminal area and select Event Log.

4) Read negotiated algorithm

Find the key exchange line. Confirm it is mlkem768x25519-sha256 or sntrup761x25519-sha512.

Verify in SecureCRT

1) Turn on trace + logging

Use File -> Trace Options, then File -> Log Session.

2) Optional deep trace

In Session Options -> Log File, set trace level to 9 and enable timestamps.

3) Connect and inspect output

Check terminal trace/log file for negotiated SSH key exchange algorithm details.

4) Interpret result

If no ML-KEM/NTRU hybrid appears, your build or config likely does not negotiate PQ hybrid KEX yet.

Verify in MobaXterm

1) Confirm version

Use a build where the changelog includes ML-KEM support (25.2+).

2) Connect with SSH session

Start your normal SSH session to the server.

3) Open SSH event details

From the terminal context menu, open Event log (MoTTY/PuTTY engine details).

4) Confirm negotiated KEX

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.