SSH pyta o hasło na kluczu publicznym bez ustawionego hasła

Od pewnego czasu używam uwierzytelniania za pomocą klucza publicznego na moich serwerach, ale mam problemy z nowym „klientem” próbującym połączyć się z github . Przeczytałem wiele wątków, aby sprawdzić, czy moje uprawnienia są skonfigurowane poprawnie i wygenerowałem nowy klucz dla github. Problem, z którym się zmagam, polega na tym, że ssh prosi o moje hasło, mimo że nie ustawiłem hasła. Nawet zmieniłem klucz, aby mieć 100% pewność, że nie wprowadziłem hasła.

ssh -vvv daje następujące powiązane dane wyjściowe:

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

Szukałem, aby dowiedzieć się, dlaczego to mówi PEM_read_PrivateKey nie powiodło się, ale nie mogę znaleźć rozwiązania.

Nie używam agenta ani nic takiego. Konfiguruję mój plik ~ / .ssh / config podobny do następującego:

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

Z góry dziękuję.

Kiedy skorzystasz z tej IdentityFileopcji ~/.ssh/config, wskazujesz klucz prywatny, a nie publiczny .

Od man ssh_config:

IdentityFile
Określa plik, z którego odczytywana jest tożsamość uwierzytelnienia DSA, ECDSA lub DSA użytkownika. Domyślna wartość to ~ / .ssh / identity dla protokołu w wersji 1 i ~ / .ssh / id_dsa, ~ / .ssh / id_ecdsa i ~ / .ssh / id_rsa dla protokołu w wersji 2.

Twój ~/.ssh/configwpis powinien wyglądać następująco:

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

Mieliśmy ten problem i był to błąd „wklej i wklej”. Pojedynczy %symbol został dodany na końcu pliku kluczy (tak więc ostatnia linia była -----END RSA PRIVATE KEY-----%). Nie było żadnych informacji o błędzie lub debugowaniu ani nic innego, co sugerowałoby, że klucz był nieprawidłowej długości lub źle sformatowany, ale ssh poprosił o hasło.

W moim przypadku problem polegał na tym, że mój klient SSH nie obsługuje kluczy ED25519. Rozwiązaniem jest utworzenie klucza RSA i użycie go zamiast tego.

Ten problem występuje w przypadku OpenSSH <6,5 (uruchomienie ssh -V) i PuTTY <0,68 .

Można to zobaczyć w następującym wyniku 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: [email protected],[email protected],[email protected],[email protected],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,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,[email protected]
debug2: kex_parse_kexinit: hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96
debug2: kex_parse_kexinit: hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],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: [email protected],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,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]

Pierwszy blok opisuje wsporniki klienta, a drugi jaka obsługuje serwer . Jak widać, w górnej połowie nie ma wzmianki o „curve25519”, co wskazuje, że klient tego nie obsługuje.

W moim zespole, gdy tak się dzieje, nie ma to żadnego problemu lokalnie. Klucz ssh i / lub dostęp użytkownika nie został poprawnie skonfigurowany na serwerze, z którym się łączy (w naszym przypadku na platformie hostingowej). Z jakiegoś powodu powoduje to wyświetlenie monitu o nieistniejący klucz ssh.