Post-quantum SSH op Ubuntu: wat is er veranderd?

Wat is er veranderd in post-quantum SSH

Post-quantum SSH is voor de meeste gebruikers al ingeschakeld en niemand hoefde hiervoor configuraties aan te passen. Een actuele OpenSSH-client die communiceert met een actuele OpenSSH-server kiest standaard een hybride post-quantum sleuteluitwisseling. Hierdoor is de sessiesleutel bestand tegen een aanvaller die uw verkeer vandaag opneemt en over jaren probeert te ontsleutelen. De bescherming is reëel, maar beperkter dan de term "quantum-safe SSH" doet vermoeden.

Eerst twee termen. SSH (secure shell) is het protocol waarmee u inlogt op een server. De sleuteluitwisseling, meestal aangeduid als "kex", is de eerste stap van elke SSH-verbinding: beide partijen komen een gedeeld geheim overeen, en dat geheim versleutelt alles wat volgt. De sleuteluitwisseling is het enige onderdeel dat is veranderd. Niets anders is gewijzigd.

Vertrouw deze pagina niet, voer de commando's uit

Elke algoritmenaam hieronder is afkomstig van een commando dat u zelf kunt uitvoeren. Dat is met opzet gedaan. De standaardinstellingen veranderen bij elke OpenSSH-release; een handleiding van twee jaar geleden noemt dus een algoritme dat uw machine niet langer verkiest, zonder dat de handleiding u daarop kan wijzen. Leer deze commando's en u heeft geen artikelen hierover meer nodig, inclusief dit artikel.

Begin met wat uw build ondersteunt.

ssh -V
ssh -Q kex

ssh -V toont een versieregel die begint met OpenSSH_, gevolgd door het Ubuntu-pakketsuffix en de OpenSSL-versie. ssh -Q kex toont één algoritme voor sleuteluitwisseling per regel. Op een build met post-quantum-ondersteuning vindt u namen zoals mlkem768x25519-sha256 en sntrup761x25519-sha512@openssh.com in die lijst, naast klassieke namen zoals curve25519-sha256.

Wat uw build ondersteunt is niet wat deze aanbiedt

Dit is het onderscheid dat de meeste berichten overslaan. ssh -Q kex beantwoordt één vraag: wat kan dit binaire bestand doen. Het beantwoordt niet de vraag die voor u van belang is: wat zal deze verbinding daadwerkelijk voorstellen. De twee lijsten zijn verschillend, en het gat daartussen is waar verouderd advies werkelijke schade aanricht.

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

ssh -G <host> toont de effectieve configuratie van de client voor die host, nadat ~/.ssh/config en /etc/ssh/ssh_config zijn toegepast. sshd -T doet hetzelfde voor de server. Elk commando print één kexalgorithms-regel in volgorde van voorkeur, en de eerste naam op die regel is de eerste keuze van die kant. Die regel is wat er daadwerkelijk over de verbinding wordt verstuurd.

Dit gat is niet theoretisch. OpenSSH 8.5, uitgebracht op 2021-03-03, voegde sntrup761x25519-sha512@openssh.com toe en liet dit bewust weg uit de standaardlijst. In die release toont ssh -Q kex het algoritme en ssh -G niet, wat betekent dat het binaire bestand een post-quantum sleuteluitwisseling kan uitvoeren, maar dat geen enkele verbinding er ooit om vraagt.

Lees het algoritme dat uw verbinding heeft onderhandeld

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

Tussen een huidige client en een huidige server print dit:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 is een hybride. Het voert ML-KEM (module-lattice key encapsulation mechanism, gestandaardiseerd als FIPS 203) uit op parameterset 768, samen met X25519 elliptic curve Diffie-Hellman, en mengt beide outputs in de sessiesleutel.

Bij een oudere server ziet u mogelijk dit in plaats daarvan:

debug1: kex: algorithm: curve25519-sha256

Die naam heeft geen post-quantum helft. curve25519-sha256 is enkel elliptic curve Diffie-Hellman, en een grote quantumcomputer kraakt dit. Dat is de volledige reden waarom de standaardinstelling is gewijzigd.

Eén onderhandelingsregel verklaart waarom een enkele oude machine een sessie tegenhoudt. De client verstuurt zijn lijst in volgorde van voorkeur, de server verstuurt de zijne, en het gekozen algoritme is de eerste naam op de lijst van de client die ook op die van de server voorkomt. De voorkeur van de client wint, dus de oudste van de twee uiteinden bepaalt hoe ver u in de lijst komt. Het upgraden van uw laptop upgradet geen sessie naar een server die nog nooit van ML-KEM heeft gehoord.

Laat de grep weg en ssh -v toont de rest van de onderhandeling, inclusief de regel waar de volgende sectie over gaat:

debug1: kex: host key algorithm: ssh-ed25519

