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

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.

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.

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

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.

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.

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

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.