WardtermSSH-Client
DE
Herunterladen

"git@github.com: Permission denied (publickey)": so beheben Sie den Fehler

GitHub hat keinen der Schlüssel akzeptiert, die Ihr SSH-Client angeboten hat. Führen Sie ssh -vT git@github.com aus, um zu sehen, welche Schlüssel angeboten werden. Stellen Sie dann sicher, dass es der in Ihrem GitHub-Konto hinterlegte Schlüssel ist, dass er geladen oder in ~/.ssh/config benannt ist und dass Sie sich als Benutzer git verbinden. Nutzen Sie kein sudo git, das sucht nach den Schlüsseln von root. Dieselben Prüfungen gelten für GitLab mit ssh -T git@gitlab.com.

Passiert das bei git pull auf einem Server? Wardterm kann diesem Server Ihren Schlüssel für die Sitzung leihen, ohne ihn dorthin zu kopieren. Zeigen

Aktualisiert am . Der Git-Fehlertext, ssh -G, core.sshCommand und git-remote-Befehle wurden mit OpenSSH 10.3 und Git unter macOS gegen einen lokalen Testserver mit einem Wegwerf-Schlüssel ausgeführt.

Was Sie sehen

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Die erste Zeile ist der eigentliche Fehler, und er kommt von SSH. Die Zeilen von Git erscheinen auch bei vielen anderen Fehlern, lassen Sie sich also nicht dazu verleiten, beim Repository zu suchen.

SSH ohne Git testen

ssh -T git@github.com

Wird der Schlüssel akzeptiert, begrüßt GitHub Sie und schließt die Verbindung. Der Exit-Status ist auch dann 1, weil GitHub keine Shell anbietet:

Hi username! You've successfully authenticated, but GitHub does not provide shell access.
  • Sie erhalten Permission denied (publickey): Folgen Sie den Ursachen unten.
  • Sie erhalten die Begrüßung mit einem anderen als dem erwarteten Namen: SSH verwendet einen Schlüssel eines anderen Kontos. Siehe Ursache 3.
  • Sie erhalten die Begrüßung mit dem richtigen Namen, aber Git scheitert mit Repository not found: Ihr Konto hat keinen Zugriff auf dieses Repository, oder die URL ist falsch.

Ursache 1: Es wird kein oder der falsche Schlüssel angeboten

ssh -vT git@github.com 2>&1 | grep -E 'identity file|Offering|Authentications'

Eine Zeile, die auf type -1 endet, heißt, dass SSH keine solche Datei gefunden hat. SSH sucht nach Standardnamen wie ~/.ssh/id_ed25519 und ~/.ssh/id_rsa. Ohne jede Zeile Offering public key wurde nichts versucht. Sehen Sie nach, was vorhanden ist:

ls -l ~/.ssh/
ssh-add -l

Hat Ihr Schlüssel einen anderen Dateinamen, teilen Sie das SSH in ~/.ssh/config mit:

Host github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github
  IdentitiesOnly yes

Prüfen Sie das Ergebnis, ohne sich zu verbinden:

ssh -G github.com | grep -E '^(user|identityfile|identitiesonly) '

Haben Sie gar keinen Schlüssel, folgen Sie SSH-Schlüssel zu GitHub hinzufügen.

Ursache 2: Der öffentliche Schlüssel ist nicht in Ihrem Konto

Vergleichen Sie Fingerprints, nicht das Aussehen des Schlüssels:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Öffnen Sie dann GitHub, Settings, SSH and GPG keys, und suchen Sie denselben SHA256:-Wert. Fehlt er, fügen Sie den Inhalt der .pub-Datei hinzu. Fügen Sie niemals den privaten Schlüssel ein. Ein Schlüssel, der in einem Repository als Deploy Key dient, kann nicht zusätzlich einem Konto hinzugefügt werden.

Ursache 3: Das falsche Konto

Haben Sie ein berufliches und ein privates Konto, gewinnt der erste Schlüssel, den GitHub erkennt, auch wenn er zum anderen Konto gehört. IdentitiesOnly yes wie oben beschränkt SSH auf den Schlüssel, den Sie nennen. Um zwei Konten nebeneinander zu nutzen, siehe mehrere GitHub-Konten.

Nur für ein Repository können Sie einen Schlüssel direkt festlegen:

git config core.sshCommand "ssh -i ~/.ssh/id_ed25519_work -o IdentitiesOnly=yes"

Ursache 4: Der falsche Benutzer in der URL

Der Benutzer ist immer git, nicht Ihr GitHub-Name:

git remote -v

Ein korrektes SSH-Remote beginnt mit git@github.com:. Hat Ihres einen anderen Benutzernamen, setzen Sie es neu:

git remote set-url origin git@github.com:owner/repo.git

Ursache 5: sudo

sudo git pull läuft als root, daher sucht SSH in /root/.ssh, und Ihr Agent ist meist außer Reichweite. Korrigieren Sie stattdessen den Besitzer des Ordners und führen Sie Git als Sie selbst aus:

sudo chown -R "$USER" /path/to/repo

Ursache 6: Der Schlüssel ist nicht geladen

Ein Schlüssel mit Passphrase, den eine GUI-App oder ein Skript ohne Möglichkeit zur Nachfrage nutzt, scheitert, als fehlte er. Laden Sie ihn:

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

Gibt das einen Fehler aus, siehe Could not open a connection to your authentication agent.

Auf dem Mac vergisst der Agent den Schlüssel nach einem Neustart. Speichern Sie die Passphrase einmal im Schlüsselbund:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Fügen Sie dann diese zwei Zeilen dem Block Host github.com in ~/.ssh/config hinzu, damit SSH den Schlüssel selbst lädt:

  AddKeysToAgent yes
  UseKeychain yes

Weitere Dinge zum Ausprobieren

  • Schlüsselrechte: Erwähnt die Ausgabe UNPROTECTED PRIVATE KEY FILE, siehe diese Lösung.
  • Viele Schlüssel im Agent: siehe Too many authentication failures.
  • In CI: Nutzen Sie einen Deploy Key oder ein Token Ihres CI-Systems. Persönliche Schlüssel gehören dort nicht hin.
  • Für einen schnellen Ausweg umgeht HTTPS mit einem Token SSH ganz: git remote set-url origin https://github.com/owner/repo.git.
  • Git auf einem entfernten Server: Leiten Sie Ihren Schlüssel über den Agent weiter, statt ihn dorthin zu kopieren, nachdem Sie die Risiken von SSH-Agent-Forwarding gelesen haben.

Fragen

Warum meldet Git Could not read from remote repository?

Das ist Gits allgemeine Zeile, nachdem SSH gescheitert ist. Die eigentliche Ursache steht in der Zeile darüber, hier Permission denied (publickey): GitHub hat keinen der von SSH angebotenen Schlüssel akzeptiert.

Wie sehe ich, welchen Schlüssel SSH an GitHub schickt?

Führen Sie ssh -vT git@github.com aus und lesen Sie die Zeilen Offering public key. ssh-add -l zeigt die im Agent geladenen Schlüssel.

Warum scheitert git pull nur mit sudo?

sudo läuft als root, SSH liest also /root/.ssh und erreicht Ihren Agent meist nicht. Führen Sie Git als Ihr eigener Benutzer aus und korrigieren Sie stattdessen den Besitzer des Ordners.

Quellen

Mehr zu Fehlermeldungen

Alle Anleitungen