Quantumveilige SSH: migratieopties voor toegang binnen bedrijven

Kort antwoord: SSH-sleuteluitwisseling is al sinds OpenSSH 9.0 in april 2022 geschikt voor post-kwantumcryptografie, eerst via de sntrup761x25519-sha512-hybride en vervolgens via de door NIST gestandaardiseerde mlkem768x25519-sha256-hybride, die in OpenSSH 10.0 de standaard is geworden. Een huidige OpenSSH-client die verbinding maakt met een huidige server onderhandelt al over kwantumresistente sleuteluitwisseling zonder dat configuratie nodig is. Hostsleutels en gebruikersauthenticatiesleutels zijn een ander verhaal: SSH-host- en gebruikerssleutels zijn momenteel nog klassiek (Ed25519 of RSA), aangezien de standaardisatie van post-kwantumsignaturen voor SSH nog steeds in ontwikkeling is bij de IETF. Deze handleiding beschrijft wat u nu kunt migreren, waar u op kunt wachten en hoe u de inventaris en het terugdraaiplan kunt opstellen rondom jump hosts en automatisering.

SSH is een van de stillere succesverhalen van na het kwantumtijdperk: de sleuteluitwisseling is standaard al langer kwantumbestendig dan de meeste organisaties beseffen. Het onderdeel dat daadwerkelijk planning vereist, is niet de sleuteluitwisseling, maar de authenticatie met host- en gebruikerssleutels. Deze authenticatie is volledig klassiek en er zijn nog geen definitieve standaarden voor vastgesteld. Deze handleiding maakt een duidelijk onderscheid tussen beide.

Key Takeaways

• OpenSSH biedt sinds versie 9.0 (april 2022) standaard hybride post-quantum sleuteluitwisseling aan, aanvankelijk via sntrup761x25519-sha512.
• OpenSSH 9.9 introduceerde de door NIST gestandaardiseerde mlkem768x25519-sha256 hybride, die de standaard werd in OpenSSH 10.0 (april 2025).
• OpenSSH 10.1 begon gebruikers te waarschuwen wanneer een verbinding een sleuteluitwisseling onderhandelt die niet gebaseerd is op post-kwantumtechnologie. Dit geeft aan dat het ecosysteem sleuteluitwisseling die uitsluitend op klassieke methoden gebaseerd is, nu als uitzondering beschouwt, en niet als de norm.
• Host- en gebruikersauthenticatiesleutels blijven klassiek (Ed25519 of RSA); de standaardisatie van post-quantum handtekeningen voor SSH-authenticatie is nog in ontwikkeling bij de IETF.
• De sntrup761x25519-sha512-hybride werd in april 2026 formeel gestandaardiseerd als RFC 9941, waardoor de eerdere, pre-NIST-hybride een duurzame standaardbasis kreeg naast de nieuwere ML-KEM-optie.

Sleuteluitwisseling: reeds opgelost voor de huidige software.

SSH-sleuteluitwisseling liep stilletjes voor op de meeste protocollen wat betreft de migratie naar het post-kwantumtijdperk. OpenSSH 9.0 introduceerde in april 2022 de sntrup761x25519-sha512-hybride, een combinatie van Streamlined NTRU Prime met het klassieke X25519, als standaard sleuteluitwisselingsalgoritme, jaren voordat NIST ML-KEM definitief vaststelde. OpenSSH 9.9 voegde mlkem768x25519-sha256 toe, een combinatie van het inmiddels gestandaardiseerde ML-KEM-768 met X25519, en OpenSSH 10.0 maakte dit in april 2025 de nieuwe standaard. Vanaf OpenSSH 10.1 geeft het verbinden zonder een van deze post-kwantumhybriden te gebruiken een expliciete waarschuwing: "Deze sessie kan kwetsbaar zijn voor aanvallen waarbij gegevens nu worden opgeslagen en later worden gedecodeerd."

Het praktische resultaat: een huidige OpenSSH-client die verbinding maakt met een huidige OpenSSH-server onderhandelt automatisch over kwantumresistente sleuteluitwisseling, zonder dat configuratie nodig is. De sntrup761x25519-sha512-hybride kreeg in april 2026 ook een formele standaardstatus als RFC 9941, en een parallelle IETF SSHM-werkgroep werkt aan een conceptversie van de equivalente standaard voor de ML-KEM-hybride.

SSH Secure is perfect voor dit soort omgevingen: het inventariseren en automatiseren van de levenscyclus van SSH-sleutels. Het systeem detecteert sleutels op al uw servers en in uw automatiseringsomgeving voordat een migratiedeadline een snelle audit noodzakelijk maakt.

Host- en gebruikerssleutels: het onderdeel dat nog op standaarden wacht.

