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. За замовчуванням для протоколу версії 1 є ~ / .ssh / особистість, і ~ / .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

Перший блок описує те , що клієнт підтримує, а друге те , що сервер підтримує . Як бачимо, у верхній половині згадки про "curve25519" немає, що свідчить про те, що клієнт цього не підтримує.

У моїй команді, коли це трапляється, проблема не стосується нічого локального. Ключ ssh та / або доступ користувача не налаштовано правильно на сервері, до якого він підключається (у нашому випадку хостингова платформа). Чомусь це запускає запит на неіснуючий ключ ssh.