SSH fragt nach einer Passphrase für einen öffentlichen Schlüssel, für den keine Passphrase festgelegt ist

Ich verwende bereits seit einiger Zeit die Authentifizierung mit öffentlichen Schlüsseln auf meinen Servern, es treten jedoch Probleme auf einem neuen "Client" auf, der versucht, eine Verbindung zu Github herzustellen . Ich habe viele Threads gelesen, um zu überprüfen, ob meine Berechtigungen korrekt eingerichtet sind, und habe einen neuen Schlüssel für Github generiert. Das Problem 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 -vvv gibt die folgende verwandte 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 gesucht, um herauszufinden, warum PEM_read_PrivateKey fehlgeschlagen ist, aber ich kann keine Lösung finden.

Ich benutze keinen Agenten oder irgendetwas. Ich konfiguriere meine ~ / .ssh / config-Datei wie folgt:

Host github
Host github.com
Hostname github.com
User git
PubkeyAuthentication yes
IdentityFile /home/me/.ssh/github.pub

Danke im Voraus.

Wenn Sie die IdentityFileOption in Ihrem verwenden, zeigen ~/.ssh/configSie auf den privaten, nicht auf den öffentlichen Schlüssel.

Von man ssh_config:

IdentityFile
Gibt eine Datei an, aus der die DSA-, ECDSA- oder DSA-Authentifizierungsidentität des Benutzers gelesen wird. Die Standardeinstellung ist ~ / .ssh / identity für Protokollversion 1 und ~ / .ssh / id_dsa, ~ / .ssh / id_ecdsa und ~ / .ssh / id_rsa für Protokollversion 2.

Ihr ~/.ssh/configEintrag sollte also so aussehen:

Host github.com
Hostname github.com
User git
PubkeyAuthentication yes
IdentityFile /home/me/.ssh/github

Wir hatten dieses Problem und es war ein Fehler beim Ausschneiden und Einfügen. Am %Ende der Schlüsseldatei wurde ein einzelnes Symbol hinzugefügt (die letzte Zeile war also -----END RSA PRIVATE KEY-----%). Es gab keine Fehler- oder Debug-Informationen oder irgendetwas anderes, das darauf hindeutet, dass der Schlüssel die falsche Länge hat oder falsch formatiert ist, aber ssh hat nach einer Passphrase gefragt.

In meinem Fall war das Problem, dass mein SSH-Client keine ED25519-Schlüssel unterstützt. Die Lösung besteht darin, einen RSA-Schlüssel zu erstellen und stattdessen zu verwenden.

Dieses Problem tritt bei OpenSSH <6.5 (Ausführen ssh -V) und PuTTY <0.68 auf .

Dies ist in der folgenden Ausgabe von 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: ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,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,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96
debug2: kex_parse_kexinit: hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,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: curve25519-sha256@libssh.org,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,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com

Der erste Block beschreibt, was der Client unterstützt, und der zweite, was der Server unterstützt . Wie Sie sehen, gibt es in der oberen Hälfte keine Erwähnung von 'curve25519', was darauf hinweist, dass der Client dies nicht unterstützt.

In meinem Team ist dies kein Problem vor Ort. Der SSH-Schlüssel und / oder der Zugriff des Benutzers wurde auf dem Server, mit dem die Verbindung hergestellt wird, nicht richtig konfiguriert (in unserem Fall eine Hosting-Plattform). Aus irgendeinem Grund wird eine Aufforderung zur Eingabe eines nicht vorhandenen SSH-Schlüssels ausgelöst.