Resolving the OpenSSH Post-Quantum Key Exchange Warning

How2's
1

Your ssh client warns that the connection is not using a post-quantum key exchange.

When your SSH client outputs a notification stating that the connection lacks a post-quantum key exchange algorithm, it indicates that the cryptographic handshake negotiated with the remote host relies exclusively on classical math. While your data remains fully encrypted today, this warning highlights a forward-looking risk: encrypted sessions captured by an adversary right now could potentially be decrypted years down the road once a sufficiently powerful quantum computer materializes. OpenSSH categorizes this threat under the “store now, decrypt later” vector.

Because modern distributions and OpenSSH releases have raised the bar for default security postures, addressing this warning requires isolating whether the bottleneck resides on your client workstation or the remote server.

Understanding the Post-Quantum Key Exchange Warning

Key exchange (KEX) is the foundational phase where both endpoints establish shared symmetric session keys prior to authentication. This exchange safeguards every subsequent packet, including your credentials and private keys.

Starting with OpenSSH 10.1, the client binary includes a built-in alert triggered by the WarnWeakCrypto configuration option (enabled by default) whenever a connection falls back to classical cryptography.

Two crucial details govern this diagnostic:

  1. The client triggers the alert: Because ssh emits the warning rather than the remote sshd daemon, server administrators managing legacy endpoints will not see the message locally.

  2. Version dependencies matter: Older client builds predate the warning mechanism entirely, remaining silent even when negotiating classical curves. Newer releases on environments like Gnoppix 26 ship with OpenSSH 10.2p1 or higher, actively surfacing the notification. Conversely, baseline releases such as Gnoppix 24 bundle older OpenSSH iterations, keeping the client output quiet until packages are upgraded.

Auditing Your Client Capabilities

Before modifying configurations, inspect your local client capabilities to verify whether post-quantum algorithms are available in your build.

Bash

ssh -V
ssh -Q kex

  • ssh -V reveals your exact OpenSSH release and build metadata (e.g., `OpenSSH_10.2p1 Gnoppix-2gnoppix

  • 3.8`).

  • ssh -Q kex dumps every key exchange method recognized by your binary.

Look specifically for hybrid post-quantum entries such as mlkem768x25519-sha256 or sntrup761x25519-sha512@openssh.com. If these algorithms are absent, your local OpenSSH package requires an update.

To determine which algorithm an active connection actually negotiates, run verbose debugging against a target host:

Bash

ssh -vv user@server.example.com 2>&1 | grep 'kex: algorithm'

A successful post-quantum handshake outputs a line matching debug1: kex: algorithm: mlkem768x25519-sha256. If a classical cipher appears instead, the negotiation fell back, triggering the client warning.

Evaluating Server-Side Configuration

Inspecting the remote server requires querying sshd directly for its effective runtime configuration rather than manually parsing flat configuration files.

Bash

sudo sshd -T | grep -i '^kexalgorithms'

Extended test mode (sshd -T) evaluates all parsed directives, including modular drop-ins located under /etc/ssh/sshd_config.d/. On systems like Gnoppix, drop-in files often take precedence due to configuration ordering. If the active KEX list omits mlkem or sntrup, hardened configuration templates or older software versions are restricting the exchange.

Implementing the Server-Side Fix

To resolve the warning cleanly on servers you control, avoid editing /etc/ssh/sshd_config directly. Instead, create a dedicated drop-in configuration file:

Bash

ssh -Q kex | grep -E 'mlkem|sntrup' | paste -sd,

Using the supported algorithms reported by your system, write a new drop-in file:

Bash

sudo tee /etc/ssh/sshd_config.d/60-pq-kex.conf >/dev/null <<'EOF'
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256
EOF

Always validate your configuration syntax before restarting services:

Bash

sudo sshd -t

If sshd -t exits silently with a status of 0, the configuration is valid. Reload the daemon safely while keeping your existing terminal session active:

Bash

sudo sshd -t && sudo systemctl reload ssh

On environments utilizing systemd socket activation, the daemon parses configuration updates dynamically on each incoming connection.

Client-Side Overrides and Managing Legacy Endpoints

When connecting to third-party hardware or immutable network appliances that lack post-quantum support, you can selectively suppress the warning in your user configuration (~/.ssh/config):

Code snippet

Host legacy-switch.example.net
    WarnWeakCrypto no

Alternatively, use WarnWeakCrypto no-pq-kex to mute only the post-quantum notification while retaining alerts for other cryptographic weaknesses. Avoid applying broad wildcards (Host *), as doing so obscures regressions across your entire infrastructure.

Summary of Threat Modeling

A post-quantum key exchange specifically mitigates passive bulk decryption of recorded ciphertext. It does not replace fundamental hygiene practices such as robust private key management, strict file permissions, and disabling password authentication. By upgrading your key exchange protocols across modern Gnoppix deployments, you future-proof your administrative channels against tomorrow’s computational threats.