GitHub SSH-Brownout: alte Algorithmen vor dem 4. November finden

Ein geplanter Ausfall ist besser als ein überraschender

GitHub modernisiert seine SSH-Sicherheit. Am 4. November 2026 findet der erste Brownout statt: Verbindungen, die noch die alte RSA-Signatur mit SHA-1 oder den Key Exchange diffie-hellman-group-exchange-sha256 benötigen, sollen während des Testfensters scheitern. Ein zweiter Brownout ist für den 9. Dezember angekündigt, die endgültige Abschaltung für den 13. Januar 2027.

Das ist kein Anlass, hektisch alle Schlüssel zu ersetzen. Es ist ein Anlass, die tatsächlichen Clients zu finden. Entwickler-Laptops sind oft aktuell; vergessene Build-Images, selbst gehostete Runner, Deploy-Appliances oder eingebettete Git-Bibliotheken sind es nicht.

Die beste Vorbereitung besteht aus Inventar, Messung und einem getesteten Update — nicht aus einer globalen Ausnahme für schwache Algorithmen.

Was GitHub genau ändert

GitHub hat vier relevante Änderungen angekündigt:

• Die RSA-Signatur ssh-rsa mit SHA-1 wird entfernt.
• diffie-hellman-group-exchange-sha256 wird als Key-Exchange-Verfahren entfernt.
• Neue RSA-Schlüssel, die seit dem 14. Oktober 2026 hochgeladen werden, müssen mindestens 3072 Bit besitzen.
• mlkem768x25519-sha256 wird als post-quantenresistenter Key Exchange unterstützt, mit der von GitHub dokumentierten regionalen Ausnahme.

HTTPS-Remotes und Pushes über HTTPS sind davon nicht betroffen. Relevant sind SSH-Verbindungen zu GitHub sowie bestimmte unauthentifizierte Git-Verbindungen bei GitHub Enterprise Server.

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

Die verwirrendste Stelle ist der Name ssh-rsa. Er kann den RSA-Schlüsseltyp meinen oder die alte Signaturvariante RSA mit SHA-1. GitHub entfernt die schwache Signatur, nicht automatisch jeden vorhandenen RSA-Schlüssel.

Ein vorhandener RSA-Schlüssel kann mit rsa-sha2-256 oder rsa-sha2-512 weiterverwendet werden, sofern Client und Bibliothek diese Signaturen unterstützen. GitHub sagt deshalb ausdrücklich, dass betroffene Nutzer nicht pauschal einen neuen Schlüssel erzeugen müssen.

In der Praxis ist häufig nicht der Schlüssel das Problem, sondern ein alter SSH-Client, der mit demselben Schlüssel nur ssh-rsa anbietet.

Wer besonders genau hinschauen sollte

Das Risiko sitzt dort, wo Software selten aktualisiert wird:

• selbst gehostete CI-Runner mit alten Betriebssystem-Images;
• Docker-Images, die OpenSSH oder Git seit Jahren pinnen;
• Build-Tools mit eingebettetem JGit, libgit2 oder eigener SSH-Implementierung;
• Deployment-Appliances und NAS-Systeme;
• alte IDEs mit gebündeltem SSH-Client;
• Automationen, die eine eigene ~/.ssh/config mit Legacy-Ausnahmen mitbringen;
• GitHub Enterprise Server-Umgebungen mit heterogenen Clients.

Ein grüner Test auf dem Laptop beweist nur, dass dieser eine Laptop funktioniert.

In zehn Minuten ein belastbares Inventar bauen

Beginnt bei den Verbindungen, nicht bei den Schlüsseldateien:

1. Mit git remote -v prüfen, welche Repositories SSH statt HTTPS nutzen.
2. Mit ssh -V die tatsächlich ausgeführte OpenSSH-Version erfassen.
3. Mit ssh -Q PubkeyAcceptedAlgorithms die unterstützten Signaturen prüfen.
4. Mit ssh -Q kex die verfügbaren Key-Exchange-Verfahren auflisten.
5. Mit ssh -G github.com die nach allen Includes wirksame Konfiguration ausgeben.
6. Mit ssh -vvT git@github.com einen Diagnose-Handshake durchführen und die ausgehandelten Verfahren lesen.

Verbose-Logs können Hostnamen, Benutzernamen, Pfade und Schlüssel-Fingerprints enthalten. Sie gehören nicht ungeprüft in öffentliche Tickets oder Chat-Kanäle.

CI und Deployments dort testen, wo sie wirklich laufen

Führt die Diagnose im Runner-Image aus, nicht nur auf dem Host. Bei containerisierten Jobs gehören mindestens diese Werte in einen temporären Audit-Step:

• Ausgabe von ssh -V;
• Git-Version und verwendete SSH-Implementierung;
• Remote-Schema;
• wirksame Host-Konfiguration;
• Ergebnis eines read-only Authentifizierungstests;
• Basis-Image und Digest.

