OpenSSH post-quantum defaults and the non-post-quantum key-exchange warning

Goal

Status as of 25 October 2026. Resolve a non-post-quantum key-exchange warning by checking the actual peers and their settings. Re-check the OpenSSH post-quantum guidance, installed package documentation and effective configuration before changing policy. The version milestones below describe upstream features, not the latest security patch level.

OpenSSH's guidance records a post-quantum default from 9.0, initially using the sntrup hybrid. Support for mlkem768x25519-sha256 arrived in 9.9 and became the default in 10.0. OpenSSH 10.1, released on 6 October 2025, introduced a warning when a connection selects a non-post-quantum exchange.

Prerequisites

Have an authorized test account, access to both peers' configuration, and an existing administrative session or console for recovery. The warning concerns protection against future decryption of recorded traffic. It does not by itself establish interception, compromise, or a failed host-key check.

Steps

1. Identify the actual SSH implementation at each endpoint, including appliances and embedded Git services. Run ssh -V on the client. A similarly named package or the client's version cannot establish what a remote service supports.

2. Inspect local capability with ssh -Q kex, then inspect the settings applied to the actual destination:

   ssh -G server.example
   

   Review kexalgorithms and applicable host-specific settings. The query of supported algorithms is not the effective allowlist, and neither is the negotiated result.

3. On an OpenSSH server, use sshd -T with sufficient privileges to inspect the effective configuration. Use its -C connection parameters when relevant conditional settings need evaluation. Review included files and centrally managed restrictions before editing anything.

4. Prefer supported vendor updates and removal of obsolete restrictions that suppress hybrid algorithms. Older peers may advertise sntrup761x25519-sha512@openssh.com; the 9.9 release notes explicitly add the unqualified sntrup761x25519-sha512 name. This is more precise than the naming shorthand in the post-quantum overview. A peer using the older hybrid need not be classified as classical-only simply because it lacks ML-KEM. Confirm the exact names accepted by each build.

5. Validate an edited server configuration with sshd -t before the platform's normal reload procedure. Keep the recovery session open. Establish a separate connection without reusing a multiplexed session:

   ssh -vv -S none server.example
   

   Read the selected key-exchange algorithm in the diagnostic output and verify normal host authentication and login. Close the test session when finished. Avoid posting unredacted diagnostic logs containing hostnames or account information.

6. If an old peer cannot be upgraded yet, document its owner, data sensitivity and replacement plan. Leave the warning visible unless a reviewed, narrowly scoped exception is necessary. Silencing WarnWeakCrypto changes reporting; it does not upgrade cryptography.

Expected result

A new connection selects an allowed hybrid exchange, or an explicitly recorded legacy exception remains. Existing clients still connect as intended, and host-key verification remains enforced.

Limits and test basis

This procedure is based on upstream documentation, not a tested fleet. Downstream packaging and policy can differ. Do not disable strict host-key checks, remove authentication controls, or replace user keys merely to address a key-exchange warning. A successful hybrid exchange is evidence about that connection's key agreement, not a claim that every authentication mechanism is post-quantum.