SSH запрашивает фразу-пароль для открытого ключа без пароля

Я уже некоторое время использую аутентификацию с открытым ключом на своих серверах, но у меня возникают проблемы с новым «клиентом», пытающимся подключиться к github . Я прочитал много веток, чтобы убедиться, что мои разрешения настроены правильно, и сгенерировал новый ключ для github. Проблема, с которой я сталкиваюсь, заключается в том, что ssh запрашивает мою фразу-пароль, хотя я не установил фразу-пароль. Я даже переделал ключ, чтобы быть на 100% уверенным, что я не ввел ключевую фразу.

ssh -vvv дает следующий связанный вывод:

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

Я искал, чтобы выяснить, почему он говорит мне, что PEM_read_PrivateKey не удалось, но я не могу найти решение.

Я не использую агента или что-либо еще. Я настраиваю свой файл ~ / .ssh / config следующим образом:

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

Заранее спасибо.

Когда вы используете IdentityFileопцию в своем, ~/.ssh/configвы указываете на закрытый, а не публичный ключ.

От man ssh_config:

IdentityFile
Указывает файл, из которого читается идентификация аутентификации DSA, ECDSA или DSA пользователя. По умолчанию используется ~ / .ssh / identity для протокола версии 1 и ~ / .ssh / id_dsa, ~ / .ssh / id_ecdsa и ~ / .ssh / id_rsa для протокола версии 2.

Итак, ваша ~/.ssh/configзапись должна выглядеть так:

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

У нас была эта проблема, и это была ошибка вырезать и вставить. Единственный %символ был добавлен в конец файла ключа (последняя строка была -----END RSA PRIVATE KEY-----%). Не было ни ошибок, ни отладочной информации, ни чего-либо еще, что бы указывало на то, что ключ был неправильной длины или неправильно отформатирован, но ssh попросил пароль.

В моем случае проблема заключалась в том, что мой SSH-клиент не поддерживает ключи ED25519. Решение состоит в том, чтобы создать ключ RSA и использовать его вместо этого.

Эта проблема возникает с OpenSSH <6,5 (запустить ssh -V) и PuTTY <0,68 .

Это можно увидеть в следующем выводе 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

Первый блок описывает то , что клиент поддерживает, а второе то , что сервер поддерживает . Как вы можете видеть, в верхней половине нет упоминания о кривой «25519», что указывает на то, что клиент не поддерживает это.

В моей команде, когда это происходит, это не проблема ни с чем локально. Ключ ssh и / или доступ пользователя не были правильно настроены на сервере, к которому они подключаются (в нашем случае, на платформе хостинга). По какой-то причине это вызывает приглашение для несуществующего ключа ssh.