up:: In the Protocols MOC

OpenSSH

OpenSSH is the dominant open-source implementation of the SSH protocol, and it already defaults to a quantum-resistant hybrid key exchange (mlkem768x25519-sha256, the default since release 10.0 in April 2025), which makes it one of the few widely-deployed pieces of internet infrastructure whose harvest-now-decrypt-later exposure on the confidentiality channel closes with a routine version upgrade.

Built by developers of the OpenBSD Project, it ships the ssh client, the sshd server, and the key tooling (ssh-keygen, ssh-agent, scp, sftp) that run remote administration and automated deployment across effectively every Unix and Linux server, plus Windows and macOS. Because it’s a protocol implementation rather than a general primitive toolkit, it decides which key exchange and signature algorithms an SSH session actually negotiates, so its post-quantum posture is the posture of the whole SSH control plane.

The short version:

• OpenSSH’s key exchange went post-quantum early. It has shipped hybrid post-quantum key agreement on by default since release 9.0 (April 2022), first with sntrup761x25519-sha512, then with mlkem768x25519-sha256 as the default from release 10.0 (April 2025).
• That closes the harvest-now-decrypt-later window on the SSH session channel, because the hybrid folds ML-KEM-768 into the key agreement, and a recorded session stays safe as long as either the classical or the post-quantum half holds.
• Authentication is a separate, much earlier-stage story. Release 10.4 (July 6, 2026) added experimental support for a composite post-quantum signature, mldsa44-ed25519, disabled by default, so SSH host and user keys are only beginning to move to PQC while RSA, ECDSA, and Ed25519 remain the norm.
• The two channels move on different clocks for a reason. Key exchange is HNDL-urgent because a captured session is decryptable later, while a login signature can’t be forged retroactively, so post-quantum authentication is genuinely less urgent and is shipping slower.
• The practical takeaway splits cleanly. The key-exchange side is a version upgrade you can do now, and the authentication side is an experimental capability to watch rather than deploy.

Think of every SSH session as a locked room with two separate guarantees. One is the lock on the door that keeps anyone from watching what happens inside, and the other is the ID check that proves the person at the door is who they claim to be. OpenSSH has already swapped the door lock for a quantum-proof one and turned it on by default. The ID check is still the old kind, and the quantum-proof replacement for it only just arrived as a prototype you can try but shouldn’t rely on yet. Understanding OpenSSH’s post-quantum status is mostly understanding that these two guarantees are on very different schedules.

What is OpenSSH?

OpenSSH (OpenBSD Secure Shell) is the reference implementation of the SSH-2 protocol and the de facto standard SSH stack on the internet. It originated in 1999 as an OpenBSD fork of the last freely-licensed release of Tatu Ylönen’s original SSH, and it’s maintained by developers of the OpenBSD Project under a BSD-style license, with donations directed to the OpenBSD Foundation.

Source: OpenSSH project site, openssh.com.

It ships in two release streams. The OpenBSD-native version tracks the base system, and OpenSSH Portable is the cross-platform build that lands on Linux distributions, macOS, and Windows (bundled since Windows 10 and Server 2019). The portable development tree lives at github.com/openssh/openssh-portable. In practice, OpenSSH is the administrative and automation backbone for server fleets, and a large amount of other tooling either shells out to the ssh binary or depends on it directly.

Source: OpenSSH portability page, openssh.com/portable.html.

Where does cryptography live in an SSH session?

Every SSH connection makes two cryptographic promises, and they sit on different components with different quantum timelines. Keeping them apart is the key to reading OpenSSH’s post-quantum status correctly.

1. Key exchange establishes the shared session keys that encrypt everything typed, transferred, or tunneled over the connection. This is the confidentiality promise, and it’s selected by the KexAlgorithms setting.
2. Authentication proves identity with digital signatures: the host key that proves the server is the right machine, and the user key that proves the client is the right account. These are governed by HostKeyAlgorithms and PubkeyAcceptedAlgorithms.

