Rozłączono: brak dostępnych obsługiwanych metod uwierzytelniania

Mam dokładnie ten sam problem opisany w tym wątku , ale odpowiedź zaakceptowana nie jest dla mnie odpowiednia, ponieważ katalog domowy użytkownika jest lokalny.

Myślę, że wszystko skonfigurowałem poprawnie po stronie klienta (Windows 7, PAGEANT PuTTY, PUTTYGEN i PLINK), ale nie wydaje mi się, aby mechanizm klucza publicznego działał (logowanie ssh oparte na haśle). Postępowałem zgodnie ze wszystkimi krokami, wskazówkami i wskazówkami w:

• Jak skonfigurować uwierzytelnianie kluczy SSH za pomocą PuTTY i Linux Server w 5 szybkich krokach
• Uwierzytelnianie klucza publicznego SSH

Teraz podejrzewam, że coś może mi brakować po stronie serwera (Linux, sshd), więc publikuję aktualną /etc/ssh/sshd_configtreść:

Protocol 2
SyslogFacility AUTHPRIV
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
Subsystem       sftp    /usr/libexec/openssh/sftp-server

Masz pojęcie, co robię źle?

AKTUALIZACJA: Znalazłem wskazówkę dotyczącą uruchamiania sshd w trybie debugowania , a oto dane wyjściowe:

/home/winwin> /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.2p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.1.8 port 49828
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60
debug1: no match: PuTTY_Release_0.60
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes256-ctr hmac-sha1 none
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done

debug1: userauth-request for user winwin service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "winwin"
debug1: PAM: setting PAM_RHOST to "win7client"
debug1: PAM: setting PAM_TTY to "ssh"
Failed none for winwin from 192.168.1.8 port 49828 ssh2
debug1: userauth-request for user winwin service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 513/513 (e=0/0)
debug1: trying public key file /home/winwin/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /home/winwin
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 513/513 (e=0/0)
debug1: trying public key file /home/winwin/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /home/winwin
debug1: restore_uid: 0/0
Failed publickey for winwin from 192.168.1.8 port 49828 ssh2
Received disconnect from 192.168.1.8: 14: No supported authentication methods available
debug1: do_cleanup
debug1: PAM: cleanup
debug1: do_cleanup
debug1: PAM: cleanup

Teraz zauważam dwie bad ownership or modes for directory /home/winwinwiadomości, ale sprawdziłem własność lub tryby dla katalogu / home / winwin i AFAICT, czy są w porządku:

/home> ls -lad winwin
drwxrwxr-x  21 winwin winwin 4096 Jul 13 21:24 winwin

I:

/home/winwin> ls -lad .ssh
drwxr-xr-x  2 winwin winwin 4096 Jul 14 12:06 .ssh

I:

/home/winwin/.ssh> ls -lad *
-rw-r--r--  1 winwin winwin 210 Jul 14 12:06 authorized_keys
-rw-r--r--  1 winwin winwin 210 Jul 14 01:58 authorized_keys.pub
-rw-r--r--  1 winwin winwin 394 Jul 14 01:57 authorized_keys.pub.orig

Co może być nie tak?

AKTUALIZACJA II: Próbowałem chmod 600zgodnie z sugestią w odpowiedzi poniżej:

/home/winwin> ls -lad .ssh
drw-------  2 winwin winwin 4096 Jul 14 13:13 .ssh

I:

/home/winwin/.ssh> ls -lad *
-rw-------  1 winwin winwin 210 Jul 14 12:06 authorized_keys

Ale nadal nie działa. Dlaczego nadal pojawia się Authentication refused: bad ownership or modes for directory /home/winwinbłąd?

Spróbuj pobrać uprawnienia do zapisu grupowego z katalogu domowego:

chmod g-w ~/

Spraw, aby folder .ssh był czytelny / zapisywalny / wykonywalny tylko przez Ciebie :

chmod 700 ~/.ssh

Dokonać autoryzowanych kluczy złożyć czytelny / zapisywalny tylko dla Ciebie :

chmod 600 ~/.ssh/authorized_keys

To powinno usunąć błędy uprawnień.

Sukces!

Wszystko, co musiałem zrobić, to zmienić StrictModesna „ nie” .

Zgodnie z sekcją 3.14 w OpenSSH FAQ i http://blogs.nullvision.com/?p=114 .

Łał.

Miał podobny problem. Podczas szukania zauważyłem, że mam zaszyfrowane katalogi domowe i podejrzewałem, że to jest problem. Skopiowałem plik autoryzowanych kluczy do katalogu poza zaszyfrowanym katalogiem domowym, odpowiednio zmieniłem uprawnienia (chmod 700 [katalog], chmod 600 [katalog] / klucze_autoryzowane itp.).

Następnie edytuj sshd_config, aby poinformować sshd o nowej lokalizacji dla pliku autoryzowanych kluczy, zrestartuj sshd i to wszystko.

Wygląda na to, że naprawiłem mój problem.

Wygląda na to, że twoje uprawnienia do katalogu domowego (lub ewentualnie folderu .ssh / Author_keys) są nieprawidłowe. Poprawienie ich powinno rozwiązać problem z logowaniem. Spróbuj chmod 600 /home/winwin/.ssh/*
Być może również będziesz musiał chmod 700 /home/winwin/.ssh.

SSHd odmówi załadowania authorized_keyspliku, jeśli może go zapisać ktoś inny niż użytkownik (jako właściciel), ponieważ stanowi to zagrożenie bezpieczeństwa.

Walczyłem przez to iw końcu znaleźliśmy rozwiązanie, które nie powoduje potencjalne naruszenie zabezpieczeń jak StrictModes Nie robi.

Upewnij się, że ustawienia są następujące:

chmod 0755 / home / {userdir}

chmod 0700 / home / {userdir} /.ssh

chmod 0600 / home / {userdir} /.ssh/authorized_keys

Gdzie {userdir} to katalog, o którym mowa.

Kluczem jest chmod 0755, który zapewnia, że ​​tylko użytkownik może zapisywać na dysku domowym. Skopiowałem to z mojej konfiguracji użytkownika, która działała i, presto! Inne nazwy użytkowników też zaczęły działać!

Mam nadzieję, że to pomaga innym, tak jak ja, i pozwala zaoszczędzić kilka godzin czasu.

Ten komunikat o błędzie może być również spowodowany przez SELinux uniemożliwiający dostęp do sshd authorized_keys. Spróbuj tego:

restorecon -FRvv ~/.ssh

(z tej odpowiedzi )

chown -R winwin.winwin /home/winwin/
chmod 700 /home/winwin/
find /home/winwin/ -type d -exec chmod 700 {} \;
find /home/winwin/ -type f -exec chmod 600 {} \;

W moim przypadku był to katalog domowy, który miał innego właściciela (root) niż faktyczny użytkownik, do którego należy ten katalog domowy (moja głupota przy tworzeniu katalogu domowego z rootem dla innego użytkownika).

Chown [user]:[group] /home/[user] 

rozwiązał ten problem (i oczywiście trzymaj się uprawnień do pliku / katalogu, jak udostępniono w innych odpowiedziach).