up:: In the Protocols MOC

PQC in SSH

Post-quantum SSH is the migration of the SSH key exchange from classical elliptic-curve Diffie-Hellman to a hybrid post-quantum key agreement, carried in OpenSSH, the implementation that sets the SSH ecosystem’s posture. It arrived in two moves. First sntrup761x25519-sha512, pairing Streamlined NTRU Prime with X25519, offered by default since OpenSSH 9.0 in April 2022. Then mlkem768x25519-sha256, pairing NIST’s standardized ML-KEM-768 with X25519, added in OpenSSH 9.9 and made the negotiated default in release 10.0 in April 2025. Both are hybrids, so a session stays secure as long as either the classical or the post-quantum half holds. The host-key and user-key signatures that authenticate the two ends are a slower, still-experimental track, because forging a signature needs a live quantum computer at connection time while recorded key exchanges are harvestable today.

Source: OpenSSH, “Post-Quantum Cryptography,” openssh.org/pq.html.

The short version:

• SSH’s key exchange is the harvest-now-decrypt-later exposure, so it migrates first. The signatures that authenticate host and user are Non-HNDL and move later.
• OpenSSH shipped its first post-quantum key exchange, sntrup761x25519-sha512, as an experimental option in release 8.5 (March 2021) and turned it on by default in release 9.0 (April 2022), pairing Streamlined NTRU Prime sntrup761 with X25519.
• The current default, mlkem768x25519-sha256, pairs ML-KEM-768 with X25519. OpenSSH added it in release 9.9 (September 2024) and made it the negotiated default in release 10.0 (April 2025).
• Both are hybrid constructions. OpenSSH’s stated goal is that the combined result is “no worse” than the classical exchange it replaces, so an undiscovered flaw in the young post-quantum scheme doesn’t reduce security below X25519.
• Host and user authentication keys (RSA, ECDSA, Ed25519) are still classical. OpenSSH landed an experimental composite signature type, mldsa44-ed25519, in release 10.4 (July 2026), pairing ML-DSA-44 with Ed25519, but it is a capability to pilot, not to deploy.

Think of an SSH session as a sealed pneumatic tube between two offices. The tube itself carries the message, and the seal on each canister is the key exchange that keeps the contents private. For years the seal was a single classical design. The post-quantum move wraps a second, quantum-resistant seal around the same canister, so an interceptor who copies the tube today and cracks the old seal in a decade still faces the new one. The person who signs the delivery slip at each end, the identity check, is a separate job on a separate schedule, and that slip is still signed the old way while the ecosystem works out its quantum-safe replacement.

What changed in SSH for post-quantum?

The key-exchange algorithm changed, and only the key-exchange algorithm, so far. Everything else about an SSH session, the transport framing, the symmetric ciphers that encrypt the actual data, the authentication flow, stayed the same. SSH negotiates each cryptographic role independently at the transport layer, so swapping the key-exchange method is a matter of both ends agreeing on a new name from their KexAlgorithms lists, with no change to application code or scripts.

The reason key exchange moved first is the two-clock split that governs every protocol in this hub. SSH key exchange based on ECDH or Curve25519 produces a shared secret that Shor’s algorithm recovers on a capable quantum computer, and an attacker can record the handshake and the encrypted session today, then decrypt it years later. That is harvest-now-decrypt-later, and it makes any long-lived secret that ever crossed an SSH session, source code, database credentials, tunneled internal traffic, a present-day liability. The host and user signatures are also quantum-breakable, but a forged signature only helps an attacker live at the moment of a connection, so there is nothing to harvest, and their migration can follow.

Source: OpenSSH, “Post-Quantum Cryptography,” openssh.org/pq.html.

How did OpenSSH’s post-quantum key exchange evolve?

OpenSSH’s post-quantum key exchange has three landmarks: an experimental NTRU Prime hybrid, its promotion to default, and the shift to the standardized ML-KEM hybrid. Walking the timeline shows how the ecosystem tracked the NIST standardization process in real time.

1. Experimental NTRU Prime hybrid (release 8.5, March 2021). OpenSSH 8.5 replaced an even earlier experimental method with sntrup761x25519-sha512@openssh.com, pairing Streamlined NTRU Prime sntrup761 with X25519. It was disabled by default at this stage, offered for testing while the field settled on a post-quantum key-establishment approach.
2. NTRU Prime hybrid becomes default (release 9.0, April 2022). OpenSSH 9.0 turned sntrup761x25519-sha512 on by default, making OpenSSH one of the first widely deployed pieces of infrastructure to negotiate a post-quantum key exchange out of the box, well before NIST finalized its own standard.
3. ML-KEM hybrid added (release 9.9, September 2024). After NIST published FIPS 203 in August 2024, OpenSSH 9.9 added mlkem768x25519-sha256, a hybrid combining ML-KEM-768 with X25519, available by default.
4. ML-KEM hybrid becomes the negotiated default (release 10.0, April 2025). OpenSSH 10.0 made mlkem768x25519-sha256 the default key agreement, OpenSSH’s own reasoning being that it is “considered to be safe against attack by quantum computers, is guaranteed to be no less strong than curve25519-sha256, has been standardised by NIST.”