The reason the distinction is load-bearing is that only one of the two channels carries harvest-now-decrypt-later risk. OpenSSH’s own post-quantum page draws the line plainly: an attacker can record encrypted SSH sessions now and decrypt them later once a quantum computer exists, so the key exchange is urgent, whereas for signatures “there is no analogous store now, decrypt later,” because a login can’t be forged against a session that already happened.

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

How does OpenSSH go post-quantum for key exchange?

OpenSSH went post-quantum on key exchange years ahead of most infrastructure, and it did it the same way TLS did: by pairing a classical key agreement with a post-quantum one so the session survives if either half holds. OpenSSH deploys PQC only in this hybrid form, never post-quantum-alone, so that a flaw discovered in the young lattice scheme can’t by itself compromise a session.

The timeline runs through four releases:

1. Release 8.5 (March 3, 2021) introduced the first hybrid, sntrup761x25519-sha512@openssh.com, combining Streamlined NTRU Prime with X25519, disabled by default.
2. Release 9.0 (April 8, 2022) made that hybrid the default key exchange, the first time a mainstream SSH stack shipped post-quantum key agreement on by default.
3. Release 9.9 (September 19, 2024) added the second hybrid, mlkem768x25519-sha256, combining ML-KEM-768 with X25519, and gave the older NTRU Prime hybrid its IANA-standardized name sntrup761x25519-sha512 (dropping the @openssh.com vendor suffix).
4. Release 10.0 (April 9, 2025) made mlkem768x25519-sha256 the negotiated default, replacing the NTRU Prime-based default. This is now the primary quantum-resistant path.

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

Because SSH negotiates the algorithm at the transport layer, no application change is needed to gain the hybrid. Upgrade the OpenSSH package to a 10.0-or-later build and the quantum-resistant key exchange is already the default, and both endpoints have to be on a capable release for the hybrid to negotiate. Operators who want to force it can pin KexAlgorithms mlkem768x25519-sha256 in ssh_config and sshd_config. This is the config-selectable side of crypto-agility: the new algorithm arrives via a binary upgrade, and the config decides whether it’s required or merely available.

There’s a residual exposure worth naming. A classical-only key exchange (plain ECDH or X25519) is still negotiable, so a session with an un-upgraded peer can silently fall back to a quantum-vulnerable exchange. Release 10.1 (October 6, 2025) added a warning when a non-post-quantum key agreement is negotiated, precisely to flag that residual HNDL exposure to operators.

Source: OpenSSH release notes 10.1, openssh.com/releasenotes.html.

What changed for authentication in OpenSSH 10.4?

Release 10.4 (July 6, 2026) added experimental support for a composite post-quantum signature scheme, mldsa44-ed25519, which pairs ML-DSA-44 with Ed25519, with keys generated via ssh-keygen -t mldsa44-ed25519. It’s disabled by default and flagged experimental by the project, pending further standardization. This is the first time OpenSSH has shipped any post-quantum host-key or user-key signature type at all, so it marks the very start of the SSH authentication channel moving to PQC.

Source: OpenSSH release notes 10.4, openssh.com/releasenotes.html.

The register matters here. “Experimental and disabled by default” is not the same as “shipped and on,” which is exactly where the key-exchange hybrid sits. The composite signature exists so people can begin generating and testing post-quantum SSH keys, and the surrounding ecosystem (certificate tooling, agents, and every peer that has to accept the new key type) is still years from being ready. Until that catches up, RSA, ECDSA, and Ed25519 host and user keys remain the norm across the fleet, and that’s the expected state of a mid-2026 deployment, not a red flag.

What’s the practical takeaway for the two channels?

The honest summary is that OpenSSH is two migrations at two very different stages, and lumping them together is how people get the risk wrong. The key-exchange side is essentially solved and deployable; the authentication side is a prototype to track.

