Kvantsäker SSH: Migreringsalternativ för företagsåtkomst

Snabbt svar: SSH:s nyckelutbyte har varit post-kvantum-kompatibelt sedan OpenSSH 9.0 i april 2022, först genom hybriden sntrup761x25519-sha512, sedan genom den NIST-standardiserade hybriden mlkem768x25519-sha256, som gjordes till standard i OpenSSH 10.0. En befintlig OpenSSH-klient som ansluter till en befintlig server förhandlar redan om kvantum-resistent nyckelutbyte utan att konfiguration krävs. Värdnycklar och användarautentiseringsnycklar är en separat historia: SSH-värd- och användarnycklar är fortfarande klassiska (Ed25519 eller RSA) idag, eftersom post-kvantum-signaturstandardisering för SSH fortfarande pågår vid IETF. Den här guiden behandlar vad man ska migrera nu, vad man ska vänta på och hur man bygger inventerings- och rollback-planen kring jump hosts och automatisering.

SSH är en av de tystare framgångshistorierna efter kvantum: dess nyckelutbyte har som standard varit kvantresistent längre än de flesta organisationer inser. Den del som faktiskt behöver planeras är inte nyckelutbyte, det är värd- och användarnycklautentisering, vilket förblir helt klassiskt och ännu inte har någon slutgiltig standardväg. Den här guiden skiljer de två tydligt åt.

Key Takeaways

• OpenSSH har levererat hybrid post-quantum key exchange som standard sedan version 9.0 (april 2022), initialt via sntrup761x25519-sha512.
• OpenSSH 9.9 lade till den NIST-standardiserade mlkem768x25519-sha256-hybriden, som blev standard i OpenSSH 10.0 (april 2025).
• OpenSSH 10.1 började varna användare när en anslutning förhandlar om ett icke-post-kvantumnyckelutbyte, vilket signalerar att ekosystemet nu behandlar klassiskt nyckelutbyte som undantaget, inte normen.
• Värdnycklar och användarautentiseringsnycklar är fortfarande klassiska (Ed25519 eller RSA); standardisering av postkvantumsignaturer för SSH-autentisering pågår fortfarande vid IETF.
• Hybriden sntrup761x25519-sha512 standardiserades formellt som RFC 9941 i april 2026, vilket gav den tidigare hybriden, före NIST, en hållbar standardförankring tillsammans med det nyare ML-KEM-alternativet.

Nyckelutbyte: Redan löst för aktuell programvara

SSH-nyckelutbyte har i tysthet legat före de flesta protokoll för post-kvantmigrering. OpenSSH 9.0 levererade hybriden sntrup761x25519-sha512, som kombinerar Streamlined NTRU Prime med klassisk X25519, som standardalgoritm för nyckelutbyte redan i april 2022, år innan NIST slutförde ML-KEM. OpenSSH 9.9 lade till mlkem768x25519-sha256, som kombinerar den nu standardiserade ML-KEM-768 med X25519, och OpenSSH 10.0 gjorde den till den nya standarden i april 2025. Från och med OpenSSH 10.1 utlöser anslutning utan att förhandla om en av dessa post-kvanthybrider nu en uttrycklig varning: "Denna session kan vara sårbar för "store now, decrypt later"-attacker."

Det praktiska resultatet: en befintlig OpenSSH-klient som ansluter till en befintlig OpenSSH-server förhandlar automatiskt om kvantresistent nyckelutbyte, utan att någon konfiguration krävs. Hybridversionen sntrup761x25519-sha512 fick också formell standardisering i april 2026 som RFC 9941, och ett parallellt utkast från en IETF SSHM-arbetsgrupp definierar motsvarande standard för ML-KEM-hybriden.

SSH-nyckelinventering och livscykelautomatisering för just den här typen av miljö är där SSH Secure passar in. Att upptäcka nycklar över din server och automationsflotta före en migreringsdeadline kräver en snabb granskning.

Värd- och användarnycklar: Den del som fortfarande väntar på standarder

