Zum Inhalt springen
Softwareentwicklung · SSH · Lieferfähigkeit

GitHub SSH-Umstellung 2026:
Ein Prüfplan für Entwicklung und CI

Veröffentlicht: 15. Oktober 2026·Zaid Aljbour, Geschäftsführer·12 Min. Lesezeit

Die GitHub SSH-Umstellung 2026 ist vor allem ein Inventar- und Kompatibilitätstest. Seit 14. Oktober akzeptiert GitHub neu hochgeladene RSA-Schlüssel erst ab 3072 Bit und unterstützt einen hybriden post-quantenresistenten Schlüsselaustausch. Am 4. November und 9. Dezember folgen Brownouts für zwei alte Verfahren; am 13. Januar 2027 werden sie entfernt.

Das größte Risiko liegt nicht auf aktuellen Entwicklerrechnern, sondern in unsichtbaren Pfaden: selbst gehostete CI-Runner, alte Java-Bibliotheken, Build-Appliances, Deploy Keys, Container-Images und Submodule. Ein erfolgreicher Test auf einem Laptop belegt deshalb noch keine sichere Lieferkette.

Kurzantwort: Erfassen Sie jeden Prozess, der per SSH mit GitHub spricht. Prüfen Sie Client-Version, ausgehandelten Signaturalgorithmus und Schlüsselaustausch. Testen Sie Checkout, Fetch, Submodule und Push aus der echten Laufzeit. Ersetzen Sie nur, was tatsächlich inkompatibel ist, und nutzen Sie die Brownouts als kontrollierten Ausfalltest.

Was GitHub ändert – und wann

TerminÄnderungPraktische Folge
14. Oktober 2026Neue RSA-Schlüssel benötigen mindestens 3072 Bit; mlkem768x25519-sha256 wird unterstütztNeue Schlüssel- und Automationspfade mit den aktiven Anforderungen testen
4. November 2026Erster Brownout für ssh-rsa mit SHA-1 und diffie-hellman-group-exchange-sha256Inkompatible Clients sollen kontrolliert sichtbar werden
9. Dezember 2026Zweiter BrownoutRestliche Ausnahmen und vergessene Laufzeiten finden
13. Januar 2027Entfernung der beiden alten VerfahrenBetroffene SSH-Pfade schlagen dauerhaft fehl

GitHub nennt als betroffen Git-Clients über SSH sowie bei GitHub Enterprise Server den unauthentifizierten Git-Transport. Remotes, die mit https:// beginnen, sind von dieser konkreten Änderung nicht betroffen. Prüfen Sie trotzdem Submodule und Skripte: Ein Haupt-Remote über HTTPS schließt zusätzliche SSH-URLs nicht aus.

RSA-Schlüssel und ssh-rsa sind nicht dasselbe

Der missverständliche Name ssh-rsa bezeichnet in diesem Kontext die alte RSA-Signatur mit SHA-1. Der öffentliche RSA-Schlüssel kann zugleich für die neueren Signaturen rsa-sha2-256 und rsa-sha2-512 verwendet werden. RFC 8332 standardisiert genau diese Trennung: Das Schlüsselformat bleibt ssh-rsa, während die Signatur SHA-256 oder SHA-512 nutzt.

Daraus folgt eine wichtige Migrationsregel: Rotieren Sie einen bestehenden RSA-Schlüssel nicht allein wegen seines Dateikopfs oder des angezeigten Schlüsseltyps. Entscheidend ist, welchen Signaturalgorithmus der reale Client aushandelt. Ein aktueller Client wählt RSA-SHA-2 üblicherweise automatisch. Ein altes Embedded-System kann dagegen trotz desselben Schlüssels nur SHA-1 anbieten.

GitHubs neue 3072-Bit-Grenze betrifft ab 14. Oktober neu hochgeladene RSA-Schlüssel. Wer für neue Zugänge keinen RSA-Kompatibilitätsgrund hat, kann GitHubs Empfehlung folgen und Ed25519 verwenden. Wer RSA benötigt, erzeugt mindestens 3072 Bit und dokumentiert, warum dieser Pfad bestehen bleibt.

Welche GitHub-SSH-Clients zuerst geprüft werden sollten