1. Key exchange is a version upgrade. Getting to a 10.0-or-later build gets you the ML-KEM hybrid as the default, which closes the harvest-now-decrypt-later window on the SSH session channel. This is one of the cleanest good-news stories in the whole post-quantum transition, because the hard cryptographic and standards work is already done and shipped.
2. Authentication is a watch-and-wait. The post-quantum signature path is experimental as of 10.4, so it’s something to understand and pilot, not something to roll out. The urgency is genuinely lower, because there’s no store-now-decrypt-later analogue for a login signature.

The mechanism behind that asymmetry is the HNDL versus Non-HNDL distinction. SSH sessions carry long-lived secrets (source code, credentials, database dumps, tunneled internal traffic) that stay sensitive for years, so a recorded session is a real future liability the day a cryptographically relevant quantum computer arrives. A forged host or user signature only helps an attacker in real time, once the machine exists, so it can’t be executed retroactively against traffic captured today.

Which PQC algorithms does OpenSSH ship, and what’s their status?

OpenSSH ships three post-quantum-relevant constructions, all hybrid or composite, spanning both channels. The status column is the one that matters, because “default” and “experimental” are worlds apart in what you can rely on.

Construction	Channel	Post-quantum part	Classical part	Status	First shipped / default
mlkem768x25519-sha256	Key exchange	ML-KEM-768	X25519	Default	Added 9.9 (Sep 2024); default since 10.0 (Apr 2025)
sntrup761x25519-sha512	Key exchange	Streamlined NTRU Prime (sntrup761)	X25519	Supported, was default 9.0 to 10.0	Introduced 8.5 (Mar 2021); default 9.0 (Apr 2022)
mldsa44-ed25519	Authentication	ML-DSA-44	Ed25519	Experimental, disabled by default	Added 10.4 (Jul 2026)

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

Two facts about status carry weight:

1. The deployed forms are combined constructions. mlkem768x25519-sha256 and mldsa44-ed25519 are hybrids, not the standalone NIST-approved algorithms on their own, so their approval status has to be evaluated against NIST hybrid guidance rather than assumed from the fact that ML-KEM-768 is FIPS 203 and ML-DSA-44 is FIPS 204.
2. OpenSSH holds no module certificate. It is not itself a FIPS-validated cryptographic module and carries no CMVP certificate of its own, so in a regulated deployment its FIPS posture is inherited from the underlying platform crypto or a vendor build rather than from OpenSSH. [OPERATOR VERIFY: no CMVP module certificate attributable to OpenSSH shipping this specific hybrid is confirmed as of 2026-07-09; verify per vendor build.]

What are the deployment realities?

The rule that governs all applied PQC holds here: a protocol is only as quantum-safe as its weakest deployed endpoint. Both ends of an SSH connection have to be on a capable release for the hybrid to negotiate, so the migration is a fleet-wide rollout tracked endpoint by endpoint, not a single switch.

1. Both endpoints must be upgraded. The hybrid only negotiates when the client and server both support it. A modern client talking to a frozen legacy server still falls back to classical key exchange.
2. Version string is the fastest tell. A build older than 9.9 has no ML-KEM hybrid available at all, 9.9 has it available but not default, and 10.0-or-later has it as the default. That single fact places any endpoint on the timeline.
3. Vendor-frozen builds are the real blocker. Many SSH endpoints are network appliances, embedded management planes, and IoT gateways that run older or vendor-locked OpenSSH builds. Those inherit the vendor’s upgrade cadence rather than the upstream one, and slow firmware cycles are where the SSH transition actually stalls, not in the OpenSSH codebase.
4. Patching hygiene and PQC posture overlap. The 8.5-to-9.7 version band that lacks the ML-KEM default is the same band affected by the 2024 regreSSHion vulnerability (CVE-2024-6387, a sshd signal-handler race that can lead to unauthenticated remote code execution), so an endpoint stuck there is both quantum-exposed on key exchange and behind on routine security patching.

Source: OpenSSH release notes, openssh.com/releasenotes.html; NVD, CVE-2024-6387.

Common misconceptions

