usługa pam (sshd) ignoruje maksymalną liczbę ponownych prób

32

Mam vps, których używam do uruchomienia serwera WWW, obecnie działa na nim Ubuntu Server 12.04. Od kilku tygodni ciągle pojawia się wiele błędów w mojej konsoli ssh.

2014 Apr 11 08:41:18 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:21 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:24 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:25 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:26 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:29 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:29 vps847 PAM service(sshd) ignoring max retries; 6 > 3

Czy ktoś mógłby mi powiedzieć, co oznaczają te błędy. A przynajmniej powiedz mi, jak wyłączyć te błędy. Naprawdę denerwujące jest, gdy pracuję nad ssh i te błędy pojawiają się na całym ekranie.

Jerodev
źródło

Odpowiedzi:

40

PAMinformuje, że jest skonfigurowany z „retry = 3” i zignoruje wszelkie dalsze żądania uwierzytelnienia od sshd w tej samej sesji. SSHbędzie jednak kontynuować próbę, dopóki nie wyczerpie ustawienia MaxAuthTries (domyślnie 6).

Prawdopodobnie powinieneś ustawić oba (SSH i PAM) na tę samą wartość dla maksymalnej liczby ponownych prób uwierzytelnienia.

Zaktualizowano

Aby zmienić to zachowanie:

Do sshdedycji /etc/ssh/sshd_configi ustawienia MaxAuthTries 3. Zrestartuj również serwer SSH, aby ustawienie zaczęło obowiązywać.

Ponieważ PAMmusisz szukać konfiguracji w /etc/pam.dkatalogu (myślę, że jest to common-passwordplik w Ubuntu), musisz zmienić retry=wartość.

Uwaga: zdecydowanie zalecam również sprawdzenie odpowiedzi Petera Hommela odnośnie przyczyny tych próśb, ponieważ możliwe jest, że twoje SSH jest brutalnie zmuszane.

phoops
źródło
Dziękuję, problem został rozwiązany przez dodanie MaxAuthTries 3w konfiguracji ssh, a następnie ponowne uruchomienie serwera.
Jerodev
41

Podczas gdy inne odpowiedzi są poprawne w eliminowaniu otrzymanego komunikatu o błędzie, należy wziąć pod uwagę, że ten komunikat o błędzie może być tylko objawem innego podstawowego problemu.

Otrzymujesz te wiadomości, ponieważ w twoim systemie jest wiele nieudanych prób logowania przez ssh. Może być ktoś, kto próbuje użyć siły w twoim pudełku (tak było w przypadku, gdy dostałem te same wiadomości w moim systemie). Przeczytaj swoje var/log/auth.logbadania ...

W takim przypadku powinieneś rozważyć zainstalowanie narzędzia takiego jak „fail2ban” ( sudo apt-get install fail2banna Ubuntu). Automatycznie odczytuje pliki dziennika twojego systemu, wyszukuje wiele nieudanych prób logowania i blokuje złośliwych klientów na konfigurowalny czas za pomocą iptables ...

Peter Hommel
źródło
4
To bardzo miły komentarz, zaktualizowałem swoją odpowiedź notatką, aby przeczytać również odpowiedź dla każdego, kto może się z tym spotkać.
phoops
5

Wydaje się, że powyższa analiza nie jest całkowicie poprawna. Wydaje się, że nie ma opcji ponawiania = uwierzytelniania pam (znalazłem taką dla pam_cracklib, ale dotyczy to tylko zmiany hasła w sekcji „hasło”, a nie uwierzytelnienia w sekcji „autoryzacja” pam). Zamiast tego pam_unix zawiera wbudowaną maksymalną liczbę prób 3. Po 3 próbach pam zwraca kod błędu PAM_MAXRETRIES, aby poinformować o tym sshd.

sshd powinien naprawdę przestać próbować w tym przypadku, niezależnie od własnego MaxAuthTries. Nie działa, co moim zdaniem jest błędem (które właśnie zgłosiłem za pomocą openssh ).

Dopóki ten błąd nie zostanie naprawiony, wydaje się, że ustawienie MaxAuthTries na <= 3 jest jedynym sposobem, aby zapobiec wyświetlaniu się tego komunikatu.

Matthijs Kooijman
źródło
błąd wydaje się naprawiony w wersji 7.3p1
Dennis Nolte,
3

Klient ssh może próbować uwierzytelnić się za pomocą jednego lub więcej kluczy. Wszelkie klucze, które nie są wymienione w uprawnionych kluczach nie powiodą się, zużywając jedną z prób sshd. Klient będzie wypróbowywał każdy klucz ssh, który ma, dopóki jeden się nie powiedzie lub wszystkie zawiodą, więc dobrze, że sshd pozwala wypróbować kilka.

