SSH Too many authentication failures: jak naprawić błąd

Co oznacza komunikat "Too many authentication failures"

Komunikat "Too many authentication failures" oznacza, że klient SSH zaoferował serwerowi więcej kluczy, niż ten był w stanie sprawdzić, przez co serwer zamknął połączenie przed próbą użycia właściwego klucza. Jest to niemal zawsze problem po stronie klienta. Klucz znajduje się na dysku, serwer posiada go w authorized_keys, jednak te fakty nie mają znaczenia, ponieważ połączenie zostało przerwane zbyt wcześnie.

Oto mechanizm tego zjawiska. ssh-agent przechowuje wszystkie klucze prywatne, które zostały do niego załadowane. Klient oferuje te klucze serwerowi pojedynczo, ponieważ nie posiada informacji, który z nich jest akceptowany przez konto. Serwer odrzuca każdy klucz, którego nie ma w authorized_keys, i zlicza każde odrzucenie jako nieudaną próbę uwierzytelnienia. Parametr MaxAuthTries w pliku sshd_config ogranicza liczbę dozwolonych niepowodzeń w ramach jednego połączenia. Wartość domyślna wynosi 6. Jeśli agent przechowuje dziesięć kluczy, a właściwy znajduje się na ósmej pozycji, serwer rozłączy sesję, zanim do niego dotrze.

Rozwiązaniem jest skonfigurowanie klienta tak, aby oferował tylko jeden, właściwy klucz.

Co zlicza serwer i gdzie pojawia się MaxAuthTries

Uwierzytelnianie kluczem publicznym zaczyna się od zgadywania. Klient przesyła klucz publiczny i pyta, czy serwer zaakceptuje podpis wykonany za jego pomocą. Serwer odpowiada twierdząco lub przecząco. Odpowiedź negatywna jest nieudaną próbą, dokładnie taką samą jak błędne hasło.

Strona podręcznika systemowego sshd_config(5) opisuje ten limit: „Określa maksymalną liczbę prób uwierzytelnienia dozwolonych na połączenie. Gdy liczba niepowodzeń osiągnie połowę tej wartości, kolejne błędy są rejestrowane w dzienniku. Wartość domyślna to 6”.

Sześć prób to wystarczająca liczba dla osoby wpisującej hasło. To jednak niewiele dla agenta przechowującego dziesięć kluczy. Gdy liczba niepowodzeń przekroczy limit, sshd rozłącza sesję i zapisuje w dzienniku systemowym linię o następującej treści:

error: maximum authentication attempts exceeded for deploy from 203.0.113.10 port 51292 ssh2

Klient wyświetla drugą stronę tego samego zdarzenia:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures
Disconnected from 203.0.113.10 port 22

Jest to błąd inny niż błąd SSH permission denied (publickey). W tamtym przypadku serwer sprawdził wszystkie przedstawione klucze i nie zaakceptował żadnego z nich. Tutaj serwer przestał sprawdzać. Mylenie tych dwóch sytuacji jest powodem, dla którego użytkownicy tracą popołudnia na ponowne kopiowanie klucza, który od początku był poprawny.

Dlaczego ten sam klucz działa z laptopa współpracownika

Klucz oraz serwer nie różnią się niczym. Agent współpracownika przechowuje dwa klucze, a Twój dwanaście. Oferta, która dla nich dociera jako pierwsza, dla Ciebie jest dziewiąta w kolejności, a do tego czasu połączenie zostaje zakończone.

Liczba kluczy rośnie niezauważenie. AddKeysToAgent yes w ~/.ssh/config dodaje każdy użyty klucz do agenta i pozostawia go tam. Agenty pęku kluczy w środowiskach graficznych, takie jak GNOME Keyring w systemie Linux lub login keychain w systemie macOS, ładują klucze podczas logowania bez pytania. Dodanie klucza klienta, klucza hosta git oraz klucza do serwera laboratoryjnego w ciągu roku sprawia, że pewnego dnia serwer, który zawsze działał, zaczyna odmawiać dostępu. Na serwerze nic się nie zmieniło. Twój agent stał się zbyt pełny.

Jak sprawdzić oferty za pomocą ssh -v

Uruchom nieudane połączenie z flagą -v i przeanalizuj ślad.

