Migrating SSH to post-quantum cryptography: a practical guide

Actualizado: 2026-05-03

OpenSSH 9.9, released in September 2024, closed a long-promised transition: native support for hybrid post-quantum cryptography in the SSH key exchange. With a year of track record, updated clients in most serious distributions, and many companies starting to plan migration, this post gathers the concrete steps and the decisions that avoid surprises.

Key takeaways

• The risk that justifies migrating now is not a quantum attack today, but the store-now, decrypt-later attack.
• OpenSSH 9.9 adds mlkem768x25519-sha256; 10.0 makes it the default exchange when both ends support it.
• The right configuration lists the hybrid algorithm first and keeps curve25519-sha256 as fallback for old clients.
• Existing Ed25519 host keys remain valid; post-quantum signatures (ML-DSA) have not yet landed in OpenSSH.
• Verifying the active algorithm with ssh -v is the most overlooked and most necessary step.

Why migrate now

The reason to migrate SSH to post-quantum is not that a quantum computer will break the connection tomorrow. The reason is the store-now, decrypt-later attack: an adversary capturing SSH traffic today can archive it and, when a quantum computer capable of breaking Diffie-Hellman or ECDH appears, retroactively decrypt the whole session.

This risk does not apply equally to everyone. For everyday SSH to a hobby server, the probability of being a target for selective storage is low. For corporate, financial, or healthcare infrastructure where long-horizon secrets circulate, the calculus shifts. NIST’s recommendation since 2024 is to migrate in any communication with long-term sensitive data, starting now.

What OpenSSH 9.9 and 10.0 bring

The key novelty of 9.9 is native support for ML-KEM-768, the post-quantum standard based on CRYSTALS-Kyber selected by NIST. The implementation is hybrid: it combines ML-KEM with X25519, so the session is safe if at least one of the two algorithms resists. If ECDH falls tomorrow because a quantum computer arrives, ML-KEM protects. If a flaw is found in ML-KEM, X25519 protects.

OpenSSH 10.0, released in April 2025, makes mlkem768x25519-sha256 the default key exchange when both ends support it. If both server and client run 10.0, hybrid mode activates without additional configuration. The log line KEX algorithm: mlkem768x25519-sha256 confirms active protection.

Concrete migration steps

Step 1: update OpenSSH to 9.9 or 10.0 on servers and clients:

• Debian 13 Trixie: OpenSSH 9.9 in default repositories.
• Ubuntu 24.04 LTS: via security update.
• macOS: Homebrew offers a recent version (system OpenSSH lags behind).
• Windows 11: integrated reached 9.5 in 24H2; 10.0 is in 25H1.

Step 2: adjust sshd_config to prioritize hybrid algorithms without dropping compatibility:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

Order matters: modern clients use PQC automatically, those that don’t support it keep connecting over ECDH.

Step 3: verify that the hybrid session actually works. From a modern client, ssh -v server and look for the KEX algorithm line. It must show mlkem768x25519-sha256. If it shows curve25519-sha256, one of the two ends does not support PQC and protection is not active. The difference is silent: the connection works the same but post-quantum encryption is not engaged.

What to break and what not to break

Main risks of a poorly executed migration:

• OpenSSH earlier than 8.5 supports neither sntrup761 nor ML-KEM. If sshd_config requires only PQC, those clients cannot connect. Keeping curve25519-sha256 as fallback resolves this.
• Configuration managers (Ansible, Puppet, Chef) may carry templates with KexAlgorithms inherited from years ago that overwrite configuration silently. Checking real state with ssh -Q kex on the server is the definitive verification.
• Bastion and jump hosts: a session crossing two SSH hops is only post-quantum if each hop is. If the bastion runs 8.9 while the final server has 10.0, the first leg is not protected. Migration must cover the whole chain.

The post-quantum context for TLS follows a similar pattern, covered in PQC and TLS: state of adoption. Supply chain audit strategy covering cryptographic dependencies appears in SBOM and CycloneDX for supply chain.

Performance impact

Hybrid PQC key exchange is more expensive than classical, but only in the initial handshake:

• Additional handshake latency: 5-15 ms on a modern machine (imperceptible for interactive sessions).
• Handshake size: ML-KEM 768 includes 1,184-byte public keys versus 32 bytes for X25519. A hybrid handshake sends about 2 KB more than a classical one.
• For tools opening hundreds of SSH connections per second (mass backups, large-scale Ansible), aggregate cost can be visible and worth measuring.

Final verification and automation

After migration, verification has three components:

1. ssh -Q kex on the server: must include mlkem768x25519-sha256.
2. ssh -v from a real client: the KEX algorithm line must show the hybrid algorithm.
3. Periodic sshd_config audit to detect accidental changes.

An automated test in CI that tries to connect forcing only mlkem768 catches any regression before anyone notices manually. It is a five-line script with real impact.

My read

Migrating SSH to hybrid is reasonable for any server with valuable long-term information. The cost is a few minutes of configuration and a small risk of breaking old clients, mitigated by the classical fallback. The gain is protection against a threat that grows each year.

What makes this migration educational is that it introduces the concept of hybrid algorithm into operational routine. Over the coming years, other protocols will make similar transitions: TLS, IPsec, VPN. Details change, but the pattern is the same: adopt the new algorithm in hybrid mode, verify it works, remove the classical only when compatibility is secured. SSH is the best place to practice that pattern now, before having to apply it to the whole network stack at once.