OpenSSH 10.6: Is Your SSH Post-Quantum Yet?

Somebody may be recording your SSH sessions today, patiently waiting for a quantum computer to read them tomorrow. That threat has a name, harvest now, decrypt later, and OpenSSH 10.6p1, tagged on 6 October 2026, is the release where the post-quantum story visibly grows up: a hybrid ML-KEM key exchange sits first in the defaults, ssh warns when you connect without one, and there is now a hybrid ML-DSA plus Ed25519 key type. This post shows how to check what your SSH connections really negotiate, what the new defaults mean, and how to try the new keys without locking yourself out.

Two different quantum problems

SSH uses public-key cryptography twice, and the two uses have different urgency. The key exchange agrees on the session keys. If an attacker records the traffic now and later breaks the key exchange, they can decrypt the whole recorded session. That is why key exchange is the urgent half, and why hybrids exist: mlkem768x25519-sha256 combines the lattice-based ML-KEM-768 with classic X25519, so an attacker would need to break both.

Signatures, the second use, prove who you are. A forged signature only helps an attacker who has a quantum computer at the time of the login, so the pressure is lower, but keys live for years. The hybrid signature type ssh-mldsa44-ed25519 pairs ML-DSA-44 with Ed25519 in the same spirit.

What the 10.6p1 source says about defaults

Rather than trust a summary, read the source at the V_10_6_P1 tag. In myproposal.h the key exchange list starts with mlkem768x25519-sha256, followed by sntrup761x25519-sha512 (also under its @openssh.com name), curve25519-sha256 and its libssh.org alias, then the three ECDH curves. The client list adds the Diffie-Hellman group exchange and group14, group16 and group18 variants at the end. The ssh_config manual repeats that order and states that the selected algorithm is the first one in the list that the server also supports.

On the signature side, the default public key algorithm list now includes ssh-mldsa44-ed25519 and its certificate form ssh-mldsa44-ed25519-cert, and the sshd_config manual lists /etc/ssh/ssh_host_mldsa44_ed25519_key among the default host keys. The ssh-keygen manual lists mldsa44-ed25519 as a -t key type, with the default file ~/.ssh/id_mldsa44_ed25519, and ssh-keygen -A now generates host keys for rsa, ecdsa, mldsa44-ed25519 and ed25519.

Check what your connections negotiate

Start by seeing what your client supports and what a real connection picks. These commands only read information.

ssh -V
ssh -Q kex | grep -i -E 'mlkem|sntrup'
ssh -Q key | grep -i mldsa

# what the client will actually offer for a host
ssh -G example.com | grep -i -E '^(kexalgorithms|hostkeyalgorithms|warnweakcrypto)'

# what was negotiated on a live connection
ssh -vv user@example.com true 2>&1 | grep -i 'kex: algorithm'

If the last command shows mlkem768x25519-sha256 you are done for that host. If it shows curve25519-sha256, the server probably runs an older OpenSSH that predates the hybrid, or a distribution build without it. That is a server-side upgrade, not a client flag.

The warning, and how to deal with it

The ssh_config manual documents WarnWeakCrypto, which controls whether you are warned when the negotiated algorithms are weak or otherwise recommended against. Warnings about connections that do not use a post-quantum key exchange can be disabled with the no-pq-kex flag, and no switches all warnings off. The default is to enable all of them. The sshd_config manual has a matching option for server-side logging.

# an old appliance that cannot be upgraded yet
Host legacy-nas
    HostName 192.168.1.20
    WarnWeakCrypto no-pq-kex

# everyone else keeps the default behaviour
Host *
    ServerAliveInterval 30

Try an ML-DSA hybrid key safely

Generating the new key type is one command, but both ends must support it. Keep your existing Ed25519 key in place and test the new one in parallel before you retire anything.

ssh-keygen -t mldsa44-ed25519 -f ~/.ssh/id_mldsa44_ed25519 -C "laptop-2026-10"

# offer only the new key for one test connection
ssh -o IdentitiesOnly=yes \
    -o IdentityFile=~/.ssh/id_mldsa44_ed25519 \
    -o PubkeyAcceptedAlgorithms=ssh-mldsa44-ed25519 \
    user@server true

# if that worked, install the public key like any other
ssh-copy-id -i ~/.ssh/id_mldsa44_ed25519.pub user@server

Upgrading the server side without a lockout

Servers choose from what they offer, so the client cannot get a post-quantum exchange from a server that lacks it. After upgrading sshd, validate the config and look at the effective settings before reloading, and test from a second terminal.

sudo sshd -t && echo config ok
sudo sshd -T | grep -i -E '^(kexalgorithms|hostkeyalgorithms)'
sudo systemctl reload ssh      # the unit is called sshd on some distributions

# from another terminal, before closing your current session
ssh -vv user@server true 2>&1 | grep -i 'kex: algorithm'

Takeaway

Treat this as an inventory exercise. Run the negotiation check against every host you manage, upgrade the ones that fall back to curve25519, keep the warning on, and trial the ML-DSA hybrid key alongside your existing Ed25519 key rather than instead of it. The key exchange is the part that protects yesterday's recorded traffic, so do that first.