OpenSSH Post-Quantum Warning: What Developers Must Do

If you upgraded to OpenSSH 10.1 or later and started seeing this in your terminal, you’re not alone:

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.

This is not a broken config. OpenSSH 10.1, released in October 2025, added explicit warnings when an SSH session negotiates a key exchange algorithm that isn’t resistant to quantum decryption. The warning is correct, and it’s the server’s problem — not yours. Here’s what it means, which major platforms have already fixed it, and exactly what to do if you control the server.

Why Storing Your SSH Sessions Is Worth Attackers’ Time

The threat model here is called “harvest now, decrypt later.” Nation-states and well-resourced adversaries are collecting encrypted traffic today — SSH sessions, TLS connections, anything — betting that quantum computers capable of breaking current asymmetric cryptography will exist within a decade or two. The data they store now can be decrypted later. SSH sessions that include credentials, deployment keys, or access to sensitive infrastructure are exactly the kind of traffic worth collecting.

NIST finalized the post-quantum algorithm ML-KEM (FIPS 203) in 2024, and OpenSSH has been shipping hybrid post-quantum key exchange since version 9.0 in April 2022. OpenSSH 10.0 made mlkem768x25519-sha256 — a hybrid of ML-KEM and classic X25519 — the default. Version 10.1 decided it was time to stop being quiet about servers that haven’t caught up.

Where Your Server Stands

Here’s the version timeline so you know exactly what you’re working with:

• OpenSSH 9.0 (Apr 2022) — added sntrup761x25519-sha512 (NTRU Prime hybrid), first post-quantum KEX
• OpenSSH 9.9 (Oct 2024) — added mlkem768x25519-sha256 (ML-KEM hybrid, NIST-standardized)
• OpenSSH 10.0 (Apr 2025) — made mlkem768x25519-sha256 the default key exchange
• OpenSSH 10.1 (Oct 2025) — added warning when the server doesn’t offer post-quantum algorithms
• OpenSSH 10.3 (Apr 2026) — current release, security and agent fixes

If your server runs OpenSSH 9.9 or later, the warning should already not appear — those versions offer ML-KEM by default. If you’re still on 9.8 or earlier, you need to upgrade.

Distro status: Ubuntu 25.04+, Debian 13 (Trixie), and RHEL 10 / AlmaLinux 10 all ship OpenSSH 9.9 or newer. Ubuntu 24.04 LTS ships 9.6 — upgrade the package manually or use a backport PPA. macOS users: Apple’s bundled SSH lags significantly; install openssh via Homebrew to get current versions on both client and server.

The Fix

First, check what you’re running:

ssh -V
sshd -V

Then verify what key exchange algorithms your server currently advertises:

sshd -T | grep -E '^kexalgorithms'

If mlkem768x25519-sha256 isn’t in that list, add it to /etc/ssh/sshd_config:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256@libssh.org,ecdh-sha2-nistp256

Restart the daemon:

# Ubuntu/Debian
systemctl restart ssh

# RHEL/Fedora
systemctl restart sshd

Confirm the upgrade worked by checking what algorithm was negotiated:

ssh -v user@yourserver 2>&1 | grep "kex algos"

You should see mlkem768x25519-sha256 in the output. If you do, clients with OpenSSH 10.1+ won’t warn anymore when connecting.

Platform Status: GitHub Is Done, Bitbucket Is Not

The practical sting for most developers is hosted Git platforms. Here’s where things stand:

• GitHub: Done. GitHub deployed post-quantum SSH in fall 2025, negotiating sntrup761x25519-sha512 by default. No warning when connecting to github.com.
• GitLab: Done for GitLab.com. Self-managed instances need GitLab 18.2.4+ with a server running OpenSSH 9.9+. If you’re seeing the warning on your own GitLab instance, update both.
• Bitbucket: Not done. As of June 2026, Bitbucket uses curve25519-sha256 with no ML-KEM support. Feature request BCLOUD-23914 was filed in March 2026 and remains open. Every developer with OpenSSH 10.1+ pushing to Bitbucket via SSH sees this warning — and there’s nothing to fix on your end.

If You Can’t Fix the Server

For servers you don’t control — Bitbucket, legacy corporate infrastructure, third-party services — you can suppress the warning on the client side without fixing the underlying issue. Add this to ~/.ssh/config:

# Suppress post-quantum warning for servers you don't control
Host bitbucket.org
    KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256

This explicitly negotiates a non-post-quantum algorithm, which stops the warning. You’re not improving security — you’re acknowledging the status quo. If you’re managing infrastructure that will stay unupgraded for a while, this is the pragmatic choice. At minimum, file a support ticket so someone is on record acknowledging the risk.

This Is Just the Beginning

SSH is where developers are first encountering post-quantum migration in practice because OpenSSH moved fast. TLS stacks are next — most HTTPS connections don’t yet negotiate post-quantum key exchange by default, though browser experiments are underway.

The NSA’s CNSA 2.0 guidance asks critical systems to complete post-quantum migration by 2026-2027. OpenSSH is accelerating the timeline on the tools developers use every day. If your server is old enough to trigger this warning, it’s time to upgrade — not because quantum computers exist today, but because the data you’re protecting now may still matter when they do.