GitHub inför postkvantumutbyte av SSH-nycklar – ännu inte i USA

I dag, den 14 oktober 2026, började GitHub tillämpa två ändringar för SSH: nya uppladdade RSA-nycklar måste vara minst 3072 bitar långa, och den postkvantumssäkra nyckelutbytesalgoritmen mlkem768x25519-sha256 aktiveras för vissa anslutningar. Ändringarna gäller SSH-anslutningar; användare som använder Git över HTTPS behöver inte ändra några inställningar på grund av detta tillkännagivande.

I GitHubs tillkännagivande den 22 september står det att algoritmen blir tillgänglig på github.com och GitHub Enterprise Cloud med Data Residency, med undantag för USA-regionen. Detta är plattformens början på stödet: om den nya algoritmen faktiskt används beror också på SSH-klienten och dess inställningar.

Vad är det som ändras?

För nya RSA-SSH-nycklar som laddas upp efter den 14 oktober gäller en minsta längd på 3072 bitar. Befintliga RSA-nycklar behöver inte bytas enbart på grund av sin längd: GitHub rekommenderar att använda RSA-SHA-2-signaturer med dem – rsa-sha2-256 eller rsa-sha2-512. I dokumentationen rekommenderar företaget också Ed25519 för nya nycklar, när den typen passar arbetsmiljön.

Den andra ändringen gäller förhandlingen om sessionsnyckel. mlkem768x25519-sha256 kombinerar ML-KEM – en postkvantumbaserad algoritm för inkapsling av nycklar – med X25519. Enligt GitHubs plan kan kompatibla klienter som är konfigurerade att föredra algoritmen välja den automatiskt. Äldre klienter ska gå över till en algoritm som stöds.

Det här bör teamet kontrollera

1. Ta reda på hur anslutningen sker. Kontrollera Git-remote-adresserna: poster som börjar med https:// påverkas inte av SSH-ändringarna. För SSH bör ni kontrollera vilka klienter, bibliotek och integrationer som används.
2. Kontrollera RSA-signaturer. Säkerställ att klienten och biblioteket som används stöder RSA-SHA-2. GitHub anger minimiversioner för populära implementationer, däribland OpenSSH 7.2p1, Go SSH 0.16.0 och libssh2 1.11.0.
3. Kontrollera nya nycklar. Om organisationens policy kräver RSA måste en ny nyckel vara minst 3072 bitar. För en redan uppladdad RSA-nyckel är stöd för signaturalgoritmen viktigare än att skapa en ersättningsnyckel enbart på grund av den här ändringen.
4. Kontrollera klientstödet för ML-KEM. En plattformsuppdatering garanterar inte i sig att en viss klient väljer det nya nyckelutbytet. Kontrollera först klientens dokumentation och hur den beter sig vid en testanslutning; planera uppdateringar av äldre klienter enligt organisationens ordinarie schema.

Ett separat steg kommer senare: GitHub har planerat provvisa avstängningar av den föråldrade RSA-signaturen med SHA-1 och mekanismen diffie-hellman-group-exchange-sha256 till den 4 november och den 9 december 2026, och den slutliga avvecklingen är planerad till den 13 januari 2027. Därför bör dagens krav på längden för nya RSA-nycklar och det framtida borttagandet av äldre algoritmer hanteras som två skilda migreringsuppgifter.

För team är den praktiska prioriteringen i dag att inventera SSH-klienter och kontrollera RSA-SHA-2-stödet, och därefter testa stödet för ML-KEM separat. Tillgänglighet för användare i USA har ännu inte utlovats; kravet på storleken på nya RSA-nycklar gäller redan för uppladdningar efter den 14 oktober.