ssh -v deploy@203.0.113.10

Istotne są dwa rodzaje linii. Will attempt key: wymienia tożsamości zebrane przez klienta w kolejności, w jakiej zostaną użyte. Offering public key: pojawia się raz dla każdego klucza faktycznie wysłanego do serwera.

debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:AAAA... agent
debug1: Will attempt key: /home/you/.ssh/id_rsa RSA SHA256:BBBB... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:AAAA... agent
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/you/.ssh/id_rsa RSA SHA256:BBBB... agent

Ścieżki, typy kluczy oraz odciski palców będą się różnić. Należy policzyć liczbę linii Offering public key: przed rozłączeniem. Jeśli oferty przewijają się, a sesja kończy się bez pojawienia się oczekiwanego klucza, diagnoza jest ustalona. Słowo agent na końcu linii oznacza, że tożsamość pochodzi z ssh-agent. Słowo explicit oznacza, że pochodzi ona z linii IdentityFile lub z -i w wierszu poleceń.

Następnie sprawdź, jakie klucze przechowuje agent:

ssh-add -l

Każda linia wyjścia to jeden załadowany klucz. Jeśli wyświetlony zostanie komunikat The agent has no identities., problem nie leży po stronie agenta i należy sprawdzić linie IdentityFile w pliku ~/.ssh/config. Jeśli wyświetlony zostanie komunikat Could not open a connection to your authentication agent., oznacza to, że agent nie jest uruchomiony, a oferty pochodzą z domyślnych plików kluczy.

Rozwiązanie 1: IdentitiesOnly z jednym kluczem na hosta

IdentitiesOnly yes instruuje ssh, aby oferowało wyłącznie klucze skonfigurowane jawnie, ignorując pozostałe klucze udostępniane przez agenta. W połączeniu z dyrektywą IdentityFile klient wysyła tylko jedną ofertę.

Host vps
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519_vps
  IdentitiesOnly yes

Zapisz powyższą konfigurację w ~/.ssh/config, a następnie wykonaj chmod 600 ~/.ssh/config. Jeśli plik posiada uprawnienia do zapisu dla grupy lub wszystkich użytkowników, ssh odmówi działania, zwracając Bad owner or permissions on /home/you/.ssh/config. Teraz ssh vps oferuje jeden klucz, a ssh -v vps powinno wyświetlić dokładnie jedną linię Offering public key:.

Dwa szczegóły często zaskakują użytkowników:

• Samo IdentitiesOnly yes nie oznacza "jednego klucza". Domyślne pliki tożsamości są traktowane jako skonfigurowane, więc ssh nadal próbuje użyć ~/.ssh/id_ed25519, ~/.ssh/id_rsa oraz innych domyślnych lokalizacji. Wymagane jest również użycie dyrektywy IdentityFile.
• Podpisywanie nadal wykonuje agent. IdentitiesOnly kontroluje jedynie, które klucze są oferowane, a nie kto je podpisuje. Jeśli klucz prywatny wskazany przez IdentityFile jest załadowany w agencie, agent wygeneruje podpis i nie pojawi się monit o hasło. Można nawet wskazać IdentityFile na odpowiedni plik .pub, co jest standardową praktyką, gdy klucz prywatny znajduje się wyłącznie w agencie lub na tokenie sprzętowym.

Jedna pułapka w ~/.ssh/config może niepostrzeżenie zniweczyć to rozwiązanie. Większość parametrów przyjmuje pierwszą napotkaną wartość, dlatego specyficzne bloki Host muszą znajdować się powyżej Host *. IdentityFile nie podlega tej zasadzie. Dokumentacja techniczna stwierdza: "Możliwe jest określenie wielu plików tożsamości w plikach konfiguracyjnych; wszystkie te tożsamości będą próbowane sekwencyjnie". Dyrektywa IdentityFile umieszczona w Host * jest dodawana do konfiguracji dla konkretnego hosta, a nie zastępuje jej, więc zapomniana globalna linia przywraca dodatkową ofertę w każdym połączeniu.

Jeśli wymagane jest globalne zabezpieczenie, należy ustawić wyłącznie flagę na końcu pliku:

Host *
  IdentitiesOnly yes

