SSH nadal pyta o hasło po skonfigurowaniu uwierzytelnienia na podstawie klucza

Z powodzeniem utworzyłem uwierzytelnianie oparte na kluczach dla użytkownika root z mojego komputera A na mój komputer B.

Teraz stworzyłem nowego użytkownika na maszynie B, tak samo jak na maszynie A, nazwijmy go USER. Utworzyłem dla niego katalog domowy na maszynie B /home/USERi chcę dla niego utworzyć autoryzację opartą na kluczach z maszyny A na maszynę B.

Więc uruchomiłem na maszynie A.

ssh-keygen -t rsa, zaakceptował wszystkie ścieżki, więc /home/USER/.ssh/id_rsabez fraz
ssh-copy-id -i /home/USER/.ssh/id_rsa.pub USER@BmachinesIP, podałem hasło i dostałem masaż

Teraz spróbuj zalogować się do urządzenia bla bla bla

Wszystko wydaje się w porządku.

Ale kiedy próbowałem się połączyć, ssh USER@BmachinesIPzostałem poproszony o hasło. Próbowałem zobaczyć dziennik i uruchomiłem, ssh -vvv USER@BmachinesIPa oto część wyniku:

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/USER/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/USER/.ssh/id_dsa
debug3: no such identity: /home/USER/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
USER@BmachinesIP's password:

Czy ktoś może mi powiedzieć, co zrobiłem źle lub co powinienem zmienić? Być może problem dotyczy uprawnień, oto one:

na maszynie A:

drwx------  2 USER USER    SIZE DATE TIME .ssh
-rw-------  1 USER USER 1675 2011-10-31 14:36 id_rsa
-rw-r--r--  1 USER USER 413 2011-10-31 14:36 id_rsa.pub

i na maszynie B:

drwx------  2 USER defaultGroup    SIZE DATE TIME .ssh
-rw-------    1 USER defaultGroup    SIZE DATE TIME authorized_keys

linux authentication ssh

— tratto
źródło

Odpowiedzi:

Znalazłem rozwiązanie. Wystąpił problem z uprawnieniami.

/home/USER na zdalnym komputerze przyznano wszystkie uprawnienia, ale dla uwierzytelniania opartego na kluczach należy ustawić 755

— tratto
źródło

Łał. Zadziwiające, że nie ma danych wyjściowych debugowania dotyczących uprawnień, mimo że są one kluczowe dla prawidłowej konfiguracji klucza publicznego.

— jchook

Wow, masz rację. Teraz działa .... chociaż naprawdę chcę zachować pozwolenie, które pierwotnie miało (775). Wszelkie wskazówki, jak to zmienić?

— Pablo Olmos de Aguilera C.

Wydaje się, że nie ma mowy, tylko obejście byłoby ustawione StrictModes no w sshd_config. : /.

— Pablo Olmos de Aguilera C.

Zasadniczo potrzebujesz tych uprawnień: chmod o-w ~/; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keyswtedy to działa. Skopiowano z odpowiedzi Maxime R. stąd: askubuntu.com/questions/54670/passwordless-ssh-not-working

— erik

Dokonałem wszystkich tych zmian uprawnień i nadal pyta mnie o hasło, gdy ssh. Sprawdziłem również, czy klucz prywatny jest taki sam na obu komputerach (Ubuntu). Całkiem zdziwiony.

— Amalgovinus

Ten sam problem dla mnie świeża instalacja CentOS7.

1. sprawdź uprawnienia do katalogu domowego i uprawnienia ~ / .ssh i ~ / .ssh / author_keys (zgodnie z @erik)

chmod o-w ~/; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys

2. sprawdź / etc / ssh / sshd_config ustawienia i & service sshd restart (po każdej edycji) Przydatne: spróbuj „LogLevel VERBOSE” w sshd_config.

Po sprawdzeniu, czy wszystko jest w porządku, nadal pojawia się monit o hasło.

Uruchom klienta ssh z dziennikami -vvv:

debug3: send_pubkey_test 
debug2: we sent a publickey packet, wait for reply

Dzienniki serwera (/ var / log / secure):

Failed publickey for * from * port * ssh2: RSA *

Serwer ssh nie wysyła więcej informacji o błędzie do klienta, ponieważ stanowiłoby to zagrożenie bezpieczeństwa.

Gdybym uruchomił sshd na innym porcie 'sshd -p 5555 -d'. Klucz zadziałał. Logowanie bez hasła ok. WTF?

Następnie wyłączyłem selinux (ustaw SELINUX = wyłączone w / etc / selinux / config) i zrestartowałem. Następnie logowanie bez hasła działało poprawnie.

moje bieżące działające ustawienia sshd_config:

[root@hp-bl-05 ~]# grep -vE "^#|^$" /etc/ssh/sshd_config  
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
SyslogFacility AUTHPRIV
LogLevel VERBOSE
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys
HostbasedAuthentication yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication no
GSSAPICleanupCredentials no
UsePAM yes
X11Forwarding yes
UseDNS no
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem   sftp    /usr/libexec/openssh/sftp-server

Byłoby miło wiedzieć, czy moglibyśmy zmienić coś małego w selinux, aby hasło do logowania ssh działało poprawnie. Czy ktoś może poprawić odpowiedź?

— gaoithe
źródło

Rozwiązaniem nie jest wyłączenie SELinux, ale naprawa uprawnień SELinux do katalogu użytkownika. Kontekst katalogu użytkownika musi być ustawiony na user_home_t.

Sprawdzić,

$ sudo ls -Z /home/

Jeśli kontekst katalogu użytkownika jest inny niż user_home_t, SELinux nie zezwoli SSH za pomocą klucza publicznego do tego katalogu użytkownika dla tego użytkownika.

Naprawić,

$ sudo semanage fcontext -a -t user_home_t /home/azureuser
$ sudo restorecon -vvRF /home/azureuser

Logowanie oparte na kluczach powinno teraz działać.

— sentifool
źródło