Post-Quantum SSH: Wetin Change for Ubuntu?

Wetin change for post-quantum SSH

Post-quantum SSH don already turn on for most people, and nobody need configure am. Current OpenSSH client wey dey connect to current OpenSSH server dey choose hybrid post-quantum key exchange by default. This mean say session key fit resist attacker wey record your traffic today and try decrypt am years from now. The protection dey real, but e no broad reach like the phrase "quantum-safe SSH" fit suggest.

Make we first define two terms. SSH (secure shell) na the protocol wey you use log into server. The key exchange, wey dem dey usually write as "kex", na the first step for every SSH connection. The two ends go agree on shared secret, and that secret go encrypt everything wey follow. Na the key exchange be the part wey change. Nothing else change.

No trust this page, run the commands

Every algorithm name wey dey below come from command wey you fit run by yourself. Na intentional. Default dey change for every OpenSSH release, so guide wey dem write two years ago fit mention algorithm wey your machine no prefer again, and e no get way to tell you. Learn these commands, and you no go need articles about this matter again, including this one.

Start with wetin your build sabi do.

ssh -V
ssh -Q kex

ssh -V dey print version line wey start with OpenSSH_, then Ubuntu package suffix and OpenSSL version follow. ssh -Q kex dey print one key exchange algorithm for each line. For build wey get post-quantum support, you go see names like mlkem768x25519-sha256 and sntrup761x25519-sha512@openssh.com for that list, together with classical names like curve25519-sha256.

Wetin your build support no be the same thing as wetin e offer

Na this difference plenty posts dey skip. ssh -Q kex answers one question: wetin this binary fit do. E no answer the question wey matter to you: wetin this connection go actually propose. The two lists no be the same, and na the gap between dem old advice dey cause serious damage.

ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'

ssh -G <host> prints the client's effective configuration for that host, after ~/.ssh/config and /etc/ssh/ssh_config don apply. sshd -T do the same thing for the server. Each one prints one kexalgorithms line for preference order, and the first name for that line na that side's first choice. Na that line go enter the wire.

The gap no be theory. OpenSSH 8.5, wey release on 2021-03-03, add sntrup761x25519-sha512@openssh.com and intentionally leave am out of the default list. For that release, ssh -Q kex show the algorithm but ssh -G no show am. This mean say the binary fit do post-quantum key exchange, but no connection ever ask am to.

Read which algorithm your connection negotiate

ssh -v example.com 2>&1 | grep 'kex: algorithm'

Between current client and current server, dis one go print:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 na hybrid. E dey run ML-KEM (module-lattice key encapsulation mechanism, dem standardise am as FIPS 203) for parameter set 768, together with X25519 elliptic curve Diffie-Hellman, then e mix both outputs into the session key.

Against older server, you fit see dis instead:

debug1: kex: algorithm: curve25519-sha256

Dat name no get post-quantum part. curve25519-sha256 na elliptic curve Diffie-Hellman by itself, and big quantum computer fit break am. Na dis be the complete reason why the default change.

One negotiation rule explain why one old machine fit hold session back. Client go send im list according to preference order, server go send im own list, and dem go choose the first name for client list wey also dey for server list. Client preference dey win, so the older side of the two go decide how far up the list una fit reach. If you upgrade your laptop, e no mean say session to server wey never hear of ML-KEM go upgrade.

ssh -v good make you know am beyond dis one line, because na the same output you go use find Permission denied (publickey) failure when login refuse completely.

Remove grep and ssh -v go show the rest of the negotiation, including the line wey next section dey talk about:

debug1: kex: host key algorithm: ssh-ed25519

Which OpenSSH release make the hybrid exchange become default

The upstream release notes show the sequence clearly. The dates matter pass the version numbers, because dem show how long this thing don dey run quietly.

• 8.5, wey release for 2021-03-03, add sntrup761x25519-sha512@openssh.com and leave am disabled by default.
• 9.0, wey release for 2022-04-08, turn am on. The notes talk say OpenSSH go "use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default". Na this release make post-quantum key exchange become the normal case.
• 9.9, wey release for 2024-09-19, add mlkem768x25519-sha256 as second option. The same release give the older method the IANA registered name, sntrup761x25519-sha512, so newer builds list am with both names.
• 10.0, wey release for 2025-04-09, make mlkem768x25519-sha256 the default for key agreement.
• 10.1, wey release for 2025-10-06, add client warning when connection negotiate key exchange wey no get post-quantum half. Na WarnWeakCrypto option for ssh_config control am, and e dey on by default.