Source: OpenSSH release notes, openssh.org/releasenotes.html; OpenSSH, “Post-Quantum Cryptography,” openssh.org/pq.html.

OpenSSH release	Date	Post-quantum key-exchange change
8.5	March 2021	sntrup761x25519-sha512 added as an experimental option, disabled by default
9.0	April 2022	sntrup761x25519-sha512 offered by default (first PQ key agreement on by default)
9.9	September 2024	mlkem768x25519-sha256 hybrid (ML-KEM-768 + X25519) added by default
10.0	April 2025	mlkem768x25519-sha256 made the negotiated default key agreement
10.1	October 2025	WarnWeakCrypto config option added
10.4	July 2026	experimental mldsa44-ed25519 composite signature type added

Source: OpenSSH release notes, openssh.org/releasenotes.html.

Why did OpenSSH ship two different post-quantum hybrids?

Because the first hybrid predated a finalized standard and the second one adopted it, and OpenSSH kept both rather than stranding the early adopters. sntrup761x25519-sha512 was chosen in 2021 and 2022, when NIST’s process was still running and no lattice KEM was standardized, so OpenSSH picked Streamlined NTRU Prime, a conservative, well-studied lattice-family scheme its designers favored for its clean security assumptions. When NIST finalized ML-KEM in 2024, OpenSSH added the standardized mlkem768x25519-sha256 and promoted it to default, because a NIST standard is what regulated deployments and interoperability require.

Both remain available, and both are hybrids for the same reason: the classical X25519 half is a hedge. The post-quantum schemes are comparatively young, and pairing each with a battle-tested elliptic-curve exchange means a session’s confidentiality holds even if the lattice scheme is later found to have a flaw, because an attacker would still have to break X25519 too. OpenSSH is explicit that the hybrid is designed so the result is “no worse” than the classical algorithm alone. The hybrid design is the shared safety net across TLS, IPsec, and SSH.

Source: OpenSSH, “Post-Quantum Cryptography,” openssh.org/pq.html.

What is the status of post-quantum host and user keys?

Post-quantum SSH authentication is early and experimental as of mid-2026, and it is deliberately behind key exchange. The host key proves the server is the right machine, and the user key proves the client is an authorized account, and both sign today with RSA, ECDSA, or Ed25519, every one of which Shor’s algorithm breaks once a quantum computer exists. One trap worth naming: Ed25519 is built on Curve25519, but it signs with EdDSA, which Shor breaks the same as any other elliptic-curve signature, so sharing a curve name with X25519 key exchange does not make the signature quantum-resistant.

OpenSSH’s own guidance is that it “will add support for post-quantum signature algorithms in the future.” The first concrete step landed in release 10.4 (July 2026), an experimental composite signature type combining ML-DSA-44 with Ed25519, generated with ssh-keygen -t mldsa44-ed25519. Being composite, it carries a classical and a post-quantum signature together, so a peer validates whichever it understands during the overlap. This is a capability to pilot and watch, because the authentication migration touches the entire trust chain, every known_hosts fingerprint, every SSH certificate authority, and every peer that must accept a new key type, so it moves on a longer timeline than the key-exchange swap.

Source: OpenSSH release notes, openssh.org/releasenotes.html; OpenSSH, “Post-Quantum Cryptography,” openssh.org/pq.html.

What does migrating SSH to post-quantum actually look like?

It looks like getting a capable OpenSSH build across a large, mixed population of endpoints, because a connection is only as quantum-safe as the weaker of its two ends. Both the client and the server have to support the hybrid for a session to negotiate it, and many SSH endpoints are owned by vendors rather than by whoever owns the data. The defining features:

1. Coverage beats capability. A modern client that supports mlkem768x25519-sha256 reaching a server that does not falls back to classical key exchange, and the HNDL window stays open. What closes the exposure is coverage across the whole fleet, not enabling the algorithm on one host.
2. Jump hosts and bastions negotiate down. A bastion sits in the path of every session routed through it, so an old build there that speaks only classical key exchange drags every downstream connection back to a quantum-vulnerable exchange even when both real endpoints are modern. High-traffic intermediaries are the highest-leverage endpoints to upgrade first.
3. Vendor-frozen builds are the real blocker. Network appliances, storage controllers, embedded management planes, and IoT gateways run vendor-locked SSH builds on the vendor’s firmware cadence, not the upstream release cadence, so slow firmware cycles are where the SSH transition stalls.
4. Silent fallback hides the gap. The fallback to classical key exchange is seamless, so a downgraded session looks identical to a protected one. The WarnWeakCrypto option OpenSSH added in 10.1 exists to surface that fallback to operators.

One thing that makes SSH more tractable than TLS: key-exchange negotiation is entirely between the client and server, with no external certificate-authority ecosystem in the loop, so key-exchange migration proceeds incrementally, endpoint by endpoint, without waiting on anyone outside the organization. Underneath, it is a crypto-agility problem: endpoints that can negotiate a new key-exchange method and retire an old one through a routine upgrade migrate cleanly, while endpoints hard-wired to one frozen build have to be replaced or re-flashed first.

