SSH-Schlüssel - Bittet immer noch nach Passwort und Passphrase

Question

Ich habe Github immer wieder nach meinem Benutzernamen und Passwort gefragt, wenn ich ein Repository klone. Ich möchte diesen Schritt umgehen, weil er mich bei meiner Arbeit stört.

Ich habe versucht, einen SSH-Schlüssel einzurichten (was mir erfolgreich gelang) mithilfe dieses Leitfadens. https://help.github.com/articles/generating-ssh-keys und es hat funktioniert.

Mein Problem ist, dass ich immer noch nach meinem Github-Passwort und Passphrase gefragt werde, wenn ich ein Repository (mit SSH) klonen will. Mein Verständnis war, dass ich nach Einrichtung dieses SSH-Schlüssels das nicht mehr tun müsste.

Ich bin mir etwas unsicher, was ich fragen soll, also werde ich einfach mein Ziel nennen.

Ich möchte in der Lage sein, Repositories zu klonen, ohne jedes Mal meine Github-Informationen eingeben zu müssen.

Was fehlt mir bei meinem SSH-Schlüssel? Wenn jemand Anleitung oder Ressourcen anbieten kann, wäre ich dankbar, denn ich habe mich immer etwas verloren gefühlt, wenn es um die SSH-Authentifizierung in GitHub ging.

Nach meinem Wissen ist dies ein Befehl, der prüft, ob alles ordnungsgemäß funktioniert, hier ist die Ausgabe von meiner Konsole:

~ $ ssh -T git@github.com
Saving password to keychain failed
Enter passphrase for key '/Users/MYNAME/.ssh/id_rsa':
Hi MYNAME! You've successfully authenticated, but GitHub does not provide shell access.

Sollte mein Passwort zuerst fehlschlagen, wenn ich es eingebe? Dann, wenn ich mein Passphrase eingebe, erfolgt die Authentifizierung.

Answer 1

Diese Antwort richtet sich hauptsächlich an Windows-Benutzer und ist auch genauso relevant, wenn Sie Probleme beim Klonen mit TFS, GitHub oder GitLab auf einem anderen Betriebssystem haben.

Der Standard-Authentifizierungsmodus bei der Verwendung von SSH ist der private Schlüssel. Wenn das aus irgendeinem Grund fehlschlägt, fällt der ssh-agent auf die Authentifizierung basierend auf Benutzername und Passwort zurück.

Es gibt mehrere Gründe, warum die Standard-Authentifizierung mit Schlüssel fehlschlagen könnte. Die häufigsten Fälle sind:

a) Der ssh-agent kann die Standard-Private-Key-Datei nicht finden, die id_rsa ist, und es wurde kein anderer Schlüsselpfad explizit angegeben.

b) Der im Server gespeicherte öffentliche Schlüssel ist falsch.

c) Der Pfad, den Sie zu klonen versuchen, ist falsch.

Um das Problem zu diagnostizieren, führen Sie zunächst den git clone-Befehl mit ausführlicher Protokollierung aus, mit dem Befehl:

GIT_TRACE=1 GIT_SSH_COMMAND="ssh -vvv" git clone ssh://PfadZuIhremRepo

Gehen Sie jeden Schritt im Protokoll durch, um eine Vorstellung davon zu bekommen, was das Problem sein könnte.

---

Problembehandlung im Fall von (a)

• Vergewissern Sie sich, dass Sie den Standard-Schlüsselnamen id_rsa im .ssh-Verzeichnis haben. Möglicherweise haben Sie einen anderen Schlüsselnamen angegeben, als Sie den Schlüssel mit dem Befehl ssh-keygen generiert haben, oder es gibt überhaupt keinen Schlüssel).

• Wenn Sie einen anderen Schlüssel für die Authentifizierung angeben möchten, verwenden Sie den folgenden Befehl:

   ssh-agent bash -c 'ssh-add ~/.ssh/anotherKey; git clone ssh://PfadZuIhremRepo'

---

Problembehandlung im Fall von (b)

• Vergewissern Sie sich, dass keine zusätzlichen Leerzeichen vorhanden sind, wenn Sie den öffentlichen Schlüssel im Server speichern.

---

Problembehandlung im Fall von (c)

• Vergewissern Sie sich, dass Sie nicht versuchen, mit der https-Version des Repositorypfads zu klonen.

Answer 2

Ich habe kürzlich auf macOS Mojave aktualisiert und einige Tools über Homebrew installiert, die offenbar die Version von ssh-add von Apple durch eine andere ersetzt haben. Meine Standardversion von ssh-add hatte nicht die Option -K. Dies führte zu folgendem Fehler:

# ssh-add: illegal option -- K

Sie können überprüfen, welche Version von ssh-add Sie haben, indem Sie which ssh-add ausführen.

(Meine Version wurde unter /usr/local/bin/ssh-add gespeichert)

Um dies zu beheben, musste ich den Schlüssel auf die Version von Apple verweisen:

/usr/bin/ssh-add -K ~/.ssh/id_rsa

Git/GitHub haben danach einwandfrei funktioniert. Weitere Informationen finden Sie unter: Fehler: ssh-add: illegal option -- K

Answer 3

Wenn Sie zuvor die Passwortauthentifizierung für Ihr GIT verwendet haben, jetzt aber die SSH-Authentifizierung verwenden, müssen Sie die Remote-URLs von HTTPS auf SSH umstellen:

git remote set-url origin git@github.com:USERNAME/REPOSITORY.git

Answer 4

Für Mac OSX Sierra habe ich festgestellt, dass die im Github-Problem für Open Radar vorgeschlagenen Fixes mein Problem behoben haben. Es scheint, dass Sierra das Standardverhalten geändert hat (ich hatte dieses Problem nach dem Upgrade).

Diesen hier fand ich besonders nützlich: https://github.com/lionheart/openradar-mirror/issues/15361#issuecomment-249059061

ssh-add -A 

Dadurch wurde meine Identität dem Agenten hinzugefügt, nachdem ich ausgeführt habe

ssh-add -K {/path/to/key}

Zusammenfassend, in OSX.12:

ssh-add -K {/path/to/key}
ssh-add -A 

sollte zu folgendem Ergebnis führen:

Identität hinzugefügt: {/path/to/file} ({/path/to/file})

EDIT: Ich habe festgestellt, dass dies beim nächsten vollständigen Neustart (wenn also der Agent gestoppt und neu gestartet wurde) nicht mehr funktioniert hat. Die umfassendere Lösung ist das, was @ChrisJF oben erwähnt hat: Erstellen einer ~/.ssh/config-Datei. Hier ist der Inhalt meiner:

$ cat ~/.ssh/config
Host *
  UseKeychain yes
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_rsa

Sie können beliebig viele IdentityFile-Einträge hinzufügen, aber dies ist die Standardkonfiguration. Dies ist aktuell auch die "trending" Antwort auf dem oben genannten openradar-Link.

Answer 5

Zusätzlich zu den obigen Antworten.

Musste auf Windows noch einen weiteren Schritt ausführen, damit git ssh-agent verwenden kann.

Musste den folgenden Befehl in Powershell ausführen, um die Umgebungsvariable zu aktualisieren:

PS> [Environment]::SetEnvironmentVariable("GIT_SSH", "$((Get-Command ssh).Source)", [System.EnvironmentVariableTarget]::User)

Starten Sie VSCode, Powershell oder das entsprechende Terminal neu, um die Umgebungsvariable zu aktivieren.

Vollständige Anweisungen finden Sie hier.