OpenSSH recently started showing a warning whenever you connect using a non–post-quantum key exchange algorithm.

WARNING: connection is not using a post-quantum key exchange algorithm. This session may be vulnerable to “store now, decrypt later” attacks. The server may need to be upgraded. See https://openssh.com/pq.html

---

Checking OpenSSH for Post-Quantum Key Exchange Support

The same command works for both client and server: ssh -Q kex lists all available key exchange algorithms.

$ ssh -Q kex
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256
curve25519-sha256@libssh.org
sntrup761x25519-sha512
sntrup761x25519-sha512@openssh.com
mlkem768x25519-sha256

OpenSSH supports two post-quantum algorithms:

• sntrup761x25519-sha512
• mlkem768x25519-sha256

Enforcing Post-Quantum Key Exchange on the Server

On the server side, I edited /etc/ssh/sshd_config and added a KexAlgorithms line specifying only PQ algorithms:

KexAlgorithms sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,mlkem768x25519-sha256

After saving, restart the SSH service:

sudo systemctl restart sshd

Enforcing Post-Quantum Key Exchange on the Client

The client configuration is very similar. Just add this to /etc/ssh/ssh_config (or ~/.ssh/config if you want it per-user):

KexAlgorithms sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,mlkem768x25519-sha256

After this change, your SSH client will refuse to connect to servers that don’t support post-quantum key exchange—unless you make specific exceptions.

Adding Exceptions for Hosts Without PQ KEX Support

Some well-known services, like GitHub, don’t support post-quantum key exchange yet. If you try to use only PQ algorithms, you’ll get an error like this:

$ git fetch origin
Unable to negotiate with <GITHUB_IP> port 22: no matching key exchange method found.
Their offer: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,...
fatal: Could not read from remote repository.

To work around this, I added a host block for GitHub that appends traditional algorithms:

Host github.com
    KexAlgorithms +curve25519-sha256,curve25519-sha256@libssh.org

The plus sign (+) means these algorithms are added in addition to your default PQ ones, not replacing them.

Is It Mandatory To Force Both Side?

It is not mandatory to enforce post-quantum key exchange on both the client and server, but doing so ensures that the strongest protection is always used for every SSH session. If only one side enforces post-quantum KEX, connections will succeed only with servers or clients that also support and prefer these algorithms; otherwise, negotiation will fall back to weaker, traditional methods or potentially fail to connect.

When Both Sides Enforce PQ KEX

If you configure both your SSH server and all client machines to use only post-quantum key exchange algorithms, every connection between them will always use the strongest available cryptography. This maximizes security and removes the risk of fallback to older, vulnerable methods.

Enforcing on Only One Side

• Enforcing on the server (sshd_config): Only clients that support and offer post-quantum KEX will be able to connect; legacy clients will not negotiate successfully.
• Enforcing on the client (ssh_config): The client will refuse to connect to servers that do not offer post-quantum KEX. Connections to legacy servers will fail unless you specify exceptions.

Practical Recommendation

In practice, enforcing on both sides offers the best guarantee. However, you can start by enforcing on the side you control most (e.g., all your own devices) and add exceptions as needed for specific services not yet supporting PQ algorithms (such as GitHub). This approach is flexible and still improves your overall security.