Post-quantum SSH

Post-quantum SSH refers to Secure Shell deployments whose key exchange resists quantum attack. OpenSSH has shipped hybrid post-quantum key exchange since 2022: sntrup761x25519-sha512 became the default in OpenSSH 9.0, and the ML-KEM based mlkem768x25519-sha256 became the default in OpenSSH 10.0. Host key authentication, by contrast, still relies on classical signatures.

#Hybrid key exchange in OpenSSH

OpenSSH adopted post-quantum key exchange unusually early. OpenSSH 8.5 (March 2021) introduced sntrup761x25519-sha512@openssh.com, a hybrid of the lattice-based Streamlined NTRU Prime KEM (sntrup761) and the classical X25519 Diffie-Hellman exchange, with both shared secrets hashed together using SHA-512. OpenSSH 9.0 (April 2022) made this hybrid the default key exchange, explicitly to prevent harvest now, decrypt later attacks in which captured SSH sessions are decrypted by a future quantum computer. Notably, this happened before NIST had selected any KEM for standardization, and sntrup761 is not a NIST standard.

After NIST finalized ML-KEM, OpenSSH added a second hybrid. OpenSSH 9.9 (September 2024) introduced mlkem768x25519-sha256, combining ML-KEM-768 with X25519 as described in the IETF draft draft-kampanakis-curdle-ssh-pq-ke. OpenSSH 10.0 (April 2025) then made mlkem768x25519-sha256 the default, citing the advantages of a standardized, faster algorithm while keeping the sntrup761 hybrid available. As of early 2026, a current OpenSSH client connecting to a current server therefore negotiates an ML-KEM hybrid without any configuration.

Administrators who want to require post-quantum key exchange rather than allow silent fallback to classical methods can pin the algorithm list:

# sshd_config or ssh_config: allow only hybrid post-quantum key exchange
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com

#Security properties

In both hybrids the session secret is derived from the classical and post-quantum shared secrets together, so an attacker must break both X25519 and the lattice KEM to recover session keys. This hedges in two directions: Shor's algorithm eventually breaking elliptic curves, and the possibility of cryptanalytic advances against the newer lattice schemes. The design mirrors the hybrid groups used in post-quantum TLS, though SSH combines the secrets with a plain hash rather than the TLS key schedule.

#Terrapin and handshake hardening

The Terrapin attack (CVE-2023-48795, December 2023) showed that the SSH transport protocol allowed an active attacker to silently truncate messages during the handshake, downgrading connection security under some configurations. It was not an attack on post-quantum algorithms, but it landed in the middle of the post-quantum rollout and reinforced that negotiation integrity matters as much as algorithm strength: a handshake that can be downgraded can also be steered away from post-quantum methods. OpenSSH 9.6 addressed Terrapin with a strict key exchange extension that both endpoints must support.

#Host keys and signatures remain classical

SSH authentication (host keys and user keys) still uses classical algorithms: Ed25519, ECDSA, and RSA. As of early 2026 OpenSSH ships no post-quantum host key or user key algorithm, and standardization of ML-DSA based signatures for SSH is at an early stage in the IETF. This is a deliberate ordering rather than an oversight: signatures are only forgeable at the moment of authentication, so recorded traffic gains an attacker nothing, and the migration can wait until Q-Day is plausibly near. The practical consequence is that SSH session confidentiality is already quantum-resistant between updated endpoints, while server impersonation by a future quantum-capable attacker remains a theoretical gap to close in a later phase.

#Interoperability

Key exchange in SSH is negotiated, so the hybrid methods are used only when both endpoints support them; otherwise the connection silently falls back to classical Diffie-Hellman or ECDH. That fallback preserves compatibility but means fleet operators must audit negotiated algorithms, not just installed versions, an instance of the wider cryptographic agility problem. Beyond OpenSSH, several other SSH implementations have added compatible hybrid methods, and the sntrup761 and ML-KEM hybrids are both documented in IETF drafts to keep independent implementations interoperable.