Quantum-Safe SSH: Migration Options for Enterprise Access

Quick answer: SSH’s key exchange has been post-quantum capable since OpenSSH 9.0 in April 2022, first through the sntrup761x25519-sha512 hybrid, then through the NIST-standardized mlkem768x25519-sha256 hybrid, made the default in OpenSSH 10.0. A current OpenSSH client connecting to a current server already negotiates quantum-resistant key exchange with no configuration required. Host keys and user authentication keys are a separate story: SSH host and user keys remain classical (Ed25519 or RSA) today, since post-quantum signature standardization for SSH is still in progress at the IETF. This guide covers what to migrate now, what to wait for, and how to build the inventory and rollback plan around jump hosts and automation.

SSH is one of the quieter post-quantum success stories: its key exchange has been quantum-resistant, by default, for longer than most organizations realize. The part that actually needs planning is not key exchange, it is host and user key authentication, which remains entirely classical and has no finalized standards path yet. This guide separates the two clearly.

Key Takeaways

• OpenSSH has shipped hybrid post-quantum key exchange by default since version 9.0 (April 2022), initially via sntrup761x25519-sha512.
• OpenSSH 9.9 added the NIST-standardized mlkem768x25519-sha256 hybrid, which became the default in OpenSSH 10.0 (April 2025).
• OpenSSH 10.1 began warning users when a connection negotiates a non-post-quantum key exchange, signaling that the ecosystem now treats classical-only key exchange as the exception, not the norm.
• Host keys and user authentication keys remain classical (Ed25519 or RSA); post-quantum signature standardization for SSH authentication is still in progress at the IETF.
• The sntrup761x25519-sha512 hybrid was formally standardized as RFC 9941 in April 2026, giving the earlier, pre-NIST hybrid a durable standards footing alongside the newer ML-KEM option.

Key Exchange: Already Solved for Current Software

SSH key exchange has quietly been ahead of most protocols on post-quantum migration. OpenSSH 9.0 shipped the sntrup761x25519-sha512 hybrid, combining Streamlined NTRU Prime with classical X25519, as the default key exchange algorithm back in April 2022, years before NIST finalized ML-KEM. OpenSSH 9.9 added mlkem768x25519-sha256, combining the now-standardized ML-KEM-768 with X25519, and OpenSSH 10.0 made it the new default in April 2025. As of OpenSSH 10.1, connecting without negotiating one of these post-quantum hybrids now triggers an explicit warning: “This session may be vulnerable to store now, decrypt later attacks.”

The practical result: a current OpenSSH client connecting to a current OpenSSH server negotiates quantum-resistant key exchange automatically, with zero configuration required. The sntrup761x25519-sha512 hybrid also gained a formal standards footing in April 2026 as RFC 9941, and a parallel IETF SSHM working group draft is defining the equivalent standard for the ML-KEM hybrid.

SSH key inventory and lifecycle automation for exactly this kind of environment is where SSH Secure fits, discovering keys across your server and automation fleet before a migration deadline forces a rushed audit.

Host and User Keys: The Part Still Waiting on Standards

This is the distinction that matters most for planning. SSH host key authentication, the mechanism that proves a server is who it claims to be, and user key authentication, the mechanism that proves a client’s identity, both still rely entirely on classical algorithms: Ed25519 or RSA. Neither has a finalized post-quantum replacement in mainline OpenSSH, and standardization of ML-DSA-based signatures for SSH remains at an early stage in the IETF.

This is a deliberate sequencing, not an oversight, and it follows the same logic covered in our hybrid PQC decision framework: key exchange is close to a self-contained library change, while signature migration touches a much broader surface, key generation and distribution tooling, host key verification workflows, and every automation script that currently expects an Ed25519 or RSA key format.

OpenSSH Support Across Platforms

Support timing varies by distribution. Red Hat Enterprise Linux 10 shipped with OpenSSH 9.9, and RHEL 10.1 made mlkem768x25519-sha256 the preferred default unless explicitly configured otherwise. RHEL 10.2 went further, adding FIPS-compatible hybrid options, mlkem768nistp256-sha256 and mlkem1024nistp384-sha384, through downstream patches, since upstream OpenSSH’s maintainers chose not to implement NIST-curve variants directly. Organizations operating under FIPS requirements should confirm which specific hybrid their platform and distribution actually support, since FIPS compliance depends on the exact curve and hash combination, not just “post-quantum support” as a general claim.

