28

I have been using public key authentication on my servers for a while now, but I am experiencing issues on a new 'client' trying to connect to github. I have read many threads to verify that my permissions are set up correctly and have generated a new key for github. The problem I am facing is that ssh is asking for my passphrase even though I did not set a passphrase. I have even re-made the key to be 100% sure that I did not enter a passphrase.

ssh -vvv gives the following related output:

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

I have searched to figure out why it is telling me PEM_read_PrivateKey failed, but I cannot find a solution.

I do not use an agent or anything. I configure my ~/.ssh/config file similar to the following:

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

Thanks in advance.

| improve this question | |
  • @jasonwryan, please move your comment to an answer. I am quite sure you are right. – andcoz Mar 22 '12 at 21:06
  • It is a bit trivial, and I'm a goof for not noticing this earlier, but hopefully your answer will provide help to others in the future. – earthmeLon Mar 23 '12 at 3:46
28

When you use the IdentityFile option in your ~/.ssh/config you point to the private, not the public, key.

From man ssh_config:

IdentityFile
Specifies a file from which the user's DSA, ECDSA or DSA authentication identity is read. The default is ~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for protocol version 2.

So, your ~/.ssh/config entry should look like:

Host github.com
Hostname github.com
User git
PubkeyAuthentication yes
IdentityFile /home/me/.ssh/github
| improve this answer | |
  • 3
    I'm such a doofus. My only saving grace is that this may help other 'doofuses' in the future. – earthmeLon Mar 23 '12 at 3:45
  • 1
    It's an easy enough mistake to make... – jasonwryan Mar 23 '12 at 4:05
  • 1
    Just helped me, so I appreciate the answer! – Topher Fangio Jan 10 '14 at 22:09
  • 1
    Color me a doofus. – jeremiah Jun 15 '15 at 14:15
  • This did iit for me. – unity100 Mar 20 '19 at 22:06
3

We had this problem, and it was a cut-and-paste error. A single % symbol had been added to the end of the key file (so the last line was -----END RSA PRIVATE KEY-----% ). There was no error or debug info or anything else to suggest that the key was the wrong length or badly formatted, but ssh asked for a passphrase.

| improve this answer | |
  • 1
    Similiar thing happend to me. I copied the key from another terminal and copied too much without noticing it. – Guillermo Jul 29 '19 at 13:48
3

In my case, the problem was the my SSH client does not support ED25519 keys. The solution is to create an RSA key and use it instead.

This problem occurs with OpenSSH < 6.5 (run ssh -V) and PuTTY < 0.68.

This can be seen in the following output of 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

The first block describes what the client supports, and the second what the server supports. As you can see, there's no mention of 'curve25519' in the top half, indicating that the client does not support that.

| improve this answer | |
0

On my team, when this happens it isn't an issue with anything locally. The user's ssh key and/or access hasn't been configured correctly on the server they're connecting to (in our case a hosting platform). For some reason this triggers a prompt for a non-existent ssh key.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.