SSH guide · updated 6 November 2026

Post-quantum SSH, and why your Mac may not be using it

OpenSSH has made a post-quantum key exchange its default since 2022, and since April 2025 that default has been mlkem768x25519-sha256. When we connected to GitHub, GitLab and Bitbucket from a Mac this week, though, all three sessions ended up on classical P-256. Here's how to see what your own connections negotiate, why the Mac does this, and the one line in your SSH config that fixes it.

Read the guide Run Quantum Core

Key agreementt = live

10042

mlkem768x25519sntrup761RFC 10042OpenSSH 10

The two post-quantum methods in OpenSSH

OpenSSH ships two hybrid key exchanges. The older one, sntrup761x25519-sha512, pairs Streamlined NTRU Prime with X25519 and has been the default since OpenSSH 9.0 in April 2022. The newer one, mlkem768x25519-sha256, pairs ML-KEM-768 (the lattice scheme NIST standardised as FIPS 203, which I've compared with the signature standards in ML-KEM, ML-DSA and SLH-DSA) with X25519. It arrived in 9.9 and became the default in 10.0.

In August 2026 the IETF published RFC 10042, which defines mlkem768x25519-sha256 for SSH along with two NIST-curve versions, mlkem768nistp256-sha256 and mlkem1024nistp384-sha384. Both halves of a hybrid feed the session key, so someone who wants to read your session has to break the elliptic curve and the lattice scheme together. It's the same idea browsers use for X25519MLKEM768 in TLS.

Why SSH key exchange matters already

Everything private about an SSH session rests on the key agreement at the start. If an attacker records the session today and breaks that agreement once a large quantum computer exists, they can read the whole thing, including any secrets you pasted or files you copied. OpenSSH calls this store now, decrypt later, and it is the same harvest now, decrypt later risk. Host keys are a different matter: they're signatures, and nobody can go back and forge a signature on a handshake that's already finished, so they can wait. That's also why NIST's migration deadlines put key establishment first.

See what your connection negotiates

Run ssh with -v and look for the line that names the key exchange:

ssh -v git@github.com 2>&1 | grep 'kex: algorithm'

If you see mlkem768x25519-sha256 or sntrup761x25519-sha512, the session is post-quantum. Anything else, such as ecdh-sha2-nistp256 or curve25519-sha256, is classical. To see what your client will propose and in what order, use

ssh -G github.com | grep kexalgorithms

The order matters more than people expect. In SSH the server doesn't pick: RFC 4253 says the method chosen is the first one on the client's list that the server also supports. So a server can put ML-KEM at the top of its own list and still end up on P-256 if your client asks for P-256 first.

What we found from a Mac on 6 November 2026

Our test machine runs macOS 26.3.1, and its built-in /usr/bin/ssh reports OpenSSH_10.2p1. We connected to three git hosts, first with the Mac's own settings and then with ML-KEM moved to the front of the client's list.

Host	Post-quantum methods the server offered	Mac defaults	ML-KEM first
github.com	mlkem768x25519, sntrup761x25519	ecdh-sha2-nistp256	mlkem768x25519-sha256
gitlab.com	mlkem768x25519	ecdh-sha2-nistp256	mlkem768x25519-sha256
bitbucket.org	mlkem768x25519	ecdh-sha2-nistp256	mlkem768x25519-sha256

All three servers list mlkem768x25519-sha256 first. The reason the Mac doesn't take it is in /etc/ssh/crypto.conf, a symlink to /etc/ssh/crypto/apple.conf, which the system ssh_config includes. Its comment says it favours higher-performance FIPS algorithms, and it contains KexAlgorithms ^ecdh-sha2-nistp256. The caret puts P-256 at the very front of the list, ahead of both post-quantum methods. The only other profile in that folder, fips.conf, allows P-256 alone.

We also didn't get a warning. OpenSSH 10.1 added one for sessions that aren't post-quantum, and ssh -G shows warnweakcrypto yes on this Mac, but none of our P-256 sessions printed it, so I wouldn't count on that warning to tell you.

The fix, for one user

Add this near the top of ~/.ssh/config:

Host *
  KexAlgorithms ^mlkem768x25519-sha256,sntrup761x25519-sha512

ssh takes the first value it finds for each option, reading the command line, then your own config, then the system file, so your line wins over Apple's. The caret keeps everything else on the list as a fallback for older servers. We ran the same setting with -o on the command line and GitHub and GitLab both negotiated mlkem768x25519-sha256. You don't need new keys, because the change only touches the key exchange and your ed25519 or RSA keys stay as they are.

Servers and the rest of your estate

For your own servers, OpenSSH 9.9 or later supports mlkem768x25519-sha256 and 9.0 or later supports sntrup761x25519-sha512. If you're already on one of those and still see classical sessions, look for a KexAlgorithms line in sshd_config that someone wrote years ago and that leaves both out. If you're held to FIPS-approved curves, RFC 10042's mlkem768nistp256-sha256 is the method written for you, although the Mac's ssh doesn't list it in ssh -Q kex, so check your own builds before planning on it.

The slow part is everything that isn't a terminal: deploy scripts, CI runners, backup jobs and code that opens SSH connections through a library with its own list of algorithms. A CBOM is how you'd record them, and Quantum Core scans a repository on your machine and lists each classical key exchange it finds, with the file and line.

Is sntrup761x25519-sha512 still safe to use?

Yes. OpenSSH counts both hybrids as post-quantum and recommends either. ML-KEM is where the standards are heading, so I'd put it first and keep sntrup761 behind it.

Do I need post-quantum host keys?

Not yet. Host keys prove who the server is at the moment you connect, so a quantum computer built later can't go back and fake an old handshake. Key exchange is what protects recorded sessions.

Will this slow my connections?

It adds bytes, not round trips. The client's share grows from 32 bytes to 1,216 and the server's reply from 32 to 1,120, once per connection.