GitHub zmienia SSH: nowe klucze RSA muszą mieć co najmniej 3072 bity

Od 14 października GitHub przyjmuje nowe klucze RSA do uwierzytelniania i podpisywania tylko wtedy, gdy mają co najmniej 3072 bity. Tego samego dnia platforma włączyła dla połączeń SSH nową hybrydową metodę wymiany klucza mlkem768x25519-sha256, łączącą mechanizm postkwantowy z X25519.

To początek szerszej zmiany. GitHub zaplanował testowe okresy wyłączenia starszego podpisu RSA z SHA-1 oraz mechanizmu wymiany diffie-hellman-group-exchange-sha256 na 4 listopada i 9 grudnia 2026 roku. Ostateczne usunięcie obu ma nastąpić 13 stycznia 2027 roku.

Harmonogram i zakres pochodzą z oficjalnego komunikatu GitHuba.

Wniosek Breachroad: większość użytkowników nie musi tworzyć nowego klucza. Największe ryzyko operacyjne dotyczy starych klientów SSH ukrytych w serwerach CI/CD, narzędziach budujących, integracjach i urządzeniach, których nikt nie aktualizował od lat.

Kogo ta zmiana dotyczy

GitHub wskazuje dwie grupy:

osoby i automatyzacje korzystające z Git przez SSH;
użytkowników nieuwierzytelnionego protokołu Git w GitHub Enterprise Server.

Jeżeli adres zdalnego repozytorium zaczyna się od https://, ta konkretna zmiana SSH go nie obejmuje. Nie oznacza to jednak, że całe środowisko firmy używa HTTPS. Laptop programisty może działać poprawnie, gdy nocny build, serwer wdrożeniowy lub stara integracja nadal łączy się przez SSH.

Zmiany trafią również do GitHub Enterprise Server. GitHub podaje wersję 3.25 dla usunięć i nowych wymagań, natomiast obsługa mlkem768x25519-sha256 pojawi się już w wersji 3.24.

Istniejący klucz RSA nie musi być za krótki

Najłatwiejszym błędem interpretacyjnym byłoby założenie, że każdy istniejący klucz RSA trzeba natychmiast wymienić na 3072-bitowy. Wymóg długości dotyczy nowych kluczy przesyłanych po 14 października.

Istniejący klucz RSA może nadal działać, jeżeli klient używa podpisu RSA z SHA-2, czyli rsa-sha2-256 albo rsa-sha2-512. Wszystkie klucze RSA mogą podpisywać z użyciem tych algorytmów; problemem jest oprogramowanie, które potrafi negocjować wyłącznie starszy podpis ssh-rsa oparty na SHA-1.

Nazewnictwo bywa mylące. ssh-rsa może opisywać ogólny typ klucza widoczny w pliku publicznym, ale w kontekście negocjacji oznacza też podpis RSA z SHA-1. Sam prefiks klucza nie dowodzi więc, że połączenie korzysta ze słabego podpisu.

Które stare narzędzia warto znaleźć

GitHub podaje minimalne wersje zapewniające właściwą obsługę RSA z SHA-2 przy standardowej konfiguracji:

Oprogramowanie	Minimalna wersja wskazana przez GitHub
OpenSSH	7.2p1
JSch	0.1.66 z wymienionego przez GitHub forka
TeamCity	2021.2.3
Go SSH	0.16.0
libssh2	1.11.0
PuTTY	0.82

Lista nie jest pełnym spisem wszystkich aplikacji używających SSH. Biblioteka może być wbudowana w narzędzie, którego interfejs nigdy nie pokazuje jej nazwy. Dlatego inwentaryzacja powinna objąć nie tylko laptopy deweloperów, lecz także runnerów, systemy release, boty, kopie zapasowe, automaty wdrożeniowe i narzędzia dostawców.

Co zmieni się podczas brownoutu

Brownout to kontrolowane, czasowe wyłączenie starszego mechanizmu. Jego celem jest ujawnienie zależności przed terminem ostatecznym. Jeżeli połączenie potrafi użyć nowszego podpisu i silniejszej wymiany klucza, użytkownik nie powinien zauważyć różnicy. Stary klient może natomiast zgłosić błąd negocjacji i nie pobrać kodu.

Nie należy leczyć takiego błędu stałym ponownym włączeniem SHA-1 w całej organizacji. To może przywrócić działanie jednego zadania kosztem obniżenia bezpieczeństwa wielu innych połączeń. Właściwym celem jest aktualizacja klienta, biblioteki albo zależnej aplikacji. GitHub wskazuje Ed25519 jako preferowany typ dla nowych kluczy, gdy środowisko go obsługuje.

Plan dla zespołu przed 4 listopada

zinwentaryzuj adresy repozytoriów używane przez ludzi i automatyzacje;
oddziel połączenia HTTPS od SSH;
znajdź wersje klientów i bibliotek na runnerach, serwerach build oraz urządzeniach;
wskaż właściciela każdej integracji, zwłaszcza tej bez dokumentacji;
zaktualizuj komponenty poniżej wspieranych wersji;
wykonaj test pobrania i wysłania zmian z każdego istotnego środowiska;
obserwuj błędy negocjacji podczas brownoutu;
usuń awaryjne wyjątki po naprawie, aby nie zostały na stałe.

Warto też sprawdzić proces tworzenia nowych kluczy. Dokumentacja, szablony obrazów runnerów i konfiguracje narzędzi nie powinny nadal generować RSA 2048, skoro GitHub takiego nowego klucza już nie przyjmie.

Co oznacza dodanie ML-KEM

GitHub opisuje mlkem768x25519-sha256 jako nową, wydajną metodę wymiany odporną na przyszłe komputery kwantowe. Jest to podejście hybrydowe: bezpieczeństwo sesji nie zależy wyłącznie od jednego nowego prymitywu. Zgodny klient może wybrać nową metodę automatycznie, a starszy powinien przejść na inny nadal wspierany mechanizm.

Samo pojawienie się algorytmu nie oznacza, że firma zakończyła migrację postkwantową. SSH do GitHuba jest jednym protokołem wśród certyfikatów, VPN, podpisów, kopii zapasowych, bibliotek i urządzeń. Jest jednak dobrym sygnałem do zbudowania inwentaryzacji kryptografii oraz właścicieli zależności.

Fakty i rekomendacje

Daty, minimalne wersje, zakres użytkowników, wymaganie RSA 3072 oraz obsługa ML-KEM pochodzą z komunikatu GitHuba. GitHub nie twierdzi, że wszystkie istniejące klucze RSA są nieważne ani że użytkownicy HTTPS muszą zmienić konfigurację.

Inwentaryzacja CI/CD, testy biznesowo krytycznych automatyzacji i sposób obsługi wyjątków są rekomendacjami Breachroad. Szerszy kontekst opisujemy w poradnikach o bezpieczeństwie DevSecOps i CI/CD oraz migracji do kryptografii postkwantowej. Firmy, które chcą sprawdzić granice zaufania w procesie dostarczania kodu, mogą zacząć od testów penetracyjnych aplikacji webowych i API.