Dit onderscheid is het belangrijkst voor de planning. SSH-hostsleutelauthenticatie, het mechanisme dat bewijst dat een server is wie hij beweert te zijn, en gebruikerssleutelauthenticatie, het mechanisme dat de identiteit van een client bewijst, zijn beide nog volledig gebaseerd op klassieke algoritmen: Ed25519 of RSA. Geen van beide heeft een definitieve vervanging na de kwantumcomputer in de reguliere OpenSSH-versie, en de standaardisatie van op ML-DSA gebaseerde handtekeningen voor SSH bevindt zich nog in een vroeg stadium binnen de IETF.

Dit is een weloverwogen volgorde, geen vergissing, en volgt dezelfde logica als beschreven in ons hybride PQC-besluitvormingskader : sleuteluitwisseling is vrijwel een op zichzelf staande bibliotheekwijziging, terwijl de migratie van handtekeningen een veel breder scala aan aspecten omvat, zoals tools voor sleutelgeneratie en -distributie, workflows voor sleutelverificatie op de host en elk automatiseringsscript dat momenteel een Ed25519- of RSA-sleutelformaat verwacht.

OpenSSH-ondersteuning op alle platformen

De timing van de ondersteuning verschilt per distributie. Red Hat Enterprise Linux 10 werd geleverd met OpenSSH 9.9, en RHEL 10.1 maakte mlkem768x25519-sha256 de voorkeursstandaard, tenzij expliciet anders geconfigureerd. RHEL 10.2 ging nog een stap verder en voegde FIPS-compatibele hybride opties toe, mlkem768nistp256-sha256 en mlkem1024nistp384-sha384, via patches vanuit de upstream-versie, aangezien de beheerders van OpenSSH ervoor kozen om de NIST-curvevarianten niet direct te implementeren. Organisaties die onder FIPS-vereisten vallen, moeten controleren welke specifieke hybride hun platform en distributie daadwerkelijk ondersteunen, aangezien FIPS-conformiteit afhangt van de exacte curve- en hashcombinatie, en niet alleen van "post-quantumondersteuning" als algemene bewering.

Niet elke SSH-clientimplementatie is bijgewerkt. Sommige ingebouwde SSH-clients, met name in oudere netwerkapparaten of gespecialiseerde tools, ondersteunen post-quantum sleuteluitwisseling nog helemaal niet. Daarom is het essentieel om de daadwerkelijke clientversies, en niet alleen de serverversies, in kaart te brengen voordat men ervan uitgaat dat een omgeving volledig gedekt is.

Jump Hosts, automatisering en inventaris

De operationele voetafdruk van SSH maakt het opsporen ervan lastiger dan bij een typische TLS-migratie. Sleutels en vertrouwensrelaties zijn vaak ingebed op plaatsen die niet zichtbaar zijn in een eenvoudige serverinventaris: jumphostconfiguraties die meerdere SSH-hops aan elkaar koppelen, inloggegevens voor CI/CD-pipelines, infrastructuur-als-code-tools die programmatisch SSH-toegang mogelijk maken, en langlopende automatiseringsscripts met hardgecodeerde host-sleutelvingerafdrukken of sleutelbestandspaden.

Het opbouwen van een nauwkeurige inventaris betekent dat al deze aspecten moeten worden meegenomen, niet alleen interactieve gebruikerssessies: elke jump host en de hopketens die daarvan afhankelijk zijn, elk geautomatiseerd proces dat een SSH-verbinding tot stand brengt, en elke hardgecodeerde verwijzing naar een specifiek sleutelalgoritme of bestandsformaat dat door een toekomstige migratie van hostsleutels zou worden verbroken.

Overwegingen met betrekking tot terugdraaien

Het terugdraaien van de sleuteluitwisseling is per definitie risicoarm: door een specifieke voorkeursvolgorde voor KexAlgorithms vast te leggen, met klassieke algoritmen als terugvalopties, kan een omgeving oudere peers soepel accommoderen, terwijl de voorkeur nog steeds uitgaat naar de post-quantum hybride, waar beide partijen dit ondersteunen. Het terugdraaien van hostsleutels, zodra post-quantum handtekeningopties gestandaardiseerd en beschikbaar zijn, zal een grotere operationele impact hebben, omdat wijzigingen in hostsleutels waarschuwingen voor bekende hosts activeren en automatisering kunnen verstoren die specifieke sleutelvingerafdrukken vastlegt. Dit is precies de reden waarom het nu al de moeite waard is om de jump-host en de automatiseringsinventaris op te bouwen, vóór die migratie, voordat de druk van een deadline dit afdwingt.

Wat we daadwerkelijk zouden aanbevelen