Det här är den skillnad som är viktigast för planeringen. SSH-värdnyckelautentisering, mekanismen som bevisar att en server är den den utger sig för att vara, och användarnyckelautentisering, mekanismen som bevisar en klients identitet, förlitar sig båda fortfarande helt på klassiska algoritmer: Ed25519 eller RSA. Ingen av dem har en slutgiltig post-kvantum-ersättning i mainline OpenSSH, och standardiseringen av ML-DSA-baserade signaturer för SSH är fortfarande i ett tidigt skede i IETF.

Detta är en avsiktlig sekvensering, inte ett förbiseende, och det följer samma logik som finns i vårt hybrida PQC-beslutsramverk : nyckelutbyte är nära en självständig biblioteksändring, medan signaturmigrering berör en mycket bredare yta, verktyg för nyckelgenerering och distribution, arbetsflöden för verifiering av värdnycklar och alla automatiseringsskript som för närvarande förväntar sig ett Ed25519- eller RSA-nyckelformat.

OpenSSH-stöd över olika plattformar

Supporttiderna varierar beroende på distribution. Red Hat Enterprise Linux 10 levererades med OpenSSH 9.9, och RHEL 10.1 gjorde mlkem768x25519-sha256 till den föredragna standarden om inte annat uttryckligen konfigurerats. RHEL 10.2 gick längre och lade till FIPS-kompatibla hybridalternativ, mlkem768nistp256-sha256 och mlkem1024nistp384-sha384, genom nedströmspatchar, eftersom uppströms OpenSSHs underhållare valde att inte implementera NIST-kurvvarianter direkt. Organisationer som arbetar under FIPS-krav bör bekräfta vilken specifik hybrid deras plattform och distribution faktiskt stöder, eftersom FIPS-efterlevnad beror på den exakta kurv- och hashkombinationen, inte bara "post-kvantstöd" som ett generellt påstående.

Inte alla SSH-klientimplementeringar har hunnit ikapp. Vissa inbyggda SSH-klienter, särskilt i äldre nätverksenheter eller specialiserade verktyg, stöder ännu inte post-quantum key exchange alls, vilket gör en inventering av faktiska klientversioner, inte bara serverversioner, till ett viktigt steg innan man antar att en miljö är helt täckt.

Jump Hosts, automatisering och lagerhantering

SSH:s operativa fotavtryck gör upptäckt svårare än en typisk TLS-migrering. Nycklar och förtroendeförhållanden är ofta inbäddade på platser som inte syns i en enkel serverinventering: hoppkonfigurationer för värdar som kedjar flera SSH-hopp, CI/CD-pipeline-autentiseringsuppgifter, verktyg för infrastruktur som kod som tillhandahåller SSH-åtkomst programmatiskt och långlivade automatiseringsskript med hårdkodade värdnycklar eller nyckelfilsökvägar.

Att bygga en korrekt inventering innebär att täcka alla dessa, inte bara interaktiva användarsessioner: varje hoppvärd och de hoppkedjor som är beroende av den, varje automatiserad process som upprättar en SSH-anslutning och varje hårdkodad referens till en specifik nyckelalgoritm eller filformat som en framtida värdnyckelmigrering skulle förstöra.

Överväganden vid återställning

Återställning av nyckelutbyte är avsiktligt lågrisk: att fästa en specifik KexAlgorithms-preferensordning, med klassiska algoritmer listade som reservposter, låter en miljö smidigt anpassa sig till äldre motsvarigheter samtidigt som den föredrar post-kvanthybriden där båda sidor stöder den. Återställning av värdnyckel, när post-kvantumsignaturalternativ standardiseras och levereras, kommer att ha mer operativ vikt, eftersom ändringar av värdnyckel utlöser varningar för kända värdar och kan förstöra automatisering som fäster specifika nyckelfingeravtryck, vilket är just därför det är värt att bygga jump-host- och automatiseringsinventeringen nu, inför den migreringen, innan pressen från en deadline tvingar fram det.

Vad vi egentligen skulle rekommendera

