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


27

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ę.


@jasonwryan, przenieś swój komentarz do odpowiedzi. Jestem pewien, że masz rację.
andcoz

Jest to trochę trywialne i jestem głupcem, że nie zauważyłem tego wcześniej, ale mam nadzieję, że twoja odpowiedź pomoże innym w przyszłości.
earthmeLon

Odpowiedzi:


26

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

2
Jestem takim głupkiem. Moją jedyną zbawczą łaską jest to, że może to pomóc innym „doofuse” w przyszłości.
earthmeLon

1
Łatwo jest popełnić błąd ...
jasonwryan

1
Właśnie mi pomógł, więc doceniam odpowiedź!
Topher Fangio,

1
Pokoloruj mnie doofus.
jeremiah

To mi się przydało.
unity100

2

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.


1
Podobna rzecz mi się przydarzyła. Skopiowałem klucz z innego terminala i skopiowałem za dużo, nie zauważając go.
Guillermo

1

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

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.


0

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.