Każdy host wymaga wówczas własnego wpisu IdentityFile, co jest pożądanym stanem docelowym. Przypisanie jednego klucza do jednego serwera umożliwia późniejsze unieważnienie dostępu dla pojedynczej maszyny bez konieczności generowania wszystkich kluczy od nowa. Warto wyrobić ten nawyk jak najwcześniej: zobacz jak zarządzać kluczami SSH dla poszczególnych maszyn.

Rozwiązanie 2: wyczyszczenie lub restart agenta

Jeśli edycja konfiguracji nie jest jeszcze możliwa, należy opróżnić agenta i załadować tylko niezbędne elementy.

ssh-add -l                    # list what is loaded
ssh-add -d ~/.ssh/id_rsa      # remove one key
ssh-add -D                    # remove every key
ssh-add ~/.ssh/id_ed25519_vps # load the one you need

Jeśli połączenie działa poprawnie bezpośrednio po wykonaniu ssh-add -D, przyczyną był agent. Należy traktować to jako test, a nie naprawę. Agent pęku kluczy środowiska graficznego przeładowuje klucze przy następnym logowaniu, więc problem powróci kolejnego dnia. Wpis IdentitiesOnly w pliku ~/.ssh/config przetrwa restart systemu. Pusty agent nie.

Można również nadać kluczowi czas życia, aby agent automatycznie go usunął:

ssh-add -t 1800 ~/.ssh/id_ed25519_vps

Klucz zostanie usunięty 1800 sekund po dodaniu. Restart agenta również jest skuteczny, a sposób jego wykonania zależy od metody uruchomienia. Proces ssh-agent uruchomiony samodzielnie zatrzymuje się za pomocą ssh-agent -k. W przypadku jednostki użytkownika systemd, należy zrestartować ją poleceniem systemctl --user restart <unit>. Agent pęku kluczy restartuje się wraz z sesją użytkownika.

Poprawka 3: polecenie jednorazowe dla serwera, z którym łączysz się sporadycznie

W przypadku hosta, którego nie chcesz dodawać do konfiguracji, umieść te same ustawienia w wierszu poleceń:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10

Samo -i jest najczęstszą błędną poprawką. -i dodaje klucz do listy tożsamości. Nie usuwa ono kluczy agenta z tej listy, więc wszystkie inne oferty nadal są wysyłane przed Twoją, a połączenie nadal zostaje zerwane po osiągnięciu limitu. Uruchom ssh -v -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10 bez IdentitiesOnly, a zobaczysz, że klucze agenta są oferowane jako pierwsze. -i wymaga obecności -o IdentitiesOnly=yes.

Aby całkowicie wykluczyć agenta z procesu dla pojedynczego połączenia:

ssh -o IdentityAgent=none -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10

ssh odczytuje wtedy klucz prywatny z dysku i prosi o hasło, jeśli zostało ono ustawione.

Narzędzia oparte na ssh akceptują tę samą opcję:

scp -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps report.tar.gz deploy@203.0.113.10:/tmp/
rsync -av -e "ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps" ./site/ deploy@203.0.113.10:/srv/site/
GIT_SSH_COMMAND="ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps" git clone git@example.com:team/repo.git

Dlaczego błąd pojawia się na drugim przeskoku

Dzięki ForwardAgent yes gniazdo agenta jest udostępniane na serwerze, z którym nawiązywane jest połączenie. Polecenie ssh uruchomione na tym serwerze korzysta z lokalnego agenta oraz wszystkich kluczy za pośrednictwem przekierowanego gniazda. Dlatego błąd może wystąpić podczas przeskoku z hosta pośredniczącego (jump host) do serwera docelowego, mimo że pierwszy przeskok przebiegł poprawnie. Należy wykonać echo $SSH_AUTH_SOCK na maszynie pośredniej: ścieżka do gniazda oznacza, że przekierowany agent jest dostępny, natomiast brak danych wyjściowych oznacza jego brak.

Przekierowanie agenta wiąże się z dodatkowym ryzykiem. Każdy użytkownik z uprawnieniami root na maszynie pośredniej może użyć agenta do uwierzytelnienia się w imieniu użytkownika, dopóki sesja pozostaje otwarta. ProxyJump pozwala uniknąć obu tych problemów:

ssh -J deploy@jump.example.com deploy@10.0.0.5

