GitHub wdraża postkwantową wymianę kluczy SSH — na razie nie w USA

Dziś, 14 października 2026 roku, GitHub zaczyna stosować dwie zmiany dotyczące SSH: nowe przesyłane klucze RSA muszą mieć co najmniej 3072 bity, a dla części połączeń włączany jest postkwantowy algorytm wymiany kluczy mlkem768x25519-sha256. Zmiany dotyczą połączeń SSH; użytkownicy Git przez HTTPS nie muszą zmieniać ustawień w związku z tym ogłoszeniem.

W ogłoszeniu GitHub z 22 września podano, że algorytm będzie dostępny na github.com i w GitHub Enterprise Cloud z Data Residency, z wyjątkiem regionu USA. To początek obsługi po stronie platformy: faktyczne wykorzystanie nowego algorytmu zależy również od klienta SSH i jego ustawień.

Co dokładnie się zmienia

Dla nowych kluczy RSA SSH przesyłanych po 14 października ustalono minimum 3072 bitów. Nie trzeba wymieniać już istniejących kluczy RSA wyłącznie ze względu na ich długość: GitHub zaleca używanie z nimi podpisów RSA-SHA-2 — rsa-sha2-256 lub rsa-sha2-512. W dokumentacji firma zaleca również Ed25519 dla nowych kluczy, jeśli ten typ pasuje do danego środowiska pracy.

Druga zmiana dotyczy uzgadniania klucza sesji. mlkem768x25519-sha256 łączy ML-KEM — postkwantowy algorytm enkapsulacji kluczy — z X25519. Zgodnie z planem GitHub zgodne klienty skonfigurowane tak, by preferować ten algorytm, będą mogły wybierać go automatycznie. Starsze klienty powinny przechodzić na obsługiwany algorytm zgodności.

Co sprawdzić w zespole

1. Ustal sposób połączenia. Sprawdź adresy zdalnych repozytoriów Git: wpisy zaczynające się od https:// nie podlegają zmianom SSH. W przypadku SSH sprawdź używane klienty, biblioteki i integracje.
2. Sprawdź podpisy RSA. Upewnij się, że klient i używana biblioteka obsługują RSA-SHA-2. GitHub wskazuje minimalne wersje popularnych implementacji, w tym OpenSSH 7.2p1, Go SSH 0.16.0 i libssh2 1.11.0.
3. Sprawdź nowe klucze. Jeśli polityka organizacji wymaga RSA, nowy klucz musi mieć co najmniej 3072 bity. W przypadku już przesłanego klucza RSA ważniejsza jest obsługa algorytmu podpisu niż generowanie zamiennika wyłącznie z powodu tej zmiany.
4. Sprawdź obsługę ML-KEM w kliencie. Sama aktualizacja platformy nie gwarantuje, że konkretny klient wybierze nową metodę wymiany kluczy. Najpierw sprawdź jego dokumentację i działanie podczas połączenia testowego; w przypadku starszych klientów zaplanuj aktualizację zgodnie z harmonogramem przyjętym w organizacji.

Osobny etap rozpocznie się później: GitHub wyznaczył testowe wyłączenia przestarzałego podpisu RSA z SHA-1 oraz mechanizmu diffie-hellman-group-exchange-sha256 na 4 listopada i 9 grudnia 2026 roku, a ostateczne usunięcie zaplanował na 13 stycznia 2027 roku. Dlatego dzisiejszy wymóg dotyczący długości nowych kluczy RSA i przyszłe wycofanie starszych algorytmów należy traktować jako dwa odrębne zadania migracyjne.

Dzisiejszy praktyczny priorytet dla zespołów to inwentaryzacja klientów SSH i sprawdzenie RSA-SHA-2, a następnie osobne testy obsługi ML-KEM. Dostępność nowego algorytmu dla użytkowników w USA nie została na razie ogłoszona; wymóg dotyczący rozmiaru nowych kluczy RSA obowiązuje już przy przesyłaniu kluczy po 14 października.