Upgrade nu naar een recente OpenSSH-release voor al uw servers en clients; het voordeel van kwantumbestendige sleuteluitwisseling is direct merkbaar en vereist geen verdere besluitvorming zodra de software is bijgewerkt. Stel KexAlgorithms expliciet in met de voorkeur voor de post-kwantum hybride optie en de klassieke optie als terugvaloptie, in plaats van te vertrouwen op impliciete standaardwaarden die per versie verschillen. Stel nu de jump-host- en automatiseringsinventaris samen, terwijl de host-sleutels nog klassiek en stabiel zijn, zodat de uiteindelijke migratie van host-sleutels een nauwkeurige basis heeft om mee te werken in plaats van onder tijdsdruk helemaal opnieuw te moeten beginnen.

Hoe encryptieconsultancy kan helpen

De ketens van jump-hosts, automatiseringsscripts en hardgecodeerde sleutelreferenties die SSH-migratie lastiger maken dan het lijkt, vormen precies de ontdekkingskloof die SSH Secure , het speciale SSH-sleutelbeheerplatform van Encryption Consulting, wil dichten. Het platform ontdekt en inventariseert SSH-sleutels op alle servers, jump-hosts en in automatiseringstools en automatiseert de sleutellevenscyclus, zodat de uiteindelijke migratie van hostsleutels begint vanuit een actuele inventaris in plaats van vanuit het institutionele geheugen.

Onze PQC Advisory Services verwerken die inventaris nu al in een migratieplan, waarbij de directe OpenSSH-upgrade en de KexAlgorithms-configuratie worden afgestemd op de toekomstige migratie van host-sleutels. Zo is uw organisatie klaar om snel over te stappen zodra de SSH-handtekeningstandaarden na de kwantumovergang definitief zijn, in plaats van het ontdekkingsproces op dat moment helemaal opnieuw te moeten beginnen.

Eén probleem opgelost, één moet nog komen.

SSH-sleuteluitwisseling is al jaren standaard bestand tegen kwantumaanvallen, en de enige actie die de meeste organisaties hoeven te ondernemen is ervoor zorgen dat hun OpenSSH-versie actueel is. Authenticatie van host- en gebruikerssleutels is de echte resterende uitdaging, en die is nog niet op dezelfde manier uitvoerbaar, omdat de standaarden waarop deze gebaseerd is nog niet definitief zijn. De organisaties die het snelst vooruitgang boeken zodra die standaarden er wel zijn, zijn de organisaties die nu een nauwkeurige inventarisatie maken van jump hosts, automatisering en sleutelafhankelijkheden, zonder de tijdsdruk die later een haastige inventarisatie afdwingt.

Veelgestelde Vragen / FAQ

Is SSH al bestand tegen kwantumaanvallen?

Sleuteluitwisseling is standaard ingeschakeld in de huidige OpenSSH-versies sinds OpenSSH 9.0. Hostsleutel en gebruikersauthenticatie zijn dat niet; beide blijven de klassieke Ed25519- of RSA-methode, in afwachting van IETF-standaardisatie van post-quantum SSH-handtekeningen.

Moet ik nog iets doen om de SSH-sleuteluitwisseling na de quantumaanval te voltooien?

Als zowel de client als de server OpenSSH 9.0 of hoger gebruiken, wordt de hybride post-quantum sleuteluitwisseling automatisch en zonder configuratie tot stand gebracht. Met OpenSSH 10.0 of hoger wordt standaard de door NIST gestandaardiseerde ML-KEM hybride gebruikt in plaats van de eerdere sntrup761 hybride.

Waarom is SSH-hostkeyauthenticatie nog niet overgestapt op post-kwantumalgoritmen?

De standaardisatie van op ML-DSA gebaseerde handtekeningen voor SSH bevindt zich nog in een vroeg stadium binnen de IETF. Dit weerspiegelt de bredere trend waarbij sleuteluitwisseling sneller verloopt dan handtekeningenmigratie, omdat handtekeningmigratie de workflows voor sleutelgeneratie, -distributie en -verificatie in een complete omgeving beïnvloedt, in plaats van slechts één bibliotheekupdate.

Wat moeten organisaties nu doen als de host-sleutels nog niet klaar zijn voor migratie?

Stel nu een inventaris samen van jump hosts, automatiseringspipelines en hardgecodeerde sleutelreferenties. Dit is het voorbereidende werk dat nodig is voor een toekomstige migratie van hostsleutels, ongeacht welke standaard uiteindelijk de norm wordt. Door dit vóór de deadline te doen, voorkomt u een gehaaste en onvolledige inventaris later.

Heeft FIPS-conformiteit invloed op de keuze van de post-quantum SSH-sleuteluitwisselingsoptie?

Ja. FIPS-compatibele omgevingen vereisen de specifieke hybride varianten van de NIST-curve, zoals mlkem768nistp256-sha256, in plaats van de op X25519 gebaseerde hybride varianten die standaard in de OpenSSH-mainline worden meegeleverd. Controleer welke variant uw specifieke platform en distributie ondersteunen voordat u ervan uitgaat dat algemene ondersteuning na de quantum-update voldoet aan de FIPS-vereisten.