SSH Post-Quantum Cryptography Configuration Guide

This guide explains how to configure SSH to use post-quantum cryptography and suppress related warnings.

Understanding the Warning

When connecting via SSH, you might see:

** 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

This warning indicates that your SSH connection uses traditional cryptography that could theoretically be broken by future quantum computers.

Quick Solutions

Solution 1: Suppress the Warning (Client-Side)

If you accept the risk and just want to hide the warning, configure your SSH client.

Edit ~/.ssh/config:

# For a specific host
Host myserver.example.com
    LogLevel ERROR

# Or for all hosts
Host *
    LogLevel ERROR

Pros: Simple, no server changes required Cons: Doesn't actually fix the security issue, just hides the warning

Solution 2: Enable Post-Quantum Cryptography (Recommended)

Actually fix the issue by enabling post-quantum key exchange algorithms.

On the SSH Server

1. Check OpenSSH version (requires OpenSSH 9.0+):

ssh -V

2. Edit SSH server configuration:

Edit /etc/ssh/sshd_config or create /etc/ssh/sshd_config.d/post-quantum.conf:

# Enable post-quantum key exchange algorithms
KexAlgorithms [email protected],curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256

Note: [email protected] is listed first, providing post-quantum security while maintaining backward compatibility.

3. Restart SSH service:

# Debian/Ubuntu
sudo systemctl restart sshd

# RHEL/CentOS/Rocky
sudo systemctl restart sshd

# Verify configuration is valid before restarting
sudo sshd -t

On the SSH Client (Optional)

You can also configure your client to prefer post-quantum algorithms:

Edit ~/.ssh/config:

Host *
    KexAlgorithms [email protected],curve25519-sha256,[email protected]

Verification

Test the Connection

After configuration, test your SSH connection:

ssh -v user@hostname 2>&1 | grep "kex:"

Look for output like:

debug1: kex: algorithm: [email protected]

Verify Key Exchange Algorithm

Connect and check which algorithm is being used:

ssh -o LogLevel=DEBUG user@hostname 2>&1 | grep "kex: algorithm"

Security Considerations

Should You Enable This?

Yes, if:

You work with long-term sensitive data (healthcare, finance, government)
You have compliance requirements
You want to future-proof your infrastructure
Your OpenSSH version supports it (9.0+)

Maybe not urgent if:

You're doing general server administration
Your data is not valuable long-term
You're not a high-value target
Your OpenSSH version is too old

What is sntrup761x25519-sha512?

This is a hybrid key exchange algorithm combining:

Streamlined NTRU Prime 761 (post-quantum secure)
X25519 (classically secure elliptic curve)
SHA-512 (hash function)

The hybrid approach means you get:

Protection against classical attacks (current computers)
Protection against quantum attacks (future quantum computers)

Troubleshooting

"Connection closed by remote host"

Your server might not support post-quantum algorithms. Check OpenSSH version:

ssh -V

Upgrade to OpenSSH 9.0 or later.

"Unable to negotiate" errors

The client and server can't agree on algorithms. Ensure both support the same algorithms or add fallback options:

KexAlgorithms [email protected],curve25519-sha256,ecdh-sha2-nistp256

Testing Without Permanent Changes

Test the algorithm before making permanent changes:

ssh -o [email protected] user@hostname

Distribution-Specific Notes

Debian/Ubuntu

OpenSSH 9.0+ is available in:

Ubuntu 22.10+
Debian 12 (Bookworm)+

For older versions, consider using backports or compiling from source.

RHEL/CentOS/Rocky Linux