April 2022 na the date wey worth remembering. Any pair of machines wey dey run OpenSSH 9.0 or newer don dey use post-quantum key exchange since then, without configuration and without any announcement to the person wey type ssh.

Ubuntu release wey include am

Ubuntu dey freeze OpenSSH version for each release, then backport security fixes go inside am without changing version number. So, the Ubuntu release wey you dey run dey decide your default algorithm. Check the machine wey dey in front of you with ssh -V instead of trusting list. As of August 2026, archive get these versions:

• 22.04 LTS ship 1:8.9p1, wey come before the 9.0 default, so stock install dey negotiate curve25519-sha256.
• 24.04 LTS ship 1:9.6p1, wey come after 9.0 and before 9.9, so e default na sntrup761x25519-sha512@openssh.com and e no get ML-KEM.
• 25.10 ship 1:10.0p1, wey default na mlkem768x25519-sha256.
• 26.04 LTS ship 1:10.2p1, wey default na mlkem768x25519-sha256 and e dey warn about connections wey no be post-quantum.

Make we use real pair of machines. A 26.04 laptop dey connect to 24.04 server. The client's first choice, mlkem768x25519-sha256, no dey inside the 9.6 server list. The client's next post-quantum choice wey the server get na sntrup761x25519-sha512@openssh.com, and na that name ssh -v report. The session use post-quantum key exchange, against server wey dem build for 2024, and nobody configure anything.

The 22.04 case dey go the other way, and e show exactly why ssh -Q kex by itself fit mislead you. OpenSSH 8.9 sabi the sntrup761x25519-sha512@openssh.com name, so ssh -Q kex for that machine dey list am, but the default proposal no include am, so negotiation settle for curve25519-sha256. From OpenSSH 10.1 or newer client, the connection go talk am clearly:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

That warning na fact about the server wey you dey reach, no be about your client. The solution na to upgrade the server. Setting WarnWeakCrypto no go remove the message, but e no go change anything about the connection.

Why hybrid, and wetin harvest now decrypt later mean

The threat get plain shape. If attacker fit see your traffic, e record the encrypted bytes today and store dem. E no fit read dem today. E go keep dem until quantum computer wey big enough to break X25519 dey available, then e go read dem. Dem dey call this harvest now, decrypt later, or store now, decrypt later. E no need any clever thing from attacker for now. E only need disk space and patience.

Encryption get this problem, but signatures no get am, and this difference dey drive everything else. Recorded ciphertext still get value as long as the data inside am remain sensitive. Signature only need remain unforgeable when dem dey check am. If person break signature algorithm for 2035, e fit impersonate server for 2035. E no fit go back forge login from 2026. So dem need fix key exchange first, while signature side fit wait.

Hybrid mean say both algorithms run, and both results feed the session key. To recover the secret behind mlkem768x25519-sha256, attacker must break ML-KEM 768 and X25519. The pairing get deliberate reason: ML-KEM newer well-well pass X25519, and cryptanalysts never get as much time attack am. So if dem find flaw for the new algorithm, you no lose the protection wey you already get.

Wetin dey protected and wetin no dey protected

The key exchange dey protected. The shared secret wey dey encrypt your session come from hybrid exchange, so recording of that session wey dem make today no go become readable when quantum computers arrive.

The host key no dey protected. The debug1: kex: host key algorithm: ssh-ed25519 line name classical signature, and na the same thing for rsa-sha2-512 and the ECDSA (elliptic curve digital signature algorithm) types. Attacker wey get working quantum computer fit forge that signature and pretend to be your server, but na only during live connection for that future time, and e no fit affect traffic wey dem record now.

Your login key no dey protected too. The key for ~/.ssh/id_ed25519 na the same kind classical signature, and the same explanation apply. Wetin dey protect that key this year na where e dey and who fit read am, so sensible SSH key management move your real risk much further than any algorithm name for this page.

You no get anything to do about either one, because nothing dey to switch to. OpenSSH don talk say post-quantum signature support dey come for future release. Until e release, OpenSSH no get post-quantum host key type and no get post-quantum user key type, and ssh-keygen no get any one to offer you. Any guide wey tell you make you generate one dey describe software wey never exist yet.

TLS for the same server na separate matter with separate answer. TLS (transport layer security) na wetin your web server dey speak for port 443, and e use different codebase with different schedule. Upgrading OpenSSH no change anything for there. If you dey run a self-signed certificate for a private service on the same VPS, OpenSSL and your web server decide the signature and key exchange, so ask about that stack on e own terms.