ProxyJump otwiera połączenie przez host pośredniczący i uwierzytelnia się na serwerze docelowym bezpośrednio z maszyny lokalnej, dzięki czemu lokalne ~/.ssh/config ma zastosowanie na każdym przeskoku, w tym IdentitiesOnly. Wyłączenie ForwardAgent jest standardowym krokiem podczas utwardzania konfiguracji SSH na VPS.

Czy należy zwiększać MaxAuthTries na serwerze?

Zazwyczaj nie. Najpierw należy sprawdzić bieżącą wartość:

sudo sshd -T | grep -i maxauthtries

sshd -T wyświetla efektywną konfigurację, włącznie z wartościami domyślnymi, więc raportuje rzeczywistą wartość nawet wtedy, gdy sshd_config nie zawiera żadnych informacji na ten temat. Należy dodać -C user=deploy,host=example.com,addr=203.0.113.10 w przypadku korzystania z bloków Match, ponieważ są one oceniane dla każdego połączenia i w przeciwnym razie są pomijane.

Zwiększenie limitu działa w wąskim znaczeniu, ponieważ większa liczba daje nieprawidłowo działającemu klientowi więcej prób:

MaxAuthTries 20

Należy zweryfikować plik i przeładować usługę, utrzymując otwartą drugą sesję podczas wykonywania tych czynności:

sudo sshd -t
sudo systemctl reload ssh      # Debian and Ubuntu
sudo systemctl reload sshd     # RHEL family

Jeśli systemctl is-enabled ssh.socket raportuje enabled w systemie Ubuntu 24.04, sshd jest aktywowany przez gniazdo: dla każdego połączenia uruchamiany jest nowy proces, który ponownie odczytuje sshd_config, więc nowe połączenia automatycznie uwzględniają zmianę.

Teraz należy sprawdzić skutki tej zmiany. Klient oferuje klucze, których ten serwer nigdy nie zaakceptuje. Podniesienie limitu powoduje, że serwer musi przetworzyć dwadzieścia odrzuconych ofert na połączenie zamiast sześciu, dla każdego łączącego się klienta oraz dla każdego skanera haseł w Internecie. Każda oferta kosztuje serwer operację wyszukiwania w authorized_keys. Własne logowanie pozostaje powolne, ponieważ właściwy klucz nadal znajduje się na końcu kolejki. Dodanie trzynastego klucza do agenta powoduje powrót do punktu wyjścia i konieczność ponownego zwiększenia limitu.

Wartość tę należy zwiększać tylko wtedy, gdy uprawniony klient rzeczywiście musi przedstawić kilka tożsamości. W każdym innym przypadku należy naprawić konfigurację klienta. Obniżenie tej wartości jest rozsądnym działaniem wzmacniającym bezpieczeństwo, gdy każdy użytkownik loguje się przy użyciu skonfigurowanego klucza, ponieważ mniejsza liczba daje osobie próbującej odgadnąć hasło mniej prób na połączenie.

Dlaczego fail2ban może zablokować dostęp w tej sytuacji

Przy domyślnym poziomie logowania, sshd rejestruje każde odrzucone użycie klucza publicznego:

Failed publickey for deploy from 203.0.113.10 port 51292 ssh2: ED25519 SHA256:AAAA...

Jedno połączenie z pełnym agentem generuje kilka takich linii z jednego adresu w ciągu sekundy lub dwóch. Jail fail2ban sshd zlicza linie błędów sshd i blokuje adres źródłowy po osiągnięciu maxretry w czasie findtime. Te okna czasowe są domyślnie krótkie, więc dwie próby nawiązania zerwanego połączenia mogą wystarczyć do zablokowania własnego adresu.

Objawy ulegają wtedy zmianie, co często wprowadza użytkowników w błąd. Komunikat "Too many authentication failures" przestaje się pojawiać, a połączenie zawiesza się i ostatecznie kończy przekroczeniem czasu oczekiwania (timeout), ponieważ firewall odrzuca pakiety zamiast na nie odpowiadać. Timeout w miejscu, gdzie wcześniej występował komunikat o błędzie, jest sygnałem ostrzegawczym; różnica ta została omówiona w odmowa połączenia SSH a przekroczenie czasu oczekiwania.

