Ich verwende seit einiger Zeit die Authentifizierung mit öffentlichem Schlüssel auf meinen Servern, aber ich habe Probleme mit einem neuen „Client“, der versucht, eine Verbindung herzustellen zugithub. Ich habe viele Threads gelesen, um zu überprüfen, ob meine Berechtigungen richtig eingerichtet sind, und habe einen neuen Schlüssel für GitHub generiert. Das Problem, mit dem ich konfrontiert bin, ist, dass SSH nach meiner Passphrase fragt, obwohl ich keine Passphrase festgelegt habe. Ich habe den Schlüssel sogar neu erstellt, um 100 % sicher zu sein, dass ich keine Passphrase eingegeben habe.
ssh -vvvgibt die folgende zugehörige Ausgabe aus:
debug1: Offering public key: /home/me/.ssh/github.pub
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1495
debug1: Remote: Forced command: gerve mygithubusername c3:71:db:34:98:30:6d:c2:ca:d9:51:a8:c6:1b:fc:f7
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp c3:71:db:34:98:30:6d:c2:ca:d9:51:a8:c6:1b:fc:f7
debug3: sign_and_send_pubkey
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/home/me/.ssh/github.pub':
Ich habe versucht, herauszufinden, warum es mir sagt:PEM_PrivateKey lesenist fehlgeschlagen, aber ich kann keine Lösung finden.
Ich verwende keinen Agenten oder ähnliches. Ich konfiguriere meine Datei ~/.ssh/config ungefähr wie folgt:
Host github
Host github.com
Hostname github.com
User git
PubkeyAuthentication yes
IdentityFile /home/me/.ssh/github.pub
Dank im Voraus.
Antwort1
Wenn Sie die IdentityFileOption in Ihrem verwenden ~/.ssh/config, verweisen Sie auf die private,nicht die Öffentlichkeit, Schlüssel.
Aus man ssh_config:
Identitätsdatei
Gibt eine Datei an, aus der die DSA-, ECDSA- oder DSA-Authentifizierungsidentität des Benutzers gelesen wird. Der Standardwert ist ~/.ssh/identity für Protokollversion 1 und ~/.ssh/id_dsa, ~/.ssh/id_ecdsa und ~/.ssh/id_rsa für Protokollversion 2.
Ihr Eintrag sollte also ~/.ssh/configfolgendermaßen aussehen:
Host github.com
Hostname github.com
User git
PubkeyAuthentication yes
IdentityFile /home/me/.ssh/githubAntwort2
Wir hatten dieses Problem und es war ein Ausschneiden-und-Einfügen-Fehler. %Am Ende der Schlüsseldatei war ein einzelnes Symbol hinzugefügt worden (die letzte Zeile war also -----END RSA PRIVATE KEY-----%). Es gab keine Fehler- oder Debuginformationen oder sonst etwas, das darauf hindeutete, dass der Schlüssel die falsche Länge hatte oder falsch formatiert war, aber SSH verlangte eine Passphrase.
Antwort3
In meinem Fall bestand das Problem darin, dass mein SSH-Client keine ED25519-Schlüssel unterstützt. Die Lösung besteht darin, einen RSA-Schlüssel zu erstellen und diesen stattdessen zu verwenden.
Dieses Problem tritt auf beiOpenSSH < 6.5(laufen ssh -V) undKitt < 0,68.
Dies ist in der folgenden Ausgabe zu sehen ssh -vvv:
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,[email protected]
debug2: kex_parse_kexinit: hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96
debug2: kex_parse_kexinit: hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
DerDer erste Block beschreibt, was der Client unterstützt, und der zweite, was der Server unterstützt.. Wie Sie sehen, wird „curve25519“ in der oberen Hälfte nicht erwähnt, was darauf hinweist, dass der Client dies nicht unterstützt.
Antwort4
Wenn dies in meinem Team passiert, liegt das nicht an einem lokalen Problem. Der SSH-Schlüssel und/oder der Zugriff des Benutzers wurden auf dem Server, mit dem er sich verbindet (in unserem Fall eine Hosting-Plattform), nicht richtig konfiguriert. Aus irgendeinem Grund wird dadurch eine Eingabeaufforderung für einen nicht vorhandenen SSH-Schlüssel ausgelöst.