Welke OpenSSH-release maakte de hybride uitwisseling de standaard

De upstream-release notes bieden een duidelijke volgorde. De data zijn belangrijker dan de versienummers, omdat ze aantonen hoe lang dit al geruisloos in gebruik is.

• 8.5, uitgebracht op 2021-03-03, voegde sntrup761x25519-sha512@openssh.com toe en liet dit standaard uitgeschakeld.
• 9.0, uitgebracht op 2022-04-08, schakelde het in. De notes vermelden dat OpenSSH standaard "de hybride Streamlined NTRU Prime + x25519 sleuteluitwisselingsmethode zal gebruiken". Dit is de release waarin een post-quantum sleuteluitwisseling de standaard werd.
• 9.9, uitgebracht op 2024-09-19, voegde mlkem768x25519-sha256 toe als tweede optie. Dezelfde release gaf de oudere methode de IANA-geregistreerde naam sntrup761x25519-sha512, waardoor nieuwere builds deze onder beide schrijfwijzen vermelden.
• 10.0, uitgebracht op 2025-04-09, maakte mlkem768x25519-sha256 de standaard voor sleutelovereenkomst.
• 10.1, uitgebracht op 2025-10-06, voegde een client-waarschuwing toe wanneer een verbinding een sleuteluitwisseling onderhandelt zonder post-quantum component. Dit wordt beheerd door de WarnWeakCrypto optie in ssh_config en staat standaard aan.

April 2022 is de datum die u moet onthouden. Elk paar machines dat OpenSSH 9.0 of nieuwer draait, voert sindsdien een post-quantum sleuteluitwisseling uit, zonder configuratie en zonder melding aan de gebruiker die ssh typt.

Welke Ubuntu-release levert deze versie

Ubuntu bevriest een OpenSSH-versie bij de release en backport vervolgens beveiligingspatches zonder het versienummer te wijzigen. De Ubuntu-release die u draait, bepaalt dus uw standaardalgoritme. Controleer de machine waar u aan werkt met ssh -V in plaats van te vertrouwen op een lijst. Sinds augustus 2026 bevat het archief de volgende versies:

• 22.04 LTS levert 1:8.9p1, wat van vóór de 9.0-standaard is, dus een standaardinstallatie onderhandelt curve25519-sha256.
• 24.04 LTS levert 1:9.6p1, wat na 9.0 en vóór 9.9 ligt, dus de standaard is sntrup761x25519-sha512@openssh.com en het bevat geen ML-KEM.
• 25.10 levert 1:10.0p1, waarvan de standaard mlkem768x25519-sha256 is.
• 26.04 LTS levert 1:10.2p1, wat standaard mlkem768x25519-sha256 gebruikt en waarschuwt voor verbindingen die niet post-quantum zijn.

Werk met een echt paar machines. Een 26.04-laptop maakt verbinding met een 24.04-server. De eerste keuze van de client, mlkem768x25519-sha256, staat niet in de lijst van de 9.6-server. De volgende post-quantum-keuze van de client die de server wel ondersteunt is sntrup761x25519-sha512@openssh.com, en dat is de naam die ssh -v rapporteert. De sessie is post-quantum wat betreft de sleuteluitwisseling, tegen een server die in 2024 is gebouwd, zonder dat iemand iets heeft geconfigureerd.

Het geval 22.04 werkt de andere kant op en laat precies zien waarom ssh -Q kex op zichzelf misleidend is. OpenSSH 8.9 kent de naam sntrup761x25519-sha512@openssh.com, dus ssh -Q kex op die machine vermeldt deze, maar het standaardvoorstel laat het weg, waardoor de onderhandeling uitkomt op curve25519-sha256. Vanaf een OpenSSH 10.1-client of nieuwer meldt de verbinding het volgende:

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

Die waarschuwing is een feit over de server die u bereikt, niet over uw client. De oplossing is om de server te upgraden. Het instellen van WarnWeakCrypto no verwijdert het bericht en verandert niets aan de verbinding.

Waarom hybride, en wat 'harvest now, decrypt later' betekent

De dreiging is helder. Een aanvaller die uw netwerkverkeer kan inzien, slaat de versleutelde bytes vandaag op. Ze kunnen deze op dit moment niet lezen. Ze bewaren de data totdat er een kwantumcomputer bestaat die krachtig genoeg is om X25519 te kraken, en lezen de inhoud vervolgens alsnog. Dit proces wordt 'harvest now, decrypt later' of 'store now, decrypt later' genoemd. Het vereist geen complexe acties van de aanvaller in het heden. Het vraagt enkel om schijfruimte en geduld.