Z poziomu konsoli dostawcy lub z innego adresu sprawdź stan jaila i usuń blokadę:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 203.0.113.10

Umieść własny adres w ignoreip w pliku jail.local na czas naprawy konfiguracji klienta, a następnie usuń go po zakończeniu prac. Sam jail jest skonfigurowany zgodnie z przewodnikiem po fail2ban dla Ubuntu 24.04.

Co zrobić raz, aby problem nie powracał

Dla każdego serwera należy utworzyć osobny blok Host w pliku ~/.ssh/config, zawierający parametry HostName, User, IdentityFile oraz IdentitiesOnly yes. Dzięki temu polecenie ssh vps jest krótkie, oferuje dokładnie jeden klucz i nie powoduje błędu MaxAuthTries, niezależnie od liczby wpisów w agencie. Pozwala to również zachować zwięzłość danych wyjściowych ssh -v, co ułatwia diagnostykę w przypadku wystąpienia innych awarii.

FAQ

Jak natychmiast naprawić błąd "Too many authentication failures"?

Należy wskazać tylko jeden klucz zamiast wszystkich dostępnych. Aby nawiązać natychmiastowe połączenie, wykonaj ssh -o IdentitiesOnly=yes -i ~/.ssh/your_key user@host. Aby wprowadzić trwałą poprawkę, dodaj blok do ~/.ssh/config zawierający HostName, User, IdentityFile wskazujący na dany klucz oraz IdentitiesOnly yes, a następnie chmod 600 ~/.ssh/config. Potwierdź konfigurację za pomocą ssh -v: powinieneś zobaczyć jedną linię Offering public key: dla tego hosta.

Dlaczego ssh -i nadal oferuje moje pozostałe klucze?

Ponieważ -i dodaje tożsamość do listy, a nie ogranicza jej. Klucze załadowane w ssh-agent pozostają na liście i są nadal oferowane, często przed Twoim kluczem, przez co serwer może osiągnąć MaxAuthTries, zanim dojdzie do Twojego klucza. -o IdentitiesOnly=yes to opcja, która ogranicza ssh wyłącznie do wskazanych tożsamości. Użyj -i i -o IdentitiesOnly=yes jednocześnie lub -o IdentityAgent=none, aby całkowicie zignorować agenta dla tego konkretnego połączenia.

Czy powinienem zwiększyć MaxAuthTries na serwerze, aby to naprawić?

Nie, w niemal każdym przypadku. Klient wysyła klucze, których serwer nigdy nie zaakceptuje, a wyższy limit jedynie sprawia, że serwer musi przetworzyć więcej odrzuconych ofert dla każdego połączenia, każdego klienta oraz każdej próby ataku brute force. Problem powróci natychmiast po dodaniu kolejnego klucza do agenta. Sprawdź bieżącą wartość za pomocą sudo sshd -T | grep -i maxauthtries, jeśli jesteś ciekaw, a następnie napraw konfigurację klienta za pomocą IdentitiesOnly.

Dlaczego problem pojawił się na serwerze, który działał poprawnie w zeszłym miesiącu?

Twój agent stał się większy. AddKeysToAgent yes w ~/.ssh/config utrzymuje załadowane wszystkie użyte klucze, a agenci kluczy w środowiskach graficznych ładują je automatycznie przy logowaniu. Gdy liczba załadowanych kluczy przekroczy wartość MaxAuthTries serwera, każdy serwer, którego klucz znajduje się na końcu listy ofert, zacznie zgłaszać błędy. Wykonaj ssh-add -l i porównaj liczbę kluczy z limitem na serwerze.

Czy to może doprowadzić do zbanowania mojego adresu IP przez fail2ban?

Tak. Każdy odrzucony klucz generuje linię Failed publickey for ... w dzienniku serwera, więc jedno połączenie może w kilka sekund wygenerować wiele błędów z Twojego adresu, a jail sshd w fail2ban zablokuje adres po osiągnięciu maxretry w czasie findtime. Sygnałem ostrzegawczym jest zmiana błędu na zawieszenie, a następnie timeout, ponieważ pakiety są odrzucane, zamiast być obsługiwane. Usuń blokadę z konsoli za pomocą sudo fail2ban-client set sshd unbanip <your address> i napraw konfigurację klienta przed ponownym połączeniem.