Not every SSH client implementation has caught up. Some built-in or embedded SSH clients, particularly in older network appliances or specialized tooling, do not yet support post-quantum key exchange at all, which makes an inventory of actual client versions, not just server versions, an essential step before assuming an environment is fully covered.

Jump Hosts, Automation, and Inventory

SSH’s operational footprint makes discovery harder than a typical TLS migration. Keys and trust relationships are frequently embedded in places that do not show up in a simple server inventory: jump host configurations that chain multiple SSH hops, CI/CD pipeline credentials, infrastructure-as-code tooling that provisions SSH access programmatically, and long-lived automation scripts with hardcoded host key fingerprints or key file paths.

Building an accurate inventory means covering all of these, not just interactive user sessions: every jump host and the hop chains that depend on it, every automated process that establishes an SSH connection, and every hardcoded reference to a specific key algorithm or file format that a future host key migration would break.

Rollback Considerations

Key exchange rollback is low-risk by design: pinning a specific KexAlgorithms preference order, with classical algorithms listed as fallback entries, lets an environment gracefully accommodate older peers while still preferring the post-quantum hybrid wherever both sides support it. Host key rollback, once post-quantum signature options do standardize and ship, will carry more operational weight, since host key changes trigger known-hosts warnings and can break automation that pins specific key fingerprints, which is exactly why building the jump-host and automation inventory now, ahead of that migration, is worth doing before the pressure of a deadline forces it.

What We’d Actually Recommend

Upgrade to a current OpenSSH release across your server and client fleet now; the quantum-resistant key exchange benefit is immediate and requires no further decision-making once the software is current. Explicitly pin KexAlgorithms with the post-quantum hybrid preferred and classical options as fallback, rather than relying on implicit defaults that vary by version. Build the jump-host and automation inventory now, while host keys are still classical and stable, so the eventual host key migration has an accurate map to work from instead of starting from scratch under deadline pressure.

How Encryption Consulting Can Help

The jump-host chains, automation scripts, and hardcoded key references that make SSH migration harder than it looks are exactly the discovery gap SSH Secure, Encryption Consulting’s dedicated SSH key management platform, is built to close, discovering and inventorying SSH keys across servers, jump hosts, and automation tooling and automating the key lifecycle so the eventual host key migration starts from a real, current inventory rather than institutional memory.

Our PQC Advisory Services build that inventory into a migration plan now, sequencing the immediate OpenSSH upgrade and KexAlgorithms configuration work against the future host key migration, so your organization is ready to move quickly once post-quantum SSH signature standards finalize rather than starting the discovery process from zero at that point.

One Problem Solved, One Still Coming

SSH key exchange has quietly been quantum-resistant by default for years, and the only action most organizations need to take is making sure their OpenSSH version is current. Host and user key authentication is the real remaining work, and it is not yet actionable in the same way, since the standards it depends on have not finalized. The organizations that will move fastest once they do are the ones building an accurate map of jump hosts, automation, and key dependencies now, while there is no deadline pressure forcing a rushed inventory later.

Frequently Asked Questions

Is SSH already quantum-resistant?

Key exchange is, on current OpenSSH versions, by default since OpenSSH 9.0. Host key and user authentication are not; both remain classical Ed25519 or RSA pending IETF standardization of post-quantum SSH signatures.

Do I need to do anything to get post-quantum SSH key exchange?

If both client and server run OpenSSH 9.0 or later, hybrid post-quantum key exchange negotiates automatically with no configuration. Running OpenSSH 10.0 or later gets you the NIST-standardized ML-KEM hybrid as the default rather than the earlier sntrup761 hybrid.

Why hasn’t SSH host key authentication moved to post-quantum algorithms yet?

Standardization of ML-DSA-based signatures for SSH is still at an early stage in the IETF. This mirrors the broader pattern where key exchange migrates faster than signatures, since signature migration touches key generation, distribution, and verification workflows across an entire environment rather than a single library update.

What should organizations do now if host keys aren’t ready to migrate?

Build an inventory of jump hosts, automation pipelines, and hardcoded key references now. This is the discovery work a future host key migration will need regardless of which standard eventually finalizes, and doing it ahead of a deadline avoids a rushed, incomplete inventory later.

Does FIPS compliance affect which post-quantum SSH key exchange option to use?

Yes. FIPS-compliant environments need the specific NIST-curve hybrid variants, such as mlkem768nistp256-sha256, rather than the X25519-based hybrids that mainline OpenSSH ships by default. Confirm which variant your specific platform and distribution support before assuming general post-quantum support satisfies FIPS requirements.