Versleuteling kent dit probleem, terwijl digitale handtekeningen dat niet hebben; deze asymmetrie bepaalt alles. Een opgeslagen ciphertext behoudt zijn waarde zolang de data erin gevoelig blijft. Een handtekening hoeft alleen onvervalsbaar te zijn op het moment van controle. Het kraken van een algoritme voor handtekeningen in 2035 stelt iemand in staat om zich in 2035 voor te doen als een server. Het stelt hen echter niet in staat om terug te gaan in de tijd en een login uit 2026 te vervalsen. Daarom moest de sleuteluitwisseling als eerste worden aangepakt, terwijl de kant van de handtekeningen kan wachten.

Hybride betekent dat beide algoritmen worden uitgevoerd en beide resultaten bijdragen aan de sessiesleutel. Om het geheim achter mlkem768x25519-sha256 te achterhalen, moet een aanvaller zowel ML-KEM 768 als X25519 kraken. Deze combinatie is bewust gekozen: ML-KEM is veel nieuwer dan X25519 en is nog maar kort onderworpen aan aanvallen van cryptanalisten. Mocht er een fout in het nieuwe algoritme worden gevonden, dan verliest u daardoor niet de bescherming die u al had.

Wat is beschermd en wat niet

De sleuteluitwisseling is beschermd. Het gedeelde geheim dat uw sessie versleutelt, is tot stand gekomen via een hybride uitwisseling. Een opname van die sessie van vandaag wordt daarom niet leesbaar wanneer kwantumcomputers beschikbaar komen.

De host-sleutel is niet beschermd. De debug1: kex: host key algorithm: ssh-ed25519-regel benoemt een klassieke handtekening, net als rsa-sha2-512 en de ECDSA-typen (elliptic curve digital signature algorithm). Een aanvaller met een werkende kwantumcomputer zou die handtekening kunnen vervalsen en zich kunnen voordoen als uw server, maar alleen tijdens een live verbinding op dat toekomstige moment, en nooit tegen verkeer dat nu wordt opgenomen.

Uw inlogsleutel is evenmin beschermd. De sleutel in ~/.ssh/id_ed25519 is van hetzelfde type klassieke handtekening en dezelfde redenering is hierop van toepassing. Wat die sleutel dit jaar beschermt, is waar deze zich bevindt en wie deze kan lezen. Daarom verplaatst verstandig beheer van SSH-sleutels uw werkelijke risico veel verder dan enige algoritmenaam op deze pagina.

U hoeft hier niets aan te doen, omdat er nog geen alternatieven zijn om naar over te stappen. OpenSSH heeft aangegeven dat ondersteuning voor post-kwantumhandtekeningen in een toekomstige release zal verschijnen. Totdat deze software wordt uitgebracht, beschikt OpenSSH niet over een post-kwantum host-sleuteltype of een post-kwantum gebruikerssleuteltype, en heeft ssh-keygen er geen beschikbaar. Een handleiding die u adviseert om er een te genereren, beschrijft software die nog niet bestaat.

TLS op dezelfde server is een aparte kwestie met een apart antwoord. TLS (transport layer security) is het protocol dat uw webserver op poort 443 gebruikt; dit is een andere codebase met een eigen releaseplanning. Het upgraden van OpenSSH verandert daar niets aan. Als u een zelfondertekend certificaat voor een private service op dezelfde VPS gebruikt, worden de handtekening en de sleuteluitwisseling bepaald door OpenSSL en uw webserver. Raadpleeg daarom de documentatie van die specifieke stack.

Wat een verstandige beheerder nu doet

Houd OpenSSH actueel, en stop daar. Dat is in feite de volledige strategie voor dit probleem. sudo apt update && sudo apt upgrade houdt u op de versie die uw Ubuntu-release meelevert, en overstappen naar een nieuwere Ubuntu-release zorgt voor een nieuwere OpenSSH. Het inschakelen van automatische beveiligingsupdates zorgt ervoor dat deze patches worden toegepast zonder dat u eraan hoeft te denken. OpenSSH vanaf de broncode compileren om een algoritmenaam na te jagen is een slechte ruil, omdat u daarmee de beveiligingsupdates van de distributie opgeeft voor de meest blootgestelde service op de server. Als u toch broncode ophaalt, controleer de download dan tegen de gepubliceerde checksum voordat u deze bouwt.

Schrijf niet handmatig een KexAlgorithms-regel. Dit is de enige actie die de zaken betrouwbaar verslechtert. Een hardening-handleiding uit 2018 geeft u een lijst die in 2018 correct was, en het plakken daarvan in sshd_config vervangt de standaardlijst in plaats van deze aan te vullen. Elk algoritme dat sindsdien is uitgevonden, wordt nu uitgesloten, waardoor een server die uit zichzelf mlkem768x25519-sha256 zou hebben onderhandeld, stilletjes terugvalt op wat er nog overblijft in de vastgezette lijst. Voer sudo sshd -T | grep -i '^kexalgorithms' uit op elke server die u heeft overgenomen. Als die regel korter is dan die op een verse installatie van dezelfde release, heeft iemand deze vastgezet.

