ssh-copy-id nie działa

Usiłuję skonfigurować logowanie SSH bez hasła na CentOS 5.4:

1. Wygenerowałem klucz publiczny RSA na kliencie.
2. ssh-copy-id od klienta do serwera.
3. Zweryfikowane ~ / .ssh / Author_keys zawiera klucz klienta.

Klient nadal monitował o hasło. Co mnie ominęło?

Dzięki.

EDYCJA: sprawdzono ssh_config i uprawnienia zgodnie z zaleceniami. To są informacje debugowania od klienta:

debug2: key: /home/saguna/.ssh/identity ((nil))
debug2: key: /home/saguna/.ssh/id_rsa (0x2b31921be9a0)
debug2: key: /home/saguna/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 192.168.1.75.
debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/saguna/.ssh/identity
debug3: no such identity: /home/saguna/.ssh/identity
debug1: Offering public key: /home/saguna/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/saguna/.ssh/id_dsa
debug3: no such identity: /home/saguna/.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
saguna@192.168.1.75's password: 

9/10 razy dzieje się tak, ponieważ ~ / .ssh / Author_Key nie działa we właściwym trybie.

chmod 600 ~/.ssh/authorized_keys

Sprawdź w / etc / ssh / sshd_config, aby umożliwić uwierzytelnianie za pomocą klucza. Powinieneś mieć coś takiego i upewnij się, że wiersze nie są komentowane:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

PS: nie zapomnij zrestartować sshd po zmodyfikowaniu pliku (/etc/init.d/sshd restart)

Odkryłem, że w moim systemie problemem był katalog użytkownika (/ home / nazwa użytkownika) wyposażony w niewłaściwe ustawienia uprawnień. Tak było drwxr-x-w-i trzeba było drwxr-xr-x(tylko z uprawnieniami do zapisu dla właściciela). Rozwiązaniem było użycie chmod:

sudo chmod 0755 /home/username

Nie jestem tutaj ekspertem, ale też natknąłem się na taki problem, oto moje dwa centy oprócz wszystkich innych sugestii.

Czasami ssh-copy-idkopiuje niewłaściwy klucz na zdalny serwer (może się zdarzyć, jeśli masz kilka kluczy i / lub używasz niestandardowych nazw plików kluczy) lub agent uwierzytelniania jest źle skonfigurowany.

Oto cytat ze stron podręcznika :

Jeśli podano opcję -i, wówczas używany jest plik tożsamości (domyślnie ~ / .ssh / id_rsa.pub), niezależnie od tego, czy w ssh-agent są jakieś klucze. W przeciwnym razie, jeśli to: ssh-add -L dostarcza jakieś dane wyjściowe, wykorzystuje je zamiast pliku tożsamości.

Więc w zasadzie chcesz to sprawdzić:

• Agent uwierzytelniania systemu (zwykle ssh-agent) widzi klucze, których zamierzasz użyć (sprawdź ssh-add -Ldane wyjściowe)
  • Jeśli nie widzisz pożądanego klucza, dodaj go za pomocą ssh-add
• ssh-copy-idSkopiowane z tego samego klucza do zdalnego komputera (wystarczy zalogować się do zdalnego serwera za pomocą hasła i sprawdzić zawartość ~/.ssh/authorized_keys)
  • Jeśli nie widzisz żądanego klucza na zdalnym serwerze, możesz domyślnie powiedzieć, ssh-copy-idktóry klucz skopiować:ssh-copy-id -i ~/.ssh/some_public_key

Mam nadzieję, że to pomaga.

Najczęstszym problemem są nieprawidłowe uprawnienia po stronie serwera. Sprawdź, czy żaden z katalogu domowym, ~/.ssha ~/.ssh/authorized_keysto zapisywalny przez nikogo, ale (w szczególności nie mogą być grupa zapisu).

Jeśli to nie jest problem, uruchom ssh -vvv serveri spójrz na widok rozmowy klienta. W szczególności sprawdź, czy klient próbuje klucza z serwerem.

Oprócz wszystkich powyższych, zawsze można sprawdzić plik dziennika sshd:

/var/log/auth.log

Próbowałem innych poprawek, ale okazało się, że musiałem zmienić katalog domowy, aby inni nie mogli zapisywać. Katalog domowy to 777. Zmieniłem go na 755 i działało.

w moim przypadku / etc / ssh / sshd_config zawierał następujący parametr:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys2

Ale ssh-copy-id utworzył plik o nazwie nazwa_autoryzowanych kluczy, więc musiałem zmodyfikować wpis do nowej nazwy. Więcej informacji na temat wycofanych kluczy autoryzowanych2

Jako uzupełnienie odpowiedzi Omera Dagana na nowszy CentOS 7 użyj:

journalctl -f -u sshd

do przeglądania dzienników sshd na serwerze.

Problem polegał na tym, że wyłączono uwierzytelnianie RSA w / etc / ssh / ssh_config