Short answer: According to the OpenSSH project, OpenSSH has offered post-quantum key agreement by default since release 9.0 (April 2022), first with the hybrid sntrup761x25519-sha512 and, since 9.9, also with mlkem768x25519-sha256, which became the default in 10.0 (April 2025). Both are hybrids that pair a post-quantum algorithm with classical X25519. This article describes what the OpenSSH project and an IETF RFC say, and we have not tested any of it.

What the OpenSSH project says

The OpenSSH page on post-quantum cryptography says OpenSSH supports a number of key agreement algorithms considered safe against attacks from quantum computers, and recommends that all SSH connections use them. Key agreement matters because an attacker can record encrypted traffic today and try to decrypt it later with a quantum computer.

The page gives this timeline:

  • OpenSSH 9.0 (April 2022): post-quantum key agreement offered by default, initially through sntrup761x25519-sha512.
  • OpenSSH 9.9: a second algorithm, mlkem768x25519-sha256, added.
  • OpenSSH 10.0 (April 2025): mlkem768x25519-sha256 made the new default.
  • OpenSSH 10.1: a warning when a connection uses a key agreement scheme that is not post-quantum. The page says it can be disabled with the WarnWeak option in ssh_config.

What "hybrid" means here

The OpenSSH 9.9 release notes describe mlkem768x25519-sha256 as a hybrid post-quantum key exchange based on the FIPS 203 Module-Lattice Key Encapsulation mechanism (ML-KEM) combined with X25519 elliptic-curve Diffie-Hellman. The older sntrup761x25519-sha512 combines Streamlined NTRU Prime, a small lattice-based key-encapsulation mechanism, with X25519 and SHA-512. RFC 9941 describes the sntrup761 hybrid for SSH.

Combining a newer algorithm with a well-known classical one means the exchange is not weaker than the classical method alone. RFC 9941 puts it this way: since sntrup761x25519-sha512 is expected to offer no reduction of security compared to curve25519-sha256, it is recommended that it is used and preferred whenever curve25519-sha256 is used, if the extra communication size and computational requirements are acceptable.

Naming and compatibility

RFC 9941 notes that some earlier implementations may only know the sntrup761 method by the name sntrup761x25519-sha512@openssh.com, and recommends announcing and accepting that name as an alias to improve the chance of negotiating it. The OpenSSH 9.9 notes say the algorithm now also has an IANA-assigned name, sntrup761x25519-sha512, alongside the vendor name.

What this does not tell you

This covers key agreement in OpenSSH as described by its own documentation. It says nothing about server signatures or host keys, about other SSH software, or about how any particular organisation configures its systems. Version behaviour is as stated by the OpenSSH pages and may change.

FAQ

Does OpenSSH support post-quantum key exchange?

Yes, according to the OpenSSH project. It has been offered by default since release 9.0 in April 2022.

Which algorithms does it use?

sntrup761x25519-sha512 first, then mlkem768x25519-sha256 from OpenSSH 9.9. The ML-KEM hybrid became the default in 10.0.

What does hybrid mean?

A post-quantum algorithm is combined with classical X25519, so the exchange is expected not to be weaker than the classical method alone.

Will OpenSSH warn about non-post-quantum connections?

The OpenSSH page says OpenSSH 10.1 warns the user when a non-post-quantum key agreement scheme is selected, and that the warning can be disabled with WarnWeak.

Is there a standard for this in SSH?

RFC 9941 describes key exchange based on a hybrid of sntrup761 and X25519 with SHA-512 in SSH.

All field notes