Lösung häufiger Git-Authentifizierungsfehler mit SSH und Tokens

Die meisten Git-Authentifizierungsprobleme beruhen auf einer Diskrepanz zwischen der Remote-URL, den Anmeldeinformationen, die Git zu verwenden versucht, und den Berechtigungen des Git-Hosting-Kontos. Die Fehlermeldung kann dramatisch aussehen, aber die Behebung ist in der Regel mechanisch, sobald Sie wissen, welchen Pfad Git einschlägt.

Beginnen Sie mit der Remote-URL:

git remote -v

Wenn Sie https://github.com/org/repo.git sehen, verwendet Git HTTPS und benötigt einen Benutzernamen sowie ein Token oder einen Credential-Helper, der eines bereitstellen kann. Wenn Sie [email protected]:org/repo.git sehen, verwendet Git SSH und benötigt einen privaten Schlüssel, der mit einem beim Host registrierten öffentlichen Schlüssel übereinstimmt.

Vermischen Sie die beiden nicht während der Fehlersuche. Entscheiden Sie sich für HTTPS oder SSH, passen Sie die Remote-URL entsprechend an und testen Sie dann diesen Pfad direkt.

Lesen Sie den Fehler wörtlich

fatal: Authentication failed for 'https://...' bedeutet normalerweise, dass Git den Server erreicht, aber keine gültigen HTTPS-Anmeldeinformationen vorgelegt hat. Die alten Anmeldeinformationen könnten zwischengespeichert sein, das Token könnte abgelaufen sein oder das Token hat möglicherweise keinen Zugriff auf dieses Repository.

remote: Permission to org/repo denied oder 403 Forbidden bedeutet normalerweise, dass Ihre Identität erkannt wurde, aber keine Berechtigung für den Vorgang hat. Beispielsweise verwenden Sie möglicherweise ein Token vom falschen Konto, ein Token ohne Schreibzugriff oder einen SSH-Schlüssel, der einem anderen Benutzer zugeordnet ist.

Permission denied (publickey) bedeutet, dass SSH keinen Schlüssel angeboten hat, den der Server akzeptiert.

Eine wiederholte Aufforderung zur Eingabe von Benutzername/Passwort über HTTPS bedeutet normalerweise, dass Git immer wieder eine Ablehnung erhält und erneut nachfragt. Die wiederholte Eingabe Ihres Kontopassworts hilft auf Hosts, die für Git-Operationen Tokens benötigen, nicht weiter.

Behebung von HTTPS mit einem persönlichen Zugriffstoken

Erstellen Sie für HTTPS-Remotes ein persönliches Zugriffstoken in den Kontoeinstellungen Ihres Git-Hosts. Die genauen Menünamen unterscheiden sich zwischen GitHub, GitLab, Bitbucket und selbst gehosteten Plattformen, aber das Prinzip ist dasselbe: Erstellen Sie ein Token, gewähren Sie ihm Repository-Zugriff, legen Sie ein Ablaufdatum fest, das Ihrer Organisationsrichtlinie entspricht, und kopieren Sie es sofort.

Wenn Git Sie auffordert, verwenden Sie Ihren normalen Benutzernamen und fügen Sie das Token als Passwort ein:

Username: your-username
Password: <paste-token-here>

Verwenden Sie die engsten Berechtigungen, die funktionieren. Für ein privates Repository, in das Sie pushen, benötigen Sie Lese- und Schreibzugriff auf das Repository. Zum Klonen öffentlicher Repositorys benötigen Sie möglicherweise überhaupt kein Token. Feingranulare Tokens und Organisations-SSO-Regeln können eine weitere Ebene hinzufügen: Ein Token kann vorhanden sein, benötigt aber möglicherweise noch eine Genehmigung oder SSO-Autorisierung, bevor es auf ein Unternehmensrepository zugreifen kann.

Wenn Git nie nach dem neuen Token fragt, verwendet es wahrscheinlich einen alten zwischengespeicherten Credential. Löschen Sie den gespeicherten Eintrag für den Host und versuchen Sie es dann erneut.

Unter macOS überprüfen Sie den Schlüsselbund auf Einträge, die sich auf Ihren Git-Host beziehen, wie z. B. github.com oder git:https://github.com.

Unter Windows öffnen Sie den Credential-Manager und entfernen Sie den relevanten generischen Credential für den Host.

Unter Linux überprüfen Sie Ihren konfigurierten Helper:

git config --global --get credential.helper
git config --show-origin --get-all credential.helper

Der cache-Helper speichert Anmeldeinformationen vorübergehend im Speicher. Der store-Helper schreibt sie im Klartext auf die Festplatte, es sei denn, Sie konfigurieren eine sicherere Speicherschicht. Verwenden Sie ihn daher mit Vorsicht. Das Credential-Helper-System von Git ist so konzipiert, dass es Helper nach Anmeldeinformationen fragt und Helpern erlaubt, erfolgreiche zu speichern; die Sicherheit hängt von dem von Ihnen gewählten Helper ab.

Eine nützliche HTTPS-Zurücksetzungssequenz ist:

git remote -v
git config --show-origin --get-all credential.helper
# entfernen Sie den alten Credential aus dem OS-Credential-Speicher
git ls-remote origin

git ls-remote origin ist ein sauberer Test, da es das Remote kontaktiert, ohne Ihren Arbeitsbaum zu verändern.

