SSH pomija mój klucz pubowy i pyta o hasło

52

Za każdym razem, gdy ssh na moim zdalnym serwerze, muszę podać hasło. Skopiowałem mój klucz publiczny (id_dsa.pub) na zdalny serwer, używając:

ssh-copy-id -i id_dsa.pub user@server

Sprawdziłem, czy został poprawnie dodany do uprawnionych kluczy. Wszystkie uprawnienia do pliku / katalogu są poprawne:

~user 755
~user/.ssh 700
~user/.ssh/authorized_keys 640
~user/.ssh/id_dsa.pub 644

Pole PasswordAuthentication w / etc / ssh / sshd_config jest ustawione na tak. Ustawiłem sshd w tryb debugowania i dodałem pełny przełącznik do polecenia ssh. Mam wrażenie, że serwer nie próbował użyć id_pub.dsa z powodu linii

Skipping ssh-dss key: ........... not in PubkeyAcceptedKeyTypes

Po stronie serwera nie ma zaszyfrowanego dysku. Jakieś pomysły na postęp? Oto informacje o debugowaniu demona ssh:

sudo /usr/sbin/sshd -d
====
debug1: sshd version OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from xxx port 63521 on yyy port 22
debug1: Client protocol version 2.0; client software version OpenSSH_7.1
debug1: match: OpenSSH_7.1 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: permanently_set_uid: 115/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server [email protected] <implicit> none [preauth]
debug1: kex: server->client [email protected] <implicit> none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user damian service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "damian"
debug1: PAM: setting PAM_RHOST to "freebox-server.local"
debug1: PAM: setting PAM_TTY to "ssh"
Connection closed by xxxx [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup

Oto pełne wyjście ssh:

$ ssh -v user@server
OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015
debug1: Connecting to server [xxxx] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to server:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client [email protected] <implicit> none
debug1: kex: client->server [email protected] <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:v4BNHM0Q33Uh6U4VHenA9iJ0wEyi8h0rFVetbcXBKqA
debug1: Host 'server' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:2
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Skipping ssh-dss key /home/user/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Next authentication method: password
user@server's password:
Damo
źródło
1
Zobacz także superuser.com/q/1016989/93541 dla tego samego problemu (i zasadniczo tego samego rozwiązania).
DW
Zauważ, że jeśli sshd_config w miejscu docelowym ma PubkeyAuthentication nie , zawsze będziesz proszony o podanie hasła. Ustaw na tak i zrestartuj sshd (na hoście docelowym), aby włączyć uwierzytelnianie za pomocą klucza publicznego.
C. Kelly,

Odpowiedzi:

84

Nowa wersja openssh (7.0+) wycofała klucze DSA i domyślnie nie używa kluczy DSA (nie na serwerze ani kliencie). Klucze nie są już używane, więc jeśli możesz, zalecam używanie kluczy RSA tam, gdzie to możliwe.

Jeśli naprawdę potrzebujesz używać kluczy DSA, musisz jawnie zezwolić na ich użycie w konfiguracji klienta

PubkeyAcceptedKeyTypes +ssh-dss

Powinno wystarczyć, aby umieścić tę linię ~/.ssh/config, ponieważ pełna wiadomość próbuje ci powiedzieć.

Jakuje
źródło
5
+1, ale lepsza rada to użyć innego, nieaktualnego klucza typu ...
jasonwryan,
@jasonwryan Dzięki za komentarz. Na pewno. Zaktualizuję odpowiedź.
Jakuje,
Dzięki Jakuje! To ma sens, nie zdawałem sobie sprawy, że dsa to oldhat. Wygenerowałem nową parę kluczy ssh-keygenrsa jest teraz domyślna. Spróbuję zalogować się jutro przy użyciu tego urządzenia.
Damo,
Jeśli ~/.ssh/confignie istniejesz, po prostu go stwórz. I pamiętaj, aby ustawić corect uprawnienia: chmod 600 ~/.ssh/config.
Florian Brucker,
@knb nie rób tego. Pozwoli to uniknąć korzystania z innych algorytmów w przyszłości, ponieważ usunięto wszystkie algorytmy krzywej eliptycznej.
Jakuje
2

W moim przypadku miałem ten problem, ponieważ inny użytkownik zmienił AuthorizedKeysFilelokalizację. Ponieważ authorized_keysw tej lokalizacji nie było innych użytkowników, login domyślnie wprowadziłby hasło, mimo że authorized_keysistniał z prawidłowymi uprawnieniami w domyślnym katalogu domowym.

AuthorizedKeysFile   /etc/ssh/%u/authorized_keys

Skomentował to zmodyfikowane wyjście liniowe i zrestartował usługę sshd, aby powrócić do ustawień domyślnych, co pozwoliło innym użytkownikom uwierzytelnić się przy użyciu ich kluczy.

GotGame
źródło
Właśnie rozwiązałem podobny problem w systemie RHEL7, w którym kontekst SELinux nie został poprawnie zainicjowany na homedir użytkownika, więc ssh nie był w stanie odczytać pliku kluczy autoryzowanych pomimo standardowych uprawnień. W końcu restorecon -Rv /homeudało mi się to naprawić dla innych użytkowników, którzy również zostali nieprawidłowo skonfigurowani w tym samym systemie.
dannysauer
1

Próbowałem odpowiedzi Jakuje. Brak szczęścia. Ale rozumiem problem stamtąd. Próbowałem dodać komentarz, ale potrzebuję reputacji, dlatego warto dodać odpowiedź.

Ale plik konfiguracyjny dla mnie / etc / ssh / ssh_config

  1. sudo nano /etc/ssh/ssh_config
  2. PubkeyAcceptedKeyTypes +ssh-dss Dodano tę linię na dole.
  3. Zapisz i spróbuj ponownie.

Pracował!

SWAPNIL DEWALKAR
źródło
1

Podsumowując to, co zrobiłem, aby SSH do Raspberry Pi .

W maszynie serwerowej (raspberry Pi):

$ ip addr show 

lub po prostu ip awyświetli adres IP maszyny Pi - host_ip

$ mkdir .ssh

Na komputerze klienta (ubuntu):

$ ssh-keygen -t rsa  

Kredyt dla @Jakuje powyżej. Początkowo używałem ssh-keygen -t dsa do generowania kluczy, a ssh ciągle prosił mnie o hasło. ssh -v adres IP nie dostarcza mi wielu użytecznych informacji, dopóki nie zobaczyłem odpowiedzi @ Jakuje

$ cat .ssh/id_rsa.pub | ssh user_id@host_ip 'cat >> ~/.ssh/authorized_keys'  

zamień user_id i host_ip, gdy pojawi się monit, podaj hasło do komputera Pi

$ ssh user@ip_address

pomyślnie zalogowałem się do PI, nie ma już hasła

VictorL
źródło
0

dsa nie działało dla mnie. rsa zrobił.

ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
cat /Users/user_name/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

I mogę ssh bez hasła.

Rodya
źródło