Uppgradera till en aktuell OpenSSH-version över din server- och klientflotta nu; fördelen med kvantresistenta nyckelutbyten är omedelbar och kräver inga ytterligare beslutsfattande när programvaran är aktuell. Fäst KexAlgorithms explicit med de föredragna och klassiska alternativen för post-kvanthybrid som reserv, snarare än att förlita sig på implicita standardvärden som varierar beroende på version. Bygg jump-host- och automationsinventeringen nu, medan värdnycklarna fortfarande är klassiska och stabila, så att den slutliga värdnyckelmigreringen har en korrekt karta att arbeta utifrån istället för att börja om från början under deadlinepress.

Hur krypteringskonsulting kan hjälpa

Jump-host-kedjorna, automatiseringsskripten och hårdkodade nyckelreferenser som gör SSH-migrering svårare än det ser ut är precis det som gör upptäcktsluckan. SSH Secure , Encryption Consultings dedikerade SSH-nyckelhanteringsplattform, är byggd för att stänga, upptäcka och inventera SSH-nycklar över servrar, jump-hosts och automatiseringsverktyg och automatisera nyckellivscykeln så att den slutliga värdnyckelmigreringen startar från en verklig, aktuell inventering snarare än institutionellt minne.

Våra PQC-rådgivningstjänster bygger in den inventeringen i en migreringsplan nu, och sekvenserar den omedelbara OpenSSH-uppgraderingen och KexAlgorithms-konfigurationsarbetet mot den framtida värdnyckelmigreringen, så att din organisation är redo att agera snabbt när post-quantum SSH-signaturstandarder är färdiga, istället för att starta identifieringsprocessen från noll vid den tidpunkten.

Ett problem löst, ett kommer fortfarande

SSH-nyckelutbyte har i tysthet varit kvantumsäkert som standard i åratal, och den enda åtgärden de flesta organisationer behöver vidta är att se till att deras OpenSSH-version är aktuell. Autentisering av värd- och användarnycklar är det verkliga återstående arbetet, och det är ännu inte handlingsbart på samma sätt, eftersom de standarder det är beroende av inte har slutförts. De organisationer som kommer att agera snabbast när de väl gör det är de som bygger en korrekt karta över hoppvärdar, automatisering och nyckelberoenden nu, medan det inte finns någon deadlinepress som tvingar fram en snabb inventering senare.

Vanliga frågor om partihandel med mat och dryck

Är SSH redan kvantresistent?

Nyckelutbyte är, på nuvarande OpenSSH-versioner, som standard sedan OpenSSH 9.0. Värdnyckel och användarautentisering är det inte; båda förblir klassisk Ed25519 eller RSA i väntan på IETF-standardisering av post-kvantum SSH-signaturer.

Behöver jag göra något för att få post-quantum SSH-nyckelutbyte?

Om både klienten och servern kör OpenSSH 9.0 eller senare, förhandlar hybrid post-quantum key exchange automatiskt utan konfiguration. Om du kör OpenSSH 10.0 eller senare får du den NIST-standardiserade ML-KEM-hybriden som standard istället för den tidigare sntrup761-hybriden.

Varför har inte SSH-värdnyckelautentisering flyttats till postkvantalgoritmer än?

Standardisering av ML-DSA-baserade signaturer för SSH är fortfarande i ett tidigt skede inom IETF. Detta speglar det bredare mönstret där nyckelutbyte migrerar snabbare än signaturer, eftersom signaturmigrering berör arbetsflöden för nyckelgenerering, distribution och verifiering över en hel miljö snarare än en enda biblioteksuppdatering.

Vad bör organisationer göra nu om värdnycklar inte är redo att migreras?

Bygg en inventering av hoppvärdar, automatiseringspipelines och hårdkodade nyckelreferenser nu. Detta är det upptäcktsarbete som en framtida värdnyckelmigrering kommer att behöva oavsett vilken standard som slutligen slutförs, och att göra det före en deadline undviker en förhastad, ofullständig inventering senare.

Påverkar FIPS-efterlevnad vilket alternativ för nyckelutbyte efter kvantums-SSH som ska användas?

Ja. FIPS-kompatibla miljöer behöver de specifika NIST-kurvhybridvarianterna, såsom mlkem768nistp256-sha256, snarare än de X25519-baserade hybrider som OpenSSH levererar som standard. Bekräfta vilken variant din specifika plattform och distributionsstöd har innan du antar att generellt post-quantum-stöd uppfyller FIPS-kraven.