GitHub innfører postkvanteutveksling av SSH-nøkler – foreløpig ikke i USA

I dag, 14. oktober 2026, begynte GitHub å innføre to endringer for SSH: Nye RSA-nøkler som lastes opp, må være på minst 3072 bit, og den postkvantebaserte nøkkelutvekslingsalgoritmen mlkem768x25519-sha256 aktiveres for enkelte tilkoblinger. Endringene gjelder SSH-tilkoblinger; brukere som benytter Git over HTTPS, trenger ikke å endre innstillingene på grunn av denne kunngjøringen.

I kunngjøringen fra GitHub 22. september står det at algoritmen blir tilgjengelig på github.com og GitHub Enterprise Cloud med Data Residency, med unntak av USA-regionen. Dette er plattformens støtte for algoritmen; om den faktisk brukes, avhenger også av SSH-klienten og innstillingene dens.

Hva endres?

For nye RSA SSH-nøkler som lastes opp etter 14. oktober, er minstegrensen satt til 3072 bit. Eksisterende RSA-nøkler trenger ikke byttes ut bare på grunn av lengden: GitHub anbefaler å bruke RSA-SHA-2-signaturer med dem — rsa-sha2-256 eller rsa-sha2-512. I dokumentasjonen anbefaler selskapet også Ed25519 for nye nøkler når typen passer arbeidsmiljøet.

Den andre endringen gjelder forhandling av øktnøkkelen. mlkem768x25519-sha256 kombinerer ML-KEM — en postkvantebasert algoritme for nøkkelinnkapsling — med X25519. Ifølge planen fra GitHub vil kompatible klienter som er konfigurert til å foretrekke algoritmen, kunne velge den automatisk. Eldre klienter skal gå videre til en støttet kompatibilitetsalgoritme.

Dette bør teamet kontrollere

1. Finn ut hvordan dere kobler til. Kontroller Git remote-adressene: oppføringer som begynner med https://, påvirkes ikke av SSH-endringene. For SSH bør dere kontrollere klientene, bibliotekene og integrasjonene som er i bruk.
2. Kontroller RSA-signaturer. Sørg for at klienten og biblioteket som brukes, støtter RSA-SHA-2. GitHub oppgir minimumsversjoner for populære implementasjoner, blant annet OpenSSH 7.2p1, Go SSH 0.16.0 og libssh2 1.11.0.
3. Kontroller nye nøkler. Hvis organisasjonens retningslinjer krever RSA, må en ny nøkkel være på minst 3072 bit. For en RSA-nøkkel som allerede er lastet opp, er støtte for signaturalgoritmen viktigere enn å generere en erstatning bare på grunn av denne endringen.
4. Kontroller klientstøtte for ML-KEM. En plattformoppdatering garanterer ikke i seg selv at den enkelte klienten velger den nye nøkkelutvekslingen. Kontroller først klientdokumentasjonen og hvordan den oppfører seg i en testtilkobling; planlegg oppdateringer for eldre klienter i tråd med organisasjonens vanlige tidsplan.

En egen fase starter senere: GitHub har planlagt prøvevise deaktiveringer av den utdaterte RSA-signaturen med SHA-1 og mekanismen diffie-hellman-group-exchange-sha256 4. november og 9. desember 2026, før den endelige fjerningen 13. januar 2027. Dagens krav til lengden på nye RSA-nøkler og den framtidige utfasing av gamle algoritmer bør derfor behandles som to separate migreringsoppgaver.

For team er den praktiske prioriteten i dag å kartlegge SSH-klientene og kontrollere RSA-SHA-2-støtte, og deretter teste ML-KEM-støtte separat. Tilgjengelighet av den nye algoritmen er foreløpig ikke oppgitt for brukere i USA; kravet til størrelsen på nye RSA-nøkler gjelder likevel allerede for opplastinger etter 14. oktober.