Próba połączenia SSH z komputerem zdalnym, ale wciąż prośba o hasło

Próba połączenia SSH z komputerem zdalnym, ale wciąż prośba o hasło.

Mam kilka komputerów z systemem SElinux i tylko jeden z nich sprawia mi trudności z używaniem ssh bez hasła.

Zrobiłem ssh-copy-id i widzę mój klucz w .ssh / Author_keys.

I chmod 700 .ssh i chmod 600 wszystkie pliki w ./ssh/*

Jeśli zrobię ssh -v, to jest mój wynik:

OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to wcmisdlin05 [10.52.208.224] port 22.
debug1: Connection established.
debug1: identity file /home/jsmith/.ssh/identity type -1
debug1: identity file /home/jsmith/.ssh/id_rsa type 1
debug1: identity file /home/jsmith/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'wcmisdlin05' is known and matches the RSA host key.
debug1: Found key in /home/jsmith/.ssh/known_hosts:9
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found

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


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


debug1: Next authentication method: publickey
debug1: Offering public key: /home/jsmith/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/jsmith/.ssh/identity
debug1: Trying private key: /home/jsmith/.ssh/id_dsa
debug1: Next authentication method: password

Czy ktoś może mi powiedzieć, dlaczego nie działa na tym jednym komputerze zdalnym?

Często spotkałem podobny błąd na maszynach CentOS 6 z udziałem ssh-copy-idi SELinux.

Kiedy ssh-copy-idtworzy pliki autoryzowanych kluczy, tworzy je z odpowiednimi uprawnieniami, ale z niewłaściwą etykietą SELinux. Rozwiązaniem tego problemu jest przywrócenie etykiet do wartości domyślnych zasad za pomocą tego polecenia:

restorecon -R ~/.ssh

Te rzeczy są zawsze dużo łatwiej debugowane po stronie serwera, jeśli jest to możliwe. Jeśli możesz uruchomić sshd na innym porcie w trybie debugowania, natychmiast powie ci, dlaczego klucz jest odrzucany (domyślam się, że twój katalog domowy można zapisać w grupie). Możesz na przykład uruchomić sshd w trybie debugowania na porcie 2222 za pomocą /usr/sbin/sshd -d -p 2222, a następnie połączyć się z ssh -p 2222 user@remotehost.

Plakat, który odwoływał się do SElinuxa, uderzył mnie w głowę z powodu mojego problemu, nie chcę używać selinuxa, ale zapomniałem go wyłączyć, a serwer wymyślił selinux włączony podczas rozruchu.

ssh -vDebugowanie pomogło. Klucz jest akceptowany:

debug1: Found key in /var/lib/amanda/.ssh/known_hosts:19
debug1: ssh_rsa_verify: signature correct

I wtedy pojawia się błąd

debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found

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


debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found

Moją poprawką było wyłączenie selinux za pomocą, setenforce 0a następnie wyłączenie w / etc / selinux. Wtedy zadziałało dla mnie logowanie bez hasła ssh.

Doświadczyłem tego jakiś czas temu na RHEL5 (nie wiem, czy to jest dystrybucja, której używasz) i odkryłem, że było to tylko wtedy, gdy użyłem ssh-copy-id. Spróbuj scp'ować plik klucza do odpowiedniego folderu i oczywiście zresetować uprawnienia

W moim przypadku problem miał niepoprawny format authorized_keyspliku.

Nie powinno być żadnego nowej linii pomiędzy definicji formatu ( ssh-rss, ssh-dss..) i samego klucza publicznego.

Miałem wcześniej problemy z ssh i kluczami. Przy tej okazji zmiana nazwy mojego identyfikatora na „ id_rsa” pomogła. Niestety mam różne klucze dla różnych serwerów. To podejście ma ograniczoną użyteczność. Może to pomóc jednorazowo.

Po drugie dzisiaj znów mam ten błąd tylko w jednej sesji XTerm i wszystko działa świetnie w 6 innych sesjach xterm na tym samym serwerze / wężu. Porównałem więc wyniki z envobu sesji. Odkryłem, że jest to sesja robocza, której nie było w sesji niedziałającej:

SSH_AUTH_SOCK=/run/user/1001/keyring/ssh 

Wkleiłem to zadanie do sesji niedziałającej:

export SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
ssh  user@host
... Welcome ...

Innymi słowy, to rozwiązanie działało dla mnie.

Sprawdziłem trochę SSH_AUTH_SOCKET. Z tej odpowiedzi:

• Jak konfiguracja SSH_AUTH_SOCK jest używana przez ssh-agent?

ścieżka do gniazda plików unix, którego agent używa do komunikacji z innymi procesami

Wydaje mi się, że ma to zasadnicze znaczenie dla kluczowego rozwiązania opartego na wyniku.

debug1: Oferowanie klucza publicznego: /home/jsmith/.ssh/id_ rsa

...

debug1: Próbowanie klucza prywatnego: /home/jsmith/.ssh/id_ dsa

Wydaje mi się, że klucz prywatny / publiczny po prostu się nie zgadza. Nazwy kluczy mówią nam, że klucz publiczny to klucz RSA, a klucz prywatny to DSA.

Spróbuj wygenerować nową parę i scpklucz publiczny do serwera.

Polecam sprawdzenie uprawnień w ./ssh i katalogu domowym użytkownika, w pliku klucza i pliku autoryzowanych_kluczy, ponieważ nikt inny niż właściciel nie powinien mieć możliwości pisania i czytania, jeśli chcesz, aby połączenie ssh działało bez hasła. Dotyczy to zarówno maszyn źródłowych, jak i docelowych. Szczerze mówiąc, czasami działa, nawet jeśli istnieją większe prawa, ale nie powinno.