Are the post-quantum SSH messages too big for the network?

Mostly no, and this is a real difference from post-quantum TLS. The ML-KEM values in the SSH handshake are larger than a classical X25519 share, but they ride inside the already-negotiated SSH transport framing, so they do not slam into the single-packet ClientHello boundary that trips old middleboxes in TLS. SSH’s larger post-quantum key-exchange messages are carried by a transport that was built to move arbitrary-length packets, so packet-size middlebox failures are far less of a headline for SSH than for TLS.

The failure modes that actually matter for SSH are about coverage rather than size: silent downgrade to classical key exchange when one end can’t do the hybrid, mixed client and server versions across a non-uniform fleet, and vendor-frozen appliances that never receive the capable build. An endpoint stuck on an old build to avoid the hybrid is usually also behind on routine security patches, so the same frozen appliance tends to be both quantum-exposed on key exchange and carrying known non-quantum vulnerabilities, and upgrading fixes both at once.

Source: OpenSSH, “Post-Quantum Cryptography,” openssh.org/pq.html.

Common misconceptions

• “SSH isn’t post-quantum yet.” Its key exchange has been post-quantum by default in OpenSSH since release 9.0 (April 2022) with the NTRU Prime hybrid, and since release 10.0 (April 2025) with the standardized ML-KEM hybrid. The confidentiality channel is one of the most quantum-ready pieces of common infrastructure.
• “The whole of SSH is quantum-safe once I’m on OpenSSH 10.0.” The key exchange is. The host and user authentication keys are still classical RSA, ECDSA, or Ed25519, and post-quantum signatures are experimental, so identity remains quantum-forgeable until that side migrates.
• “sntrup761x25519 and mlkem768x25519 are the same thing.” They are two different hybrids. The first pairs NTRU Prime with X25519 and predates the NIST standard; the second pairs standardized ML-KEM-768 with X25519 and is the current default.
• “Ed25519 keys are quantum-safe because they use Curve25519.” Ed25519 signs with EdDSA, which Shor’s algorithm breaks like any other elliptic-curve signature. Sharing a curve with X25519 key exchange does not make the signature quantum-resistant.
• “Enabling the hybrid is one config flag and I’m done.” The flag is the easy part. A session goes hybrid only when both ends, and every bastion in the path, support the algorithm, so the real work is coverage across every server, client, jump host, and vendor-controlled appliance.

Questions people ask

What is the default post-quantum key exchange in current OpenSSH? mlkem768x25519-sha256, a hybrid of ML-KEM-768 and X25519, the negotiated default since OpenSSH 10.0 in April 2025. The earlier sntrup761x25519-sha512 hybrid, default since 9.0, is still available.

Do I have to change my applications or scripts? No. SSH negotiates the key-exchange algorithm at the transport layer, so gaining the hybrid is a matter of running a capable OpenSSH build on both ends, with no change to application code. You only touch config to force or restrict which algorithms are allowed.

Is post-quantum SSH ready to deploy today? For key exchange, yes. mlkem768x25519-sha256 is standardized on ML-KEM and is the OpenSSH default, so a current build closes the harvest-now-decrypt-later window on the session. Post-quantum authentication is early and experimental, so it is a capability to pilot, not to roll out.

When did OpenSSH first ship a post-quantum key exchange? As an experimental, off-by-default option (sntrup761x25519-sha512) in release 8.5 in March 2021, then on by default in release 9.0 in April 2022, which made OpenSSH one of the earliest widely deployed pieces of infrastructure to negotiate a post-quantum key agreement.

Which is more urgent for SSH, the key exchange or the host keys? Key exchange, clearly. It is harvestable today, so a recorded session is a future liability. Host and user signatures are Non-HNDL and need a live quantum computer to forge, so they are a real but slower-clock problem.

Why can a session silently fall back to a vulnerable key exchange? Classical key-exchange algorithms stay negotiable for backward compatibility, so when one end can’t do the hybrid, the handshake quietly settles on the classical algorithm both share. The session still works and looks normal, which is why OpenSSH’s WarnWeakCrypto option (release 10.1) surfaces it.

What about SSH on network appliances and embedded devices? Those usually run a vendor-controlled build, so they inherit the vendor’s firmware timeline rather than the upstream cadence. That is where the transition stalls, because the operator can’t drive the upgrade directly and a frozen jump host or appliance pulls downstream sessions back to classical key exchange.

Go deeper

The SSH protocol itself, its two-clock structure, and the fleet-wide rollout live in Secure Shell (SSH). The implementation detail, the config knobs, and the FIPS-validation caveats live in the OpenSSH note. The classical scheme in the first hybrid is NTRU Prime (sntrup761), and the standardized scheme in the current default is ML-KEM. The TLS analogue of this exact move is X25519MLKEM768 and the TLS hybrid named groups. The hub that maps this into every other protocol is In the Protocols MOC.

---

Everything here is the map, given freely. When your team needs its SSH fleet, bastion hosts, and vendor-controlled appliances assessed for where the post-quantum key exchange is actually negotiating and where it’s silently falling back, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.