Bei matrix-basierten Pipelines reicht ein erfolgreicher Linux-Runner nicht. macOS, Windows, ARM-Runner und alte Release-Jobs können andere Clients laden. Dasselbe gilt für Produktionsdeployments, die außerhalb der normalen CI laufen.

Der sichere Fix ist ein Update, keine Legacy-Ausnahme

Wenn ein Client nur die entfernten Verfahren beherrscht, ist die bevorzugte Reihenfolge:

1. OpenSSH, Git oder die eingebettete SSH-Bibliothek aktualisieren.
2. Veraltetes Basis-Image neu bauen und per Digest ausrollen.
3. Konfigurationen entfernen, die moderne Algorithmen versehentlich ausschließen.
4. Falls nötig einen neuen Ed25519- oder ausreichend großen RSA-Schlüssel erzeugen und kontrolliert rotieren.
5. Den alten Schlüssel erst nach erfolgreichem Paralleltest entfernen.

Eine globale Zeile, die ssh-rsa wieder aktiviert, konserviert das Problem und kann auch Verbindungen zu anderen Hosts schwächen. Eine kurzfristige Ausnahme gehört höchstens host-spezifisch, befristet und mit Owner in ein dokumentiertes Recovery-Verfahren.

Nicht jede Fehlermeldung meint dasselbe

Während des Brownouts können ähnliche Symptome unterschiedliche Ursachen haben:

• no matching host key type betrifft die Identität des Servers;
• no mutual signature algorithm betrifft die Signatur für den Benutzerschlüssel;
• no matching key exchange method betrifft den Aufbau des Sitzungsschlüssels;
• Permission denied (publickey) kann zusätzlich einen falschen Key, Agent oder Account bedeuten.

Darum ist ssh -vv wichtiger als blindes Ändern der Konfiguration. Erst die ausgehandelte Phase bestimmt den richtigen Fix.

Brownout als kontrollierten Testtag nutzen

Ein Brownout ist ein kostenloser Probelauf für Januar. Plant ihn wie ein kleines Change Window:

• Owner für CI, Deployments und Entwicklerzugänge benennen;
• kritische Repositories und Release-Wege priorisieren;
• vor dem Fenster einen bekannten Commit per Fetch testen;
• während des Fensters Fehlerrate und Job-Abbrüche beobachten;
• Logs mit Runner-Image und Client-Version korrelieren;
• Fixes noch am selben Tag in einem aktualisierten Image reproduzieren;
• Erkenntnisse in ein Runbook für den 9. Dezember und 13. Januar übernehmen.

Der Test ist erst bestanden, wenn auch seltene Wege funktionieren: Hotfix-Deploy, Rollback, Tag-Signierung und Disaster-Recovery-Runner.

Ein kleiner Test verhindert einen großen Januar

Für jede relevante Ausführungsumgebung sollte ein automatisierter Smoke-Test existieren, der ohne Schreibzugriff auskommt. Er kann einen bekannten öffentlichen oder internen Repository-Ref lesen und bei SSH-Negotiation-Fehlern klar abbrechen.

Der Test sollte die Client-Version mitspeichern, aber keine privaten Schlüssel oder vollständigen Verbose-Logs als Build-Artefakt veröffentlichen. Ein täglicher Lauf bis Januar ist sinnvoller als ein einmaliger Screenshot aus Oktober.

Wenn ihr mehrere Git-Hosts nutzt, testet sie getrennt. GitHubs Abschaltung sagt nichts über die Policy eures internen Git-Servers aus.

Unser 48-Stunden-Plan

Vor dem 4. November würden wir so vorgehen:

1. SSH-Remotes und produktionskritische Jobs inventarisieren.
2. Alle Runner-Images mit Client-Version und Digest erfassen.
3. Read-only Handshakes aus jeder Umgebung ausführen.
4. Legacy-Treffer nach Geschäftskritikalität sortieren.
5. Images und Bibliotheken aktualisieren, dann parallel testen.
6. Brownout-Monitoring und einen erreichbaren Owner festlegen.
7. Den zweiten Test am 9. Dezember bereits terminieren.

Damit wird aus einer angekündigten Abschaltung eine normale Wartungsaufgabe.

Fazit

GitHubs SSH-Änderung ist technisch überschaubar. Das eigentliche Risiko liegt in unsichtbaren Clients, die niemand mehr auf dem Inventar hat.

Wer nur Schlüsseldateien zählt, übersieht alte Signatur- und Key-Exchange-Implementierungen. Wer aus jeder realen Laufzeitumgebung misst, findet das Problem vor dem Brownout — und kann es mit einem normalen Update lösen, statt im Januar schwache Kryptografie wieder einzuschalten.

Primärquellen

• GitHub Changelog: Security improvements for SSH
• GitHub Docs: Testing your SSH connection
• OpenBSD manual: ssh_config
• OpenBSD manual: ssh