Wetin Change for Post-Quantum SSH on Ubuntu?

Wetin change for post-quantum SSH

Post-quantum SSH don already dey switched on for most people, and nobody need configure am. Current OpenSSH client wey dey talk to current OpenSSH server dey choose hybrid post-quantum key exchange by default. So, session key fit resist attacker wey record your traffic today and decrypt am years from now. The protection dey real, but e no broad reach as the phrase "quantum-safe SSH" fit make person believe.

Make we first explain two terms. SSH (secure shell) na protocol wey you use take log into server. The key exchange, wey dem usually write as "kex", na the first step for every SSH connection. The two ends agree on shared secret, and that secret encrypt everything wey follow. Na the key exchange 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 deliberate thing be that. The default dey change with every OpenSSH release, so guide wey dem write two years ago fit mention algorithm wey your machine no longer prefer, 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 wetin e dey offer

Na this distinction 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 different, 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 the line na that side's first choice. Na that line go enter the wire.

The gap no be theory. OpenSSH 8.5, released on 2021-03-03, add sntrup761x25519-sha512@openssh.com and deliberately 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 request am.

Read the algorithm wey your connection negotiate

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

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

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 na hybrid. E dey run ML-KEM (module-lattice key encapsulation mechanism, wey dem standardise 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 this instead:

debug1: kex: algorithm: curve25519-sha256

That name no get post-quantum half. curve25519-sha256 na elliptic curve Diffie-Hellman by itself, and large quantum computer fit break am. Na the whole reason dem move the default be this.

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

Remove the grep and ssh -v to show the rest of the negotiation, including the line wey the 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 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 but 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. This same release give the older method im 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. WarnWeakCrypto option inside 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.

Which Ubuntu release dey ship am

Ubuntu dey freeze one OpenSSH version for each release, then backport security fixes into am without changing the 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 make you trust one list. As of August 2026, archive get these versions:

• 22.04 LTS dey ship 1:8.9p1, wey come before the 9.0 default, so stock install dey negotiate curve25519-sha256.
• 24.04 LTS dey 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 dey ship 1:10.0p1, wey default na mlkem768x25519-sha256.
• 26.04 LTS dey ship 1:10.2p1, wey default na mlkem768x25519-sha256 and dey warn about connections wey no be post-quantum.

Make we work through one real pair of machines. One 26.04 laptop dey connect to one 24.04 server. The client's first choice, mlkem768x25519-sha256, no dey inside the 9.6 server list. The next post-quantum choice wey the server get na sntrup761x25519-sha512@openssh.com, and na that name ssh -v dey 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 person. OpenSSH 8.9 know the sntrup761x25519-sha512@openssh.com name, so ssh -Q kex for that machine go list am, but the default proposal leave am out, so negotiation settle on curve25519-sha256. From OpenSSH 10.1 or newer client, the connection go talk am:

** 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 and no go change anything about the connection.

Why hybrid, and wetin harvest now decrypt later mean

The threat get one clear 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 require any clever move from attacker now. E only require disk space and patience.

Encryption get this problem, but signatures no get am, and this difference drive everything else. Recorded ciphertext keep its value as long as the data inside still sensitive. Signature only need remain unforgeable when dem check am. If person break signature algorithm for 2035, e fit impersonate server for 2035. E no mean say e 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. Dem pair the algorithms deliberately: ML-KEM dey much newer than X25519 and cryptanalysts never get as much time to attack am. So if dem discover flaw for the new algorithm, e no go remove 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 person 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 rsa-sha2-512 plus the ECDSA (elliptic curve digital signature algorithm) types dey do the same thing. Attacker wey get working quantum computer fit forge that signature and pretend say na your server, but na only during live connection for that future time, and e no fit affect traffic wey person 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 to am. Wetin 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 of dem, because nothing dey available to switch to. OpenSSH don talk say post-quantum signature support go come for future release. Until e release, OpenSSH no get post-quantum host key type or post-quantum user key type, and ssh-keygen no get any one to offer you. Guide wey tell you make you generate one dey describe software wey never exist.

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

Wetin 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. Turning on automatic security upgrades go make those patches apply without you needing remember. Building OpenSSH from source just to chase algorithm name no worth the trade-off, because you go lose the distribution security updates for the service wey internet expose pass for the machine. If you still fetch source, check the download against the checksum wey dem publish 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 for 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 dey read leading + as append, leading - as remove, and leading ^ as move go front.

KexAlgorithms ^mlkem768x25519-sha256

Test the file before you depend on am. sudo sshd -t dey parse the configuration and print nothing when e valid. KexAlgorithms line wey name algorithm wey the build no get go stop sshd from starting, and for remote machine that one mean say you no fit enter again. So keep second session open while you dey work. When the lists for both sides no overlap again, the client go talk am clear:

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. When vendor call product quantum-safe, dem dey describe whichever layer dem name, and that layer normally na key exchange somewhere. Ask for the algorithm name and the protocol wey e apply to. For OpenSSH for August 2026, the honest version of the claim be say the key exchange dey use hybrid post-quantum, while the signatures remain classical. Anything broader 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 solve guessable password problem, and e no solve private key wey person copy enter laptop wey later get stolen. Na those things dey actually take servers, and standard SSH hardening for VPS still carry almost all the weight. If the negotiation steps for 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 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 ends need version wey dey offer post-quantum name, because negotiation dey pick the client's first choice wey the server too support. So, the older machine na im set the ceiling.

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

OpenSSH 9.0, wey release for 2022-04-08, make sntrup761x25519-sha512@openssh.com the default key exchange. OpenSSH 9.9, wey release for 2024-09-19, add mlkem768x25519-sha256, and OpenSSH 10.0, wey release for 2025-04-09, make that one the default instead. OpenSSH 10.1, wey release for 2025-10-06, start to warn when connection no negotiate either one. 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, and e no need any key files from you or any configuration. Host keys and login keys still dey use classical signatures like Ed25519 and RSA, and upstream don talk say post-quantum signatures go come for future release. Continue to use Ed25519 key and protect where 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 na about 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 hide the message and leave the connection exactly as weak as e be.