SSH demandant une phrase secrète sur la clé publique sans aucun mot de passe défini

J'utilise l'authentification par clé publique sur mes serveurs depuis un certain temps maintenant, mais je rencontre des problèmes avec un nouveau «client» essayant de se connecter à github . J'ai lu de nombreux threads pour vérifier que mes autorisations sont correctement configurées et j'ai généré une nouvelle clé pour github. Le problème auquel je suis confronté est que ssh demande ma phrase secrète même si je n'ai pas défini de phrase secrète. J'ai même refait la clé pour être sûr à 100% que je n'ai pas entré de phrase secrète.

ssh -vvv donne la sortie associée suivante:

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': 

J'ai cherché à comprendre pourquoi il me dit que PEM_read_PrivateKey a échoué, mais je ne trouve pas de solution.

Je n'utilise pas d'agent ou quoi que ce soit. Je configure mon fichier ~ / .ssh / config de la manière suivante:

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

Merci d'avance.

Lorsque vous utilisez l' IdentityFileoption dans votre, ~/.ssh/configvous pointez sur la clé privée et non sur la clé publique .

De man ssh_config:

IdentityFile
Spécifie un fichier à partir duquel l'identité d'authentification DSA, ECDSA ou DSA de l'utilisateur est lue. La valeur par défaut est ~ / .ssh / identity pour la version 1 du protocole, et ~ / .ssh / id_dsa, ~ / .ssh / id_ecdsa et ~ / .ssh / id_rsa pour la version 2 du protocole.

Ainsi, votre ~/.ssh/configentrée devrait ressembler à:

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

Nous avons eu ce problème, et c'était une erreur de copier-coller. Un seul %symbole avait été ajouté à la fin du fichier clé (donc la dernière ligne l'était -----END RSA PRIVATE KEY-----%). Il n'y a eu aucune erreur ou information de débogage ou quoi que ce soit d'autre pour suggérer que la clé était de mauvaise longueur ou mal formatée, mais ssh a demandé une phrase de passe.

Dans mon cas, le problème était que mon client SSH ne prend pas en charge les clés ED25519. La solution consiste à créer une clé RSA et à l'utiliser à la place.

Ce problème se produit avec OpenSSH <6,5 (exécution ssh -V) et PuTTY <0,68 .

Cela peut être vu dans la sortie suivante de 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

Le premier bloc décrit ce que le client prend en charge et le second ce que le serveur prend en charge . Comme vous pouvez le voir, il n'y a aucune mention de «curve25519» dans la moitié supérieure, indiquant que le client ne prend pas en charge cela.

Dans mon équipe, lorsque cela se produit, ce n'est pas un problème avec quoi que ce soit localement. La clé ssh et / ou l'accès de l'utilisateur n'a pas été correctement configuré sur le serveur auquel il se connecte (dans notre cas une plateforme d'hébergement). Pour une raison quelconque, cela déclenche une invite pour une clé ssh inexistante.