Behebung von SSH mit Schlüsseln

Überprüfen Sie für SSH-Remotes zunächst, ob Sie bereits Schlüssel haben:

ls -al ~/.ssh

Häufige Schlüsselnamen sind id_ed25519, id_rsa und hostspezifische Namen wie github_work_ed25519. Die .pub-Datei ist der öffentliche Schlüssel, den Sie auf den Git-Host hochladen. Die Datei ohne .pub ist privat und sollte nicht weitergegeben werden.

Wenn Sie einen neuen Schlüssel benötigen, ist Ed25519 auf modernen Systemen eine gute Standardwahl:

ssh-keygen -t ed25519 -C "[email protected]"

Verwenden Sie eine Passphrase, es sei denn, Ihre Umgebung hat einen spezifischen Automatisierungsgrund, dies nicht zu tun. Fügen Sie dann den öffentlichen Schlüssel zu Ihrem Git-Host-Konto oder den Deploy-Key-Einstellungen hinzu:

cat ~/.ssh/id_ed25519.pub

Testen Sie die Verbindung direkt:

ssh -T [email protected]

Ersetzen Sie für GitLab oder Bitbucket den Hostnamen. Ein erfolgreicher Test gibt normalerweise eine Begrüßung oder eine Nachricht aus, dass kein Shell-Zugriff gewährt wird. Das ist in Ordnung; Git-over-SSH-Authentifizierung kann trotzdem funktionieren.

Wenn SSH immer noch fehlschlägt, fragen Sie den SSH-Client, was er tut:

ssh -vT [email protected]

Achten Sie auf Zeilen, die anzeigen, welche Schlüssel angeboten werden. Wenn Ihr Schlüssel nicht angeboten wird, laden Sie ihn in den Agenten:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Für mehrere Konten auf demselben Host verwenden Sie ~/.ssh/config, damit Git weiß, welcher Schlüssel zu welchem Remote gehört:

Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/github_work_ed25519
  IdentitiesOnly yes

Zeigen Sie dann das Repository auf diesen Alias:

git remote set-url origin git@github-work:org/repo.git

Dies vermeidet das häufige Problem, dass SSH Ihren persönlichen Schlüssel für ein Arbeitsrepository anbietet.

Sauberer Protokollwechsel

Wenn Ihr Team auf SSH standardisiert, ändern Sie ein HTTPS-Remote wie folgt:

git remote set-url origin [email protected]:ORG/REPO.git

Wenn Ihr Unternehmen SSH blockiert oder eine HTTPS-Inspektion erfordert, wechseln Sie in die andere Richtung:

git remote set-url origin https://github.com/ORG/REPO.git

Testen Sie nach dem Ändern der URL mit einem Lesevorgang:

git fetch origin

Testen Sie dann die Aktion, die fehlgeschlagen ist:

git push origin HEAD

Wenn fetch funktioniert, aber push fehlschlägt, ist die Authentifizierung wahrscheinlich gültig und die Autorisierung das Problem. Überprüfen Sie Branch-Schutz, Repository-Rolle, Token-Bereich und Organisations-SSO-Regeln.

CI- und Serverumgebungen

Vermeiden Sie auf Build-Agenten und Servern nach Möglichkeit die Verwendung eines persönlichen Tokens einer Person. Bevorzugen Sie Deploy-Keys, Maschinenbenutzer oder den integrierten Credential-Speicher Ihres CI-Systems. Halten Sie Geheimnisse aus dem Befehlsverlauf und den Protokollen fern. Fügen Sie Tokens nicht wie folgt in Remote-URLs ein, es sei denn, Sie befinden sich in einer kontrollierten Wegwerfumgebung:

https://[email protected]/org/repo.git

Dieser Stil kann über Protokolle, Prozesslisten, Shell-Verlauf und Konfigurationsdateien durchsickern.

Speichern Sie für Jenkins, GitHub Actions-Runner, GitLab-Runner und ähnliche Systeme Anmeldeinformationen im Secret-Mechanismus der Plattform und injizieren Sie sie nur für den Job, der sie benötigt.

Eine kurze Checkliste

Führen Sie diese in der Reihenfolge aus, wenn Sie nicht weiterkommen:

git remote -v
git ls-remote origin

Wenn die URL HTTPS ist, löschen Sie alte zwischengespeicherte Anmeldeinformationen und verwenden Sie ein aktuelles Token mit den richtigen Repository-Berechtigungen.

Wenn die URL SSH ist, führen Sie Folgendes aus:

ssh -T git@your-hostname
ssh -vT git@your-hostname

Bestätigen Sie, dass der erwartete Schlüssel angeboten wird und dass seine öffentliche Hälfte beim richtigen Konto registriert ist.

Wenn die Authentifizierung erfolgreich ist, aber der Push fehlschlägt, suchen Sie nach Autorisierungsregeln: geschützte Branches, fehlende Schreibrolle, abgelaufene SSO-Autorisierung, schreibgeschützte Deploy-Keys oder Tokens ohne Schreibberechtigung.

Die zuverlässige Lösung besteht nicht darin, zufällige Passwörter auszuprobieren. Passen Sie das Remote-Protokoll an den Credential-Typ an, entfernen Sie veraltete zwischengespeicherte Anmeldeinformationen, testen Sie die Verbindung direkt und überprüfen Sie dann die Berechtigungen des Repositorys.