- Auf einem unveränderten Notebook schlug
git pull bei GitHub plötzlich fehl; nach dem Erzeugen der zum privaten Schlüssel passenden .pub-Datei funktionierte die Authentifizierung wieder
- Wenn eine
.pub-Datei vorhanden ist, präsentiert OpenSSH zuerst den öffentlichen Schlüssel, wartet auf die Zustimmung und signiert erst danach; fehlt sie, wird sofort eine signierte Authentifizierungsanfrage gesendet
- Beide Abläufe entsprechen RFC 4252 und werden auch von einem üblichen
sshd akzeptiert, doch das damalige GitHub-SSH-Frontend schien direkt signierte Anfragen nicht anzunehmen
- In 12 kontrollierten Tests wurden alle 6 Versuche ohne
.pub-Datei abgelehnt, während alle 6 Versuche mit Datei erfolgreich waren
- Eine Änderung des Server-Banners deutet auf eine mögliche serverseitige Softwareänderung hin; da die genaue Ursache aber nicht bestätigt ist, ist es sicherer, die zugehörige öffentliche Schlüsseldatei mitzuführen
Plötzlicher Authentifizierungsfehler und Lösung
- Auf dem primären Notebook brach
git pull mit dem Fehler Permission denied (publickey) ab
- Der betreffende Schlüssel war weiterhin bei GitHub registriert
- Auf einem anderen Notebook, das einen anderen Schlüssel verwendete, ließ sich dasselbe Repository normal abrufen
- An Schlüssel und Client-Konfiguration ließ sich kein Problem finden
openssl rsa -check gab RSA key ok zurück- Verwendet wurde der aktuelle Signaturalgorithmus
rsa-sha2-512
- In
~/.ssh/config gab es kein Problem, und die GitHub-Statusseite meldete ebenfalls keine Störung
- Nach einer Neuinstallation fehlte die zum Schlüssel
~/.ssh/github_rsa gehörende öffentliche Schlüsseldatei; nach dem Erzeugen mit folgendem Befehl war die Authentifizierung erfolgreich
ssh-keygen -y -f ~/.ssh/github_rsa > ~/.ssh/github_rsa.pub
- In kontrollierten Tests schlugen alle 6 Versuche ohne
.pub-Datei fehl, während alle 6 Versuche mit Datei erfolgreich waren
Je nach .pub-Datei unterschiedlicher Authentifizierungsablauf
- OpenSSH nutzt je nach Vorhandensein der
.pub-Datei unterschiedliche Public-Key-Authentifizierungsabläufe
- Ist die Datei vorhanden, wird zuerst der öffentliche Schlüssel präsentiert und die Zustimmung des Servers abgewartet, bevor signiert wird
- Ist nur der private Schlüssel vorhanden, wird die Vorabprüfung übersprungen und direkt eine vollständig signierte Authentifizierungsanfrage gesendet
- Beide Methoden sind nach RFC 4252 zulässig, und ein übliches
sshd akzeptiert beide
- Bei GitHub wurden damals direkt signierte Public-Key-Anfragen abgelehnt, ob es tatsächlich eine Änderung auf GitHub-Seite gab, ist jedoch nicht bestätigt
- Das Server-Banner im Debug-Log erschien nicht im früheren Format
babeld-<hash>, sondern als 6a2c000
- Die Möglichkeit, dass neue Serversoftware direkt signierte Anfragen ablehnte, bleibt eine Vermutung
- Um dasselbe Problem zu vermeiden, sollte die zum privaten Schlüssel gehörende
.pub-Datei mitgeführt werden
1 Kommentare
Kommentare auf Lobste.rs
Ich habe seit den letzten 4 Stunden dasselbe Problem; es ist bereits unter https://www.githubstatus.com/incidents/g40zcbvchny4 erfasst.
Vor ein paar Wochen habe ich meinen SSH-Schlüssel ausgetauscht, aber die alte
.pub-Datei, die von Git ignoriert wurde, nicht gelöscht. Auch mit dem neuen Schlüssel schlug die Verbindung weiterhin fehl.Erst nachdem ich mehrere Debug-Optionen aktiviert hatte, merkte ich, dass der SSH-Client noch den alten Fingerprint sendete. Mir war nicht einmal bewusst, dass OpenSSH
.pub-Dateien liest; ich hatte sie bisher für völlig überflüssig gehalten.Heute hatten wir offenbar denselben Ausfall: Unser CI-Server konnte plötzlich keine Verbindung zu github.com herstellen.
Nachdem wir den Schlüssel durch den richtigen ed25519-Schlüssel ersetzt hatten, funktionierte es wieder, aber auch zu diesem Schlüssel gibt es keine passende
.pub-Datei, daher ist unklar, warum das die Lösung war.Ich hatte heute dasselbe Problem; soweit ich weiß, gab es keine Ankündigung, dass GitHub eine Änderung am SSH-Authentifizierungsverhalten geplant hatte.
Ich hatte sowohl mein Passwort als auch meine Wiederherstellungsschlüssel verloren und den Prozess zur kontobasierten Wiederherstellung per SSH-Schlüssel durchlaufen, aber GitHub hat diesen SSH-Schlüssel als abgelaufen markiert, wodurch ich den Zugriff auf mein Konto vollständig verloren habe.
Ich glaube, ich hatte seit 7–8 Jahren keine
.pub-Datei mehr liegen. Ich hoffe, das Problem ist behoben, bevor ich GitHub das nächste Mal nutze.Wenn beide Authentifizierungsabläufe legitim sind, frage ich mich, warum es den Key-Discovery-Ablauf überhaupt gibt.
Er scheint nur solches merkwürdiges Verhalten zu verursachen, und wenn sich der Public Key ohnehin aus dem Private Key erzeugen lässt, sollte SSH das doch automatisch erledigen können.
SSH prüft zuerst, welcher Schlüssel beim Server funktionieren könnte, damit Nutzer keinen Schlüssel unnötig entschlüsseln müssen, der bei der Authentifizierung sicher scheitern würde.
Dieses Verhalten hat auch ungewöhnliche Nebeneffekte wie https://github.com/FiloSottile/whoami.filippo.io; daher muss auch ein Modus erlaubt sein, bei dem der Server den Public Key des Clients vorab kennen muss, bevor eine Authentifizierung versucht werden kann – für den Fall, dass Nutzer versehentlich eine Verbindung zum falschen Server herstellen.
Mein berufliches Office-365-Konto hat heute ebenfalls zum ersten Mal seit 5 Jahren plötzlich aufgehört zu funktionieren.
Ich frage mich, ob es bei Microsoft einen Sicherheitsvorfall gab und alle Werte neu gesalzen wurden, oder ob das nur europäische Nutzer betrifft – wegen der jüngsten Abstimmung zu Chat Control 1.0.
Da ich eine der zwei Personen bin, von denen ich weiß, dass sie sowohl an GitHubs Git Systems als auch an Microsofts Office/M365-Produktreihe gearbeitet haben, darf ich das ziemlich sicher behaupten.
Selbst wenn eine Richtlinien- oder Technikänderung zugrunde läge, die für beide Dienste gleichermaßen gilt, sind die Systeme voneinander getrennt, sodass es äußerst unwahrscheinlich wäre, dass sie am selben Tag ausgerollt wird.