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

12

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:

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?

WinWin
źródło

Odpowiedzi:

9

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

John T.
źródło
Zrobiłem tak, jak sugerowałeś dla ~/.sshi ~/.ssh/authorized_keys. Wciąż nie ma szczęścia. Jeśli chodzi o pobieranie uprawnień do zapisu grupowego z samego katalogu domowego, nie mogę tego zrobić, ponieważ podważyłoby to cały cel tego użytkownika / grupy, dla którego został stworzony. Katalog domowy tego użytkownika musi być możliwy do zapisu przez grupę (o tej samej dokładnej nazwie i gid!). +1 za próbę pomocy.
WinWin
Dziękuję Ci! chmod g-w ~/uratował mnie po godzinach szaleństwa i ciągnięcia włosów, gdy nie mogłem ssh z kitem w imieniu jednego z użytkowników, a inni użytkownicy
działali
Dziękuję, utworzyłem katalog domowy z innym użytkownikiem i brakowało mi chmod gw ~ /
Clarence Liu
5

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

WinWin
źródło
Hmm, to jednak bardziej obejście niż rozwiązanie. Pozwól, że sprawdzę coś na moim pudełku.
Rob
Mój ls -lad .sshpokazuje drwx, więc chmod 700 ~/.sshi wszystkie pliki w nim są -rw, więc chmod 600 ~/.ssh/*-SHOULD- działa.
Rob
Nieważne, widziałem Katalog domowy tego użytkownika musi być do zapisu przez grupę (o tej samej dokładnej nazwie i gid!) Poniżej
Rob
Ten sposób jest bezużyteczny!
Uwielbiam
3

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.

czerwony
źródło
2

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.

Darth Android
źródło
Dzięki +1. Zobacz moją aktualizację powyżej, ponieważ wciąż nie mogę ustalić, jakie powinny być prawidłowe uprawnienia / prawa własności.
WinWin
Właśnie próbowałem chmod 600 /home/winwin/.ssh/*. To nie pomogło. : - /
WinWin
1
@WinWin, czy ustawiłeś go również w .sshkatalogu? (Zaktualizowałem swoją odpowiedź).
Darth Android
Tak. Wciąż nie ma szczęścia.
WinWin
2

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.

smcjones
źródło
1

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 )

RomanSt
źródło
0
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 {} \;
Wujek Bob
źródło
3
Witamy w Super User! Byłoby miło, gdybyś mógł wyjaśnić, co robią te polecenia.
slhck
0

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

Philippe
źródło