Я уже некоторое время использую аутентификацию с открытым ключом на своих серверах, но у меня возникают проблемы с новым «клиентом», пытающимся подключиться к 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:Итак, ваша
~/.ssh/configзапись должна выглядеть так:источник
У нас была эта проблема, и это была ошибка вырезать и вставить. Единственный
%символ был добавлен в конец файла ключа (последняя строка была-----END RSA PRIVATE KEY-----%). Не было ни ошибок, ни отладочной информации, ни чего-либо еще, что бы указывало на то, что ключ был неправильной длины или неправильно отформатирован, но ssh попросил пароль.источник
В моем случае проблема заключалась в том, что мой SSH-клиент не поддерживает ключи ED25519. Решение состоит в том, чтобы создать ключ RSA и использовать его вместо этого.
Эта проблема возникает с OpenSSH <6,5 (запустить
ssh -V) и PuTTY <0,68 .Это можно увидеть в следующем выводе
ssh -vvv:Первый блок описывает то , что клиент поддерживает, а второе то , что сервер поддерживает . Как вы можете видеть, в верхней половине нет упоминания о кривой «25519», что указывает на то, что клиент не поддерживает это.
источник
В моей команде, когда это происходит, это не проблема ни с чем локально. Ключ ssh и / или доступ пользователя не были правильно настроены на сервере, к которому они подключаются (в нашем случае, на платформе хостинга). По какой-то причине это вызывает приглашение для несуществующего ключа ssh.
источник