# Resolving the OpenSSH Post-Quantum Key Exchange Warning

**URL:** <https://forum.gnoppix.org/t/resolving-the-openssh-post-quantum-key-exchange-warning/7763>\
**Category:** How2's\
**Created:** [October 30, 2026, 3:33am UTC](https://forum.gnoppix.org/t/resolving-the-openssh-post-quantum-key-exchange-warning/7763 "2026-10-30T03:33:11Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![amu](https://forum.gnoppix.org/user_avatar/forum.gnoppix.org/amu/32/7_2.png) [@amu](https://forum.gnoppix.org/u/amu)\
**Post date:** [October 30, 2026, 3:33am UTC](https://forum.gnoppix.org/t/resolving-the-openssh-post-quantum-key-exchange-warning/7763/1 "2026-10-30T03:33:11Z")

</div>

# 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

```auto
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

```auto
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

```auto
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

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

```

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

Bash

```auto
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

```auto
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

```auto
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

```auto
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.