Jeśli żaden klucz nie pasuje, sshd może pozwolić ci na wypróbowanie hasła. Każda z tych prób zużywa również jedną z dozwolonych prób sshd. Ale zużywa również jedną z dozwolonych prób PAM.

Tak więc kombinacja 6 prób uwierzytelnienia ssh i 3 prób autoryzacji pam jest dobra: oznacza, że ​​ssh pozwoli na 6 prób uwierzytelnienia łącznie (klucz lub hasło), ale tylko 3 próby hasła.

Jak powiedzieli inni, jeśli często widujesz je w swoich logach, ktoś próbuje brutalnie przedostać się do twojego systemu. Rozważ użycie fail2ban do całkowitego zablokowania pakietów z adresów IP, z których pochodzą te próby.

Rachunek
źródło
1

Po uaktualnieniu z Debiana 6 do Debiana 7 napotkałem te same problemy. Nagle te błędy sshd pojawiły się w mojej konsoli.

2014 Oct 15 13:50:12 vps456 PAM service(sshd) ignoring max retries; 6 > 3
2014 Oct 15 13:50:17 vps456 PAM service(sshd) ignoring max retries; 6 > 3
2014 Oct 15 13:50:18 vps456 PAM service(sshd) ignoring max retries; 6 > 3

W moim przypadku problemem było to, że rsyslognie był już instalowany po aktualizacji Debiana.

Po zainstalowaniu rsyslog te błędy zniknęły z mojej konsoli: apt-get install rsyslog

komputer
źródło
3
To sprawia, że ​​pojawiają się tylko w innym miejscu zamiast konsoli. Moja odpowiedź naprawia przyczynę błędu z powodu błędnej konfiguracji SSH / PAM po aktualizacji.
phoops
-1

Z pewnością otrzymywanie tych powiadomień na konsoli może być denerwujące, ale kiedy widzę w moich plikach dziennika, że ​​wczoraj miałem 987 nieudanych prób logowania roota z adresu IP w Chinach lub 2670 z jakiejś usługi w chmurze w Kalifornii, lub ... wielu inni, nie martwię się. Użytkownik root nie może się w ogóle zalogować na moim komputerze. Nie ważne ile prób.

Gdyby zaczęli wypróbowywać nazwy użytkowników, które mogą się zalogować, to byłaby inna sprawa, ale jeśli ktoś ma dobre hasła, nie widzę tam ryzyka. Hasła logowania (w przeciwieństwie do kluczy szyfrujących) można wypróbować tylko tak szybko.

Używanie czegoś takiego jak fail2ban wydaje się niepotrzebną złożonością, która niczego nie kupuje (jeśli masz dobre hasła), a złożoność jest szkodliwa dla bezpieczeństwa. Dławienia prób jest coś, sshd powinien realizować, a nie coś, co powinno wymagać jakiś dodatek ... i sshd robi przepustnicy prób. Dobry.

-kb, Kent, który używa tylko dobrych haseł i nigdy nie przetwarzał między różnymi witrynami.

Kent Borg
źródło
2
Używanie kluczy ssh i wyłączanie haseł jeszcze lepiej zapobiega udanym atakom z użyciem siły.
HBruijn,
Tak, ale problem przenosi się na ochronę kluczy SSH. Gdzie oni są? Czy są szyfrowane? Jak dobry klucz je chroni? Jeśli hasło nie może zostać złamane w ciągu X lat prób, to nie może zostać złamane w ciągu X lat prób, do czego potrzebujesz „lepszego”? Dużo czasu poświęcam na zarządzanie hasłami i mogę je wpisać, wiele z nich pamiętam. Ale kilka kluczy ssh? Potrzebujesz bezpiecznego miejsca, aby je zachować.
Kent Borg
2
Brutalne wymuszanie hasła (zwykle krótszego niż 20 znaków i zbyt często źle wybierane) jest znacznie prostsze niż brutalne wymuszanie 1024-bitowego klucza prywatnego (uprościło odpowiednik hasła 128-znakowego), aby uzyskać dostęp przez SSH. Trzymajmy się porównywania jabłek z jabłkami. - - O ile nie jesteś kompletnym idiotą (np. Przechowując swój prywatny klucz w publicznym githubie) dostanie się do prywatnego klucza ssh jest trudne, ponieważ nie musi nigdy opuszczać stacji roboczej. Po naruszeniu klucza prywatnego nie jesteśmy już w losowych atakach, ale wkraczamy w sferę ataków ukierunkowanych ...
HBruijn,
@Kent wiesz, że możesz zabezpieczyć hasłem klucze SSH? Mówisz również, że fail2ban jest niepotrzebny, ale nadal sugerujesz, że SSH powinien implementować tę funkcję w sobie. Ponadto, jeśli nie zablokujesz żądań, mogą one znacznie łatwiej wykonać DDoS.
phoops