Wetín sensible operator go do now

Keep OpenSSH current, and stop there. Na na the whole strategy for this problem. sudo apt update && sudo apt upgrade go keep you for the version wey your Ubuntu release ship, and na moving to newer Ubuntu release go move you to newer OpenSSH. If you turn on unattended security upgrades, dem go apply the patches without you needing remember. Building OpenSSH from source just to chase algorithm name no worth the trade, because you go lose the distribution security updates for the service wey dey most exposed for the server. If you still fetch source, check the download against its published checksum before you build am.

No write KexAlgorithms line by hand. Na this one action dey reliably make things worse. Hardening guide from 2018 fit give you list wey correct for 2018, but if you paste am inside sshd_config, e go replace the default list instead of adding to am. Every algorithm wey dem invent since then go now dey excluded, so server wey suppose negotiate mlkem768x25519-sha256 by itself go quietly drop to anything wey remain for the pinned list. Run sudo sshd -T | grep -i '^kexalgorithms' for any server wey you inherit. If that line short pass the one for fresh install of the same release, somebody pin am.

If you get real reason to change the list, add to am instead of replacing am. OpenSSH reads leading + as append, leading - as remove, and leading ^ as move to the front.

KexAlgorithms ^mlkem768x25519-sha256

Test the file before you depend on am. sudo sshd -t parses the configuration and prints nothing when e valid. KexAlgorithms line wey name algorithm wey the build no get go stop sshd from starting, and for remote server that means you no go fit enter again, so keep second session open while you dey work. When the two sides' lists no overlap again, the client go talk am clearly:

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

Understand "quantum-safe" marketing as claim about one layer. If vendor call product quantum-safe, dem dey describe whichever layer dem name, and usually that layer na key exchange somewhere. Ask for the algorithm name and the protocol wey e apply to. For OpenSSH in August 2026, the honest version of the claim na say the key exchange dey hybrid post-quantum while the signatures remain classical. Anything wider than that suppose come with name wey you fit find for ssh -Q kex output.

Continue with the boring parts. Post-quantum key exchange no do anything about password wey person fit guess, or private key wey somebody copy go laptop wey later get stolen. Na those things dey actually take servers, and standard SSH hardening on a VPS still carry almost all the weight. If the negotiation steps here no familiar to you, wetin SSH dey do when you connect cover the stages wey this page assume say you know.

FAQ

My SSH connection don already be post-quantum?

Run ssh -v yourserver 2>&1 | grep 'kex: algorithm' and read the name wey e print. mlkem768x25519-sha256 and sntrup761x25519-sha512@openssh.com na hybrid post-quantum exchanges. curve25519-sha256, ecdh-sha2-nistp256 and any diffie-hellman-group name na classical. Both sides need version wey dey offer post-quantum name, because negotiation go choose the client's first choice wey the server still support. So, the older machine set the limit.

Which OpenSSH release make post-quantum key exchange the default?

OpenSSH 9.0, wey release on 2022-04-08, make sntrup761x25519-sha512@openssh.com the default key exchange. OpenSSH 9.9, wey release on 2024-09-19, add mlkem768x25519-sha256, and OpenSSH 10.0, wey release on 2025-04-09, make that one the default instead. OpenSSH 10.1, wey release on 2025-10-06, start to warn when connection no negotiate any of dem. Check wetin your own build dey do with ssh -Q kex and ssh -G <host>, because your Ubuntu release decide which ones you get.

I suppose generate post-quantum SSH key?

No, because OpenSSH no get that kind key type. The post-quantum work so far cover the key exchange. E no need any key files from you or any configuration. Host keys and login keys still be classical signatures like Ed25519 and RSA. Upstream don talk say post-quantum signatures go come for future release. Continue to use Ed25519 key, and protect the place wey you store am.

Why ssh dey warn say my connection no be post-quantum?

OpenSSH 10.1 and newer print ** WARNING: connection is not using a post-quantum key exchange algorithm. when the negotiated exchange no get post-quantum half. The warning concern the server, no be your client, because your client offer post-quantum name and the server accept none of dem. Upgrade the server's OpenSSH, or check whether person pin KexAlgorithms line for its sshd_config wey exclude the modern names. Setting WarnWeakCrypto no go hide the message, but the connection go remain exactly as weak as before.