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.

1. ssh-keygen -t rsa, zaakceptował wszystkie ścieżki, więc /home/USER/.ssh/id_rsabez fraz
2. 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

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

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ź?

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