OpenSSH 10 and Post-Quantum Key Exchange: What Changed and How to Check Your Linux Servers

OpenSSH 10.0, released on 9 April 2025, made a post-quantum hybrid key exchange the default and removed DSA keys entirely. Since then the 10.x series has added a client warning for connections that are not post-quantum, and version 10.6 followed on 6 October 2026. This guide explains what changed, which Debian and Ubuntu releases ship which OpenSSH, and how to check what your own servers and clients actually negotiate.

What changed in OpenSSH 10

• New default key exchange. According to the OpenSSH release notes, 10.0 uses mlkem768x25519-sha256 by default. It combines ML-KEM, which NIST has standardised, with the classical X25519 exchange, so it is no weaker than curve25519-sha256 and is considered safe against attacks by quantum computers.
• DSA removed. 10.0 removes the DSA signature algorithm, which had been disabled by default since 2015.
• Leaner server defaults. sshd no longer offers finite-field Diffie-Hellman (diffie-hellman-group*) by default; the client still supports it. Authentication code also moved into a separate sshd-auth binary, so some log lines now come from that name.
• A warning since 10.1. From 10.1 (6 October 2025) the ssh client warns when a connection does not use a post-quantum key exchange. The WarnWeakCrypto option in ssh_config controls it.

Why the key exchange matters now

The OpenSSH post-quantum page explains the reasoning. The privacy of a whole SSH session depends on the key exchange. Someone who records encrypted traffic today could decrypt it later if a sufficiently powerful quantum computer appears, which is known as "store now, decrypt later". Such computers do not exist yet, but traffic sent today stays exposed unless a post-quantum exchange was used. OpenSSH has offered one by default since 9.0 (April 2022) with sntrup761x25519-sha512, and added ML-KEM in 9.9. Signature keys such as RSA, ECDSA and Ed25519 are a separate, less urgent question, because there is no equivalent of recording traffic to break later.

Which OpenSSH your distribution ships

Upstream versions below come from the Debian package tracker and packages.ubuntu.com; the default lists come from each release's sshd_config(5) manual page.

The client chooses the preference order, so what matters is the pairing. A modern client connecting to an Ubuntu 22.04 server still gets a post-quantum exchange because the server offers sntrup761x25519. An Ubuntu 22.04 client prefers classical X25519 by default, as the OpenSSH 8.9 notes describe. On the enterprise side, the AlmaLinux 9.8 release notes list OpenSSH 9.9p1. Distributions can adjust defaults, so always check the system itself.

How to check a server and a client

# installed versions (Debian/Ubuntu)
dpkg-query -W -f='${Package} ${Version}\n' openssh-server openssh-client

# key exchange methods this client supports
ssh -Q kex

# what the server will offer, after its configuration is applied
sudo sshd -T | grep -i '^kexalgorithms'

# what a real connection negotiated
ssh -v user@server.example.com exit 2>&1 | grep 'kex: algorithm'

ssh -Q kex lists supported key exchange algorithms (ssh(1)), and sshd -T checks the configuration and prints the effective settings (sshd(8)). If the negotiated line shows mlkem768x25519-sha256 or sntrup761x25519-sha512, the session is protected against store-now-decrypt-later.

Optional: require post-quantum key exchange on the server

On Debian 13 or Ubuntu 26.04 you can limit the server to post-quantum methods. Do this only when every client, script and tool that connects is recent enough; older clients, libraries and network devices will fail to connect.

# in /etc/ssh/sshd_config (or a file under /etc/ssh/sshd_config.d/ if it is included)
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com

sudo sshd -t && sudo systemctl reload ssh

Debian 12's sshd does not know mlkem768x25519-sha256, so do not copy this line to bookworm servers. Keep a second session open while you test.

DSA keys and old devices

Debian's trixie release notes state that DSA keys are no longer supported even with the old configuration overrides. If something still logs in with DSA, replace the key before upgrading:

# find DSA keys still in use
ls ~/.ssh/id_dsa* 2>/dev/null
grep -n '^ssh-dss' ~/.ssh/authorized_keys

# create and install an Ed25519 key instead
ssh-keygen -t ed25519
ssh-copy-id user@server.example.com

For an old appliance that only speaks DSA, Debian provides an ssh1 command in the openssh-client-ssh1 package. For a legacy host that triggers the new warning, the OpenSSH page suggests silencing it only for that host, for example Match host legacy.example.com followed by WarnWeakCrypto no-pq-kex in ~/.ssh/config.

What you should do

• Run sshd -T on each server and confirm that a post-quantum method is in the offered list and that no custom KexAlgorithms line removed it.
• Update admin workstations and CI runners: the client decides the preference order, and clients older than OpenSSH 9.0 do not prefer a post-quantum exchange.
• Plan the move from Debian 12 to Debian 13, or from Ubuntu 22.04/24.04 to a release with OpenSSH 10, to get ML-KEM by default.
• Remove any remaining DSA keys from authorized_keys and key stores now, before an upgrade removes support.
• Silence the post-quantum warning per host, never globally, and treat each such host as a device to upgrade.

Sources

• openssh.com/releasenotes.html
• openssh.com/pq.html
• manpages.debian.org/trixie/openssh-server/sshd_config.5.en.html
• manpages.debian.org/bookworm/openssh-server/sshd_config.5.en.html
• manpages.ubuntu.com/manpages/jammy/en/man5/sshd_config.5.html
• manpages.ubuntu.com/manpages/noble/en/man5/sshd_config.5.html
• manpages.ubuntu.com/manpages/resolute/en/man5/sshd_config.5.html
• manpages.ubuntu.com/manpages/resolute/en/man5/ssh_config.5.html
• manpages.debian.org/trixie/openssh-client/ssh.1.en.html
• manpages.debian.org/trixie/openssh-server/sshd.8.en.html
• tracker.debian.org/pkg/openssh
• packages.ubuntu.com/search?keywords=openssh-server&searchon=names&exact=1&suite=all&sec...
• debian.org/releases/trixie/release-notes/issues.en.html
• wiki.almalinux.org/release-notes/9.8.html