Als u een gegronde reden heeft om de lijst te wijzigen, voeg er dan aan toe in plaats van deze te vervangen. OpenSSH leest een voorloop-+ als toevoegen, een voorloop-- als verwijderen, en een voorloop-^ als verplaatsen naar het begin.

KexAlgorithms ^mlkem768x25519-sha256

Test het bestand voordat u erop vertrouwt. sudo sshd -t parseert de configuratie en geeft niets weer wanneer deze geldig is. Een KexAlgorithms-regel die een algoritme noemt dat de build niet bevat, zorgt ervoor dat sshd niet start, en op een externe server betekent dit dat u niet meer kunt inloggen. Houd daarom een tweede sessie open terwijl u werkt. Wanneer de lijsten van beide kanten niet meer overeenkomen, meldt de client dit duidelijk:

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

Lees "quantum-safe" marketing als een bewering over één laag. Een leverancier die een product quantum-safe noemt, beschrijft de laag die zij hebben benoemd, en die laag is meestal een sleuteluitwisseling ergens. Vraag naar de algoritmenaam en het protocol waarop deze van toepassing is. Voor OpenSSH in augustus 2026 is de eerlijke versie van de bewering dat de sleuteluitwisseling hybride post-quantum is, terwijl de handtekeningen klassiek zijn. Alles wat breder is dan dat, zou moeten komen met een naam die u kunt vinden in de ssh -Q kex-output.

Blijf de saaie onderdelen uitvoeren. Een post-quantum sleuteluitwisseling doet niets tegen een raadbaar wachtwoord of een privésleutel die naar een laptop is gekopieerd die later wordt gestolen. Dat zijn de zaken die servers daadwerkelijk in gevaar brengen, en standaard SSH-hardening op een VPS draagt nog steeds bijna al het gewicht. Als de onderhandelingsstappen hier onbekend waren, behandelt wat SSH doet wanneer u verbinding maakt de fasen waarvan deze pagina aanneemt dat u ze kent.

FAQ

Is mijn SSH-verbinding al post-quantum?

Voer ssh -v yourserver 2>&1 | grep 'kex: algorithm' uit en lees de naam die wordt weergegeven. mlkem768x25519-sha256 en sntrup761x25519-sha512@openssh.com zijn hybride post-quantum uitwisselingsmethoden. curve25519-sha256, ecdh-sha2-nistp256 en elke naam met diffie-hellman-group zijn klassiek. Beide zijden hebben een versie nodig die een post-quantum naam aanbiedt, omdat de onderhandeling de eerste keuze van de client kiest die de server ook ondersteunt; de oudere machine bepaalt dus de bovengrens.

Welke OpenSSH-release maakte post-quantum sleuteluitwisseling de standaard?

OpenSSH 9.0, uitgebracht op 2022-04-08, maakte sntrup761x25519-sha512@openssh.com de standaard sleuteluitwisseling. OpenSSH 9.9, uitgebracht op 2024-09-19, voegde mlkem768x25519-sha256 toe, en OpenSSH 10.0, uitgebracht op 2025-04-09, maakte dat de nieuwe standaard. OpenSSH 10.1, uitgebracht op 2025-10-06, begon met het geven van waarschuwingen wanneer een verbinding geen van beide onderhandelt. Controleer wat uw eigen build doet met ssh -Q kex en ssh -G <host>, aangezien uw Ubuntu-release bepaalt welke versie u heeft.

Moet ik een post-quantum SSH-sleutel genereren?

Nee, want OpenSSH heeft geen dergelijk sleuteltype. Het post-quantum werk tot nu toe betreft de sleuteluitwisseling, waarvoor u geen sleutelbestanden nodig heeft en geen enkele configuratie vereist is. Host-sleutels en inlogsleutels zijn nog steeds klassieke handtekeningen zoals Ed25519 en RSA; de ontwikkelaars hebben aangegeven dat post-quantum handtekeningen in een toekomstige release zullen verschijnen. Blijf een Ed25519-sleutel gebruiken en beveilig de opslaglocatie ervan.

Waarom waarschuwt ssh dat mijn verbinding niet post-quantum is?

OpenSSH 10.1 en nieuwer tonen ** WARNING: connection is not using a post-quantum key exchange algorithm. wanneer de onderhandelde uitwisseling geen post-quantum component bevat. De waarschuwing betreft de server, niet uw client, omdat uw client een post-quantum naam aanbood en de server er geen enkele accepteerde. Upgrade de OpenSSH-versie van de server of controleer of er geen KexAlgorithms-regel in het bestand sshd_config staat die de moderne namen uitsluit. Het instellen van WarnWeakCrypto no verbergt het bericht, maar laat de verbinding net zo zwak als deze was.