• “OpenSSH isn’t post-quantum yet.” Its key exchange has been post-quantum by default since release 9.0 in April 2022, and the current ML-KEM hybrid has been the default since 10.0 in April 2025. The confidentiality channel is one of the most PQC-ready pieces of common infrastructure.
• “OpenSSH 10.4 makes SSH logins quantum-safe.” It adds an experimental, disabled-by-default composite signature so people can start testing post-quantum keys. It’s a prototype, not a production authentication path, and RSA, ECDSA, and Ed25519 keys remain the norm.
• “Upgrading one server is enough.” The hybrid only negotiates when both endpoints support it, so a capable server talking to a legacy client still falls back to classical key exchange. The migration is fleet-wide.
• “ML-KEM in OpenSSH means it’s FIPS-validated.” OpenSSH carries no CMVP module certificate, and the deployed construction is a hybrid rather than a standalone NIST-approved algorithm, so a FIPS claim has to trace to a specific validated vendor build, not to the presence of ML-KEM in the code.
• “Classical-only key exchange is off once I upgrade.” Classical groups stay negotiable for backward compatibility, so a session can quietly fall back to a quantum-vulnerable exchange with an old peer. Release 10.1 added a warning when that happens for exactly this reason.
• “The hybrid is a permanent design.” The classical X25519 half is the exact thing a quantum computer breaks, so it’s carried as a transitional hedge and is meant to retire once the post-quantum scheme is trusted alone. A hybrid that never sheds its classical half is running dead weight.

Questions people ask

Is my SSH traffic quantum-safe if I’m on a current OpenSSH? For key exchange, yes on any 10.0-or-later build, where mlkem768x25519-sha256 is the default and closes the harvest-now-decrypt-later window on the session. The authentication signatures (host and user keys) are still classical unless you’ve opted into the experimental 10.4 path, and that’s the expected state for now.

What’s the difference between the key-exchange fix and the authentication fix? Key exchange protects the confidentiality of the session and is HNDL-urgent, because recorded traffic is decryptable later. Authentication proves identity and is not HNDL-exposed, because a signature can’t be forged retroactively. That’s why OpenSSH shipped the key-exchange hybrid on by default years ago and only added an experimental authentication option in mid-2026.

Do I have to change my applications or scripts to get it? No. SSH negotiates the algorithm at the transport layer, so upgrading the OpenSSH package is enough for the key-exchange hybrid to become the default, with no change to your application code. You only touch config if you want to force or restrict specific algorithms.

Which OpenSSH version do I need? For the ML-KEM hybrid as the default, release 10.0 (April 2025) or later. Release 9.9 has it available but not default, and anything earlier has no ML-KEM hybrid at all (though 9.0 and up still default to the older sntrup761x25519-sha512 post-quantum hybrid).

Should I deploy the new post-quantum SSH keys from 10.4? Not for production. The mldsa44-ed25519 composite signature is experimental and disabled by default, and the surrounding tooling and peer support aren’t ready, so it’s a capability to pilot and understand, not to roll out.

Why is post-quantum SSH authentication so far behind key exchange? Partly urgency and partly ecosystem. There’s no store-now-decrypt-later risk on a login signature, so the pressure is genuinely lower, and post-quantum signatures also depend on a wider chain of certificate tooling, agents, and peers that all have to accept the new key type before it’s usable.

What about SSH on network appliances and embedded devices? Those usually run a vendor-controlled OpenSSH build, so they inherit the vendor’s firmware timeline rather than the upstream release cadence. That’s where the SSH transition tends to stall, because the operator can’t drive the upgrade directly and has to manage it as a vendor dependency.

Is sntrup761x25519-sha512 still safe to use? Yes. It’s a supported hybrid that was the default from release 9.0 until 10.0, and it still provides post-quantum key agreement. The default moved to the ML-KEM hybrid because ML-KEM is the NIST-standardized scheme, but the NTRU Prime hybrid remains a valid post-quantum choice.

---

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

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