How-to: the OpenSSH post-quantum key exchange warning

OpenSSH 10.1 warns when a connection negotiates a classical key exchange. The warning comes from the client and describes the server, it is suppressed entirely by pinning KexAlgorithms, and four algorithm names count as post-quantum rather than two. What to change on each side, how to check what was really negotiated, and how the same transition looks in DoH and TLS.

TL;DR

OpenSSH 10.1 (6 October 2025) prints "connection is not using a post-quantum key exchange algorithm". It is a warning from your client about what the server offered - the session is not blocked.
It fires only when KexAlgorithms is not set. Pin that list, even to an entirely classical one, and the check is skipped permanently - so the configs most likely to be vulnerable are the ones least likely to be told.
Four algorithm names are flagged post-quantum in the OpenSSH source, not two, and the @openssh.com spelling of sntrup761 is the legacy one, not the new one.
Any server on OpenSSH 9.0 (April 2022) or newer with a stock config already satisfies the warning, so "the server may need to be upgraded" is usually not the real problem.
Naming an mlkem algorithm on a build without it is a fatal sshd config error, not a warning - validate with sshd -t and keep a second session open.
The guide bridges to the same migration in TLS and DoH (X25519MLKEM768), including why a stock Ubuntu openssl 3.0 reports a post-quantum endpoint as classical.

Full write-up: Not Using a Post-Quantum Key Exchange: What ssh Is Telling You.