GitHub veröffentlicht Mindestversionen für robuste RSA-SHA-2-Unterstützung mit Standardkonfiguration. Dazu zählen OpenSSH 7.2p1, TeamCity 2021.2.3, Go SSH 0.16.0, libssh2 1.11.0 und PuTTY 0.82; für JSch verweist GitHub auf Version 0.1.66 eines gepflegten Forks. Diese Werte sind Startpunkte für das Inventar, kein Beweis für einen konkreten Prozess.

VerbindungspfadTypische BlindstelleBenötigter Nachweis
EntwicklerrechnerMehrere SSH-Installationen durch Betriebssystem, Git-Bundle oder WSLVersion und verbose Test aus dem tatsächlich genutzten Terminal
CI-RunnerAltes Basis-Image oder eingebettete BibliothekCheckout, Fetch, Submodule und Artefakt-Push im Runner
Deploy KeysSchlüsselinhaber und Laufzeit sind nicht dokumentiertRepository, Eigentümer, Client, Ablauf und Widerrufstest
Build- und Netzwerk-AppliancesSSH-Stack folgt nicht dem System-OpenSSHHerstellerangabe plus beobachtete Aushandlung
Container und JobsSelten gestartete Images entgehen dem TagesbetriebTest jedes Images und jedes zeitgesteuerten Pfads

Die Priorisierung ist ATMAN-Analyse. Beginnen Sie mit schreibenden Produktionspfaden und selten ausgeführten Wiederherstellungs- oder Release-Jobs. Ein Lesefehler im lokalen Clone ist sichtbar; ein erst im Notfall gestarteter Restore-Job kann monatelang unbemerkt inkompatibel bleiben.

GitHub SSH in sechs Schritten prüfen

  1. Remotes und Abhängigkeiten erfassen. Prüfen Sie mit git remote -v die Haupt-Remotes und suchen Sie zusätzlich in .gitmodules, Pipeline-Konfigurationen und Deployment-Skripten nach GitHub-SSH-URLs.
  2. Die reale Implementierung bestimmen. Führen Sie ssh -V in derselben Shell, demselben Container oder Runner aus, der später Git benutzt. Erfassen Sie bei Bibliotheken den Paketnamen und die Version.
  3. Schlüssel ohne Geheimnisinventar prüfen. Dokumentieren Sie Typ, Bitlänge, Fingerprint, Besitzer und Zweck der öffentlichen Schlüssel, zum Beispiel mit ssh-keygen -lf KEY.pub. Private Schlüssel oder Passphrasen gehören nicht in das Inventar.
  4. Die Aushandlung beobachten. Nutzen Sie ssh -vvT [email protected] in einer kontrollierten Umgebung. Prüfen Sie RSA-SHA-2 und einen unterstützten Schlüsselaustausch, statt nur die abschließende Erfolgsmeldung zu lesen. GitHubs erfolgreicher Authentisierungstest endet absichtlich mit Exit-Code 1, weil kein Shell-Zugang bereitgestellt wird.
  5. Den echten Git-Ablauf testen. Führen Sie einen read-only Fetch, Submodule-Initialisierung und – in einem freigegebenen Test-Repository – den schreibenden Pfad aus. Ein SSH-Handshake allein deckt Berechtigungen, Agenten, Proxys und eingebettete Git-Clients nicht vollständig ab.
  6. Brownout und Rollback vorbereiten. Benennen Sie Eigentümer, Testfenster, erwartetes Fehlerbild und eine zeitlich begrenzte Rückfalloption. HTTPS kann für ausgewählte Git-Abläufe eine Alternative sein, braucht aber eine eigene Token- und Secret-Steuerung.

Post-Quanten-SSH richtig einordnen

Der neue Name mlkem768x25519-sha256 bezeichnet einen hybriden Schlüsselaustausch. RFC 10042 kombiniert ML-KEM-768 mit X25519 und leitet daraus den gemeinsamen SSH-Schlüssel ab. „Hybrid“ bedeutet hier, dass die Verbindung nicht ausschließlich auf einem neuen post-quantenresistenten Verfahren beruht.

GitHub zufolge erfordert die Einführung normalerweise keine Nutzeraktion: Unterstützende Clients handeln das Verfahren aus, ältere Clients fallen auf andere angebotene Verfahren zurück. Die GitHub-Ankündigung nennt außerdem eine Ausnahme für die US-Region von GitHub Enterprise Cloud with Data Residency. Prüfen Sie deshalb beobachtete Verbindungen, statt aus einer Produktbezeichnung auf das ausgehandelte Verfahren zu schließen.

Diese Änderung ergänzt, ersetzt aber keine Migration von post-quantenresistentem TLS. SSH und TLS haben getrennte Protokolle, Bibliotheken, Endpunkte und Betriebsnachweise. Beide Vorhaben profitieren von einem reproduzierbaren Cloud-&-DevOps-Releaseprozess und einer risikobasierten Sicherheitsarchitektur.

Entscheidungsmatrix für die Migration

  • Aktueller Client, bestehender RSA-Schlüssel, RSA-SHA-2 beobachtet: Schlüssel beibehalten, Nachweis dokumentieren und Brownout testen.
  • Alter Client ohne RSA-SHA-2: Client oder Bibliothek aktualisieren; falls das nicht möglich ist, einen Ed25519- oder ECDSA-Pfad auf Kompatibilität prüfen.
  • Neuer RSA-Schlüssel erforderlich: mindestens 3072 Bit erzeugen, Upload- und Widerrufsprozess testen und den Eigentümer festhalten.
  • Unbekannter Deploy Key: nicht blind ersetzen. Zuerst Repository, Verbraucher und Abschaltweg ermitteln; dann in einem kontrollierten Fenster rotieren.
  • Nur HTTPS-Remotes: als nicht direkt betroffen dokumentieren, aber Submodule und eingebettete Abhängigkeiten separat prüfen.

Häufige Fragen zur GitHub SSH-Umstellung

Müssen bestehende RSA-Schlüssel für GitHub ersetzt werden?

Nicht allein wegen der Abschaltung von ssh-rsa. Ein bestehender RSA-Schlüssel kann weiterverwendet werden, wenn der SSH-Client mit RSA-SHA-2 signiert. GitHubs Mindestgröße von 3072 Bit betrifft neue RSA-Schlüssel, die ab 14. Oktober 2026 hochgeladen werden.

Wie prüft man, ob ein GitHub-SSH-Client betroffen ist?

Ermitteln Sie die tatsächlich verwendete SSH-Implementierung und Version, prüfen Sie die angebotenen Signatur- und Schlüsselaustauschalgorithmen und führen Sie eine verbose Testverbindung aus. Wiederholen Sie den Test aus CI-Runnern, Appliances und Containern, nicht nur vom Entwicklerrechner.

Sind HTTPS-Remotes von der GitHub-SSH-Umstellung betroffen?

Nein. GitHub erklärt, dass Git-Remotes mit https:// von diesen SSH-Änderungen nicht betroffen sind. Teams sollten dennoch prüfen, ob Submodule, Deploy-Skripte oder Werkzeuge intern SSH-URLs verwenden.

Muss ML-KEM für GitHub SSH manuell aktiviert werden?

In der Regel nicht. Unterstützende Clients handeln den hybriden Schlüsselaustausch automatisch aus; ältere Clients fallen auf andere unterstützte Verfahren zurück. Die dringende Aufgabe ist daher die Beseitigung veralteter Signatur- und Schlüsselaustauschpfade.

Mit einem vollständigen Verbindungspfad beginnen

Wählen Sie zuerst einen kritischen Build- oder Deployment-Pfad. Belegen Sie Remote, Laufzeit, Client-Version, öffentlichen Schlüssel, ausgehandelte Algorithmen, erfolgreichen Git-Ablauf und Widerruf. Erst wenn dieser Nachweis vollständig ist, übertragen Sie die Methode auf weitere Runner und Geräte. So wird aus der GitHub SSH-Umstellung 2026 ein kontrollierter Kompatibilitätswechsel statt eines ungeplanten Release-Ausfalls.

Quellen und Methodik

Dieser Beitrag trennt den von GitHub veröffentlichten Zeitplan und die IETF-Protokollgrundlagen von ATMANs Inventar-, Test- und Entscheidungsmodell. Die Checkliste ist technische Analyse, keine GitHub-Vorgabe und keine Garantie für jede SSH-Implementierung. Alle Quellen wurden am 15. Oktober 2026 abgerufen.