Jak odzyskać dane po „Zbyt wielu niepowodzeniach uwierzytelniania użytkownika root”

Zrobiłem kilka prób ustanowienia SSH-connecton dla użytkownika root @ host przy użyciu putty terminal. Robiąc to, podałem kilka razy nieprawidłowe dane uwierzytelniające, a następnie poprawnie je podałem, a następnie po ich zaakceptowaniu sesja ssh zrywa się z

„Serwer niespodziewanie zamknął połączenie sieciowe”.

Ten błąd jest zgłaszany przez szpachlówkę. Podczas próby ssh root @ localhost z lokalnej konsoli - działa dobrze. Działa również dobrze, gdy ssh otheruser @ host z innego hosta. Dlatego problemy z połączeniem sieciowym nie są winne. Jedyny błąd, o którym myślę, to: „Zbyt wiele niepowodzeń uwierzytelniania dla użytkownika root”, chociaż Kit zgłosił inny błąd.

Pytanie brzmi: jak odzyskać od tego błędu i pozwolić, aby Kit zalogował się ponownie? Ponowne uruchomienie sshd wydaje się nie pomagać

Czy jesteś pewien, że logowanie roota do ssh jest dozwolone?

Sprawdź sshd_config i sprawdź, czy logowanie root jest dozwolone. sshd będzie musiał zostać zrestartowany, jeśli ustawienie się zmieni.

„Zbyt wiele niepowodzeń uwierzytelniania dla użytkownika root” oznacza, że limit MaxAuthTries serwera SSH został przekroczony . Zdarza się tak, że Twój klient próbuje się uwierzytelnić za pomocą wszystkich możliwych kluczy przechowywanych w /home/USER/.ssh/.

Sytuację tę można rozwiązać na następujące sposoby:

1. ssh -i / path / to / id_rsa root @ host
2. Podaj parę Host / IdentityFile w /home/USER/.ssh/config .
   • Host host
   • IdentityFile /home/USER/.ssh/id_rsa
   • Host host2
   • IdentityFile /home/USER/.ssh/id_rsa2
3. Zwiększ wartość MaxAuthTries na serwerze SSH w / etc / ssh / sshd_config (niezalecane).

Jeśli pojawi się następujący błąd SSH:

$ Received disconnect from host: 2: Too many authentication failures for root

Może się to zdarzyć, jeśli masz (domyślnie w moim systemie) pięć lub więcej plików tożsamości DSA / RSA przechowywanych w twoim .sshkatalogu. W takim przypadku, jeśli -iopcja nie zostanie podana w wierszu poleceń, klient ssh najpierw spróbuje się zalogować przy użyciu każdej tożsamości (klucza prywatnego), a następnie poprosi o uwierzytelnienie hasła. Jednak sshd porzuca połączenie po pięciu błędnych próbach logowania (znowu domyślne mogą się różnić).

Więc jeśli masz kilka kluczy prywatnych w swoim katalogu .ssh, możesz wyłączyć Public Key Authenticationw wierszu poleceń, używając -oopcjonalnego argumentu.

Na przykład:

$ ssh -o PubkeyAuthentication=no root@host

Na zdalnym komputerze otwórz / etc / sshd_config i zmień wartość

MaxAuthTries 30

Jest to typowy problem w przypadku zainstalowania wielu kluczy lub otwarcia wielu połączeń. Sprawdzanie serwera krok po kroku dla każdego klucza, a jeśli MaxAuthTries jest ustawiony na 3, to po pierwszych 3 próbach rozłączy Cię. Typowe bezpieczeństwo ssh.

Sugeruję używanie trybu pełnego podczas połączenia ze zdalnym komputerem w celu analizy problemu.

ssh -v -p numer_portu użytkownik @ nazwa_serwera

Zgadywanie jak większość ludzi na tym forum jest NIEPRAWIDŁOWE i marnuje czas. Najpierw spróbuj przeanalizować problem, zbierz informacje, a następnie zapytaj.

Baw się dobrze.

To zła praktyka. Wystarczy mieć zwykłego użytkownika na zdalnym urządzeniu i połączyć się przez niego za pomocą ssh, a następnie uzyskać dostęp do roota za pomocą su / sudo.

Dla mnie ten problem został rozwiązany przez utworzenie poniższego ssh_config dla hosta, z którym się łączyłem.

(~ / .ssh / config)

Host example
HostName example.com
User admin
IdentityFile ~/path/to/ssh_key_rsa
IdentitiesOnly=yes

Problem wystąpił, ponieważ mam o wiele za dużo kluczy ssh w moim ~/.sshfolderze, na przykład około 16. I bez obu tych dyrektyw IdentityFileAND IdentitiesOnlyw konfiguracji, moja maszyna najwyraźniej próbowała wszystkich kluczy ~/.sshi osiągnęła maksymalną liczbę prób przed próbą poprawnego pliku IdentityFile.

Polecam, jak napisałem powyżej Anon, użyj innego użytkownika, aby uzyskać dostęp do ssh, a następnie użyj supolecenia, aby uzyskać rootdostęp.

Upewnij się także, aby włączyć PermitRootLoginw /etc/ssh/sshd_configpliku na serwerze.

Zetknąłem się również z tym samym problemem. Może się to łatwo zdarzyć, jeśli używasz programu Pageant i załadowano do niego dużą liczbę kluczy , ponieważ serwery te liczą każdą ofertę klucza publicznego jako próbę uwierzytelnienia.

(Ta rada pochodzi stąd .)

Rozwiązałem ten problem w moich systemach, uruchamiając następujące polecenia:

eval $(ssh-agent)
ssh-add  ~/.ssh/keyname

Następnie wypróbowanie ssh na zdalnym komputerze

Aby tymczasowo rozwiązać ten problem, dopóki sprawy nie zostaną w pełni rozwiązane, jak wspomniano w innym miejscu, możesz zresetować licznik PAM użytkownika, aby mógł spróbować ponownie:

pam_tally --reset --user <USERNAME>
pam_tally2 --reset --user <USERNAME>

Ugryzł mnie podobny problem. Jednak prawdziwą przyczyną było to, że miałem ForwardAgent yesw pliku konfiguracyjnym maszyny wzdłuż potoku. Łączyłem z maszyny A do maszyny B do maszyny C.

Komunikat o błędzie został wyświetlony przy próbie ssh z B -> C, ale był spowodowany aktywnym przesyłaniem dalej. Więc C najpierw podano wszystkie klucze z A, a dopiero potem te z B.

Nagle pojawił się, gdy dodałem jeszcze jeden klucz do A.

Rozwiązałem ten problem na komputerze Mac przez:

1. następnie ustaw hasło roota za pomocą „sudo passwd root”
2. edycja i zapisanie pliku konfiguracyjnego ssh za pomocą „nano / etc / ssh_config” i
3. zmiana RSAAuthentication na „nie” zamiast tak.

OK, więc w moim przypadku było to dość dziwne, proszę bardzo ...

Mam standardową maszynę wirtualną z kluczem SSH i mogę SSH do niego za pomocą Putty. Podczas próby dostania się do niego podczas wdrażania w PHPStorm pojawia się too many authentication failuresbłąd. Więc zwiększyłem MaxAuthTriesswoje, sshd_configa potem dostałem Auth failedbłąd i wtedy Auth cancel.

Teraz nie wiem dokładnie, dlaczego nawet tego spróbowałem, ale ... Dodałem kropkę na końcu ścieżki klucza SSH w oknie wdrażania w PHPStorm. Więc było tak:

C:\Users\Deadpool\\.ssh\chimichanga

a teraz jest tak:

C:\Users\Deadpool\\.ssh\chimichanga.

I to działa ... W moim folderze „.ssh” mam więcej plików:

chimichanga - copy of "id_rsa" from vagrant machine
chimichanga.ppk
chimichanga.pub

Nie jestem pewien, co robi ta cholerna kropka, ale używanie .ppkpliku nie działa, więc myślę, że to rodzaj magii;) Och, i mogłem pozbyć się MaxAuthTries po tej „sztuczce z kropką”.

Inne odpowiedzi podpowiadają ci najlepszy sposób na połączenie się z rootem i implikacje związane z bezpieczeństwem, ale twoje wyraźne pytanie brzmiało:

jak odzyskać po tym błędzie i pozwolić, aby Kit zalogował się ponownie?

Wspomniałeś przy ostatnim połączeniu, że serwer zdalny porzucił połączenie.

Myślę, że może się okazać, że na zdalnym serwerze działa fail2ban (*) i „uwięził” twój adres IP po pomyślnym zalogowaniu. Możesz to sprawdzić, próbując zalogować się ponownie, a nawet nie pojawi się monit o zalogowanie.

Istnieją dwa rozwiązania, możesz albo poczekać na czas więzienia, w którym to momencie wszystko wraca do normy, ale czas więzienia może być dowolny. Możesz też znaleźć inny komputer, z którego można się zalogować, zrób to i „usuń z więzienia” swój adres IP, w tym przypadku „inny” jest z perspektywy zdalnego serwera, więc inny komputer za tą samą zaporą prawdopodobnie nie będzie działał .

(*) fail2ban to bardzo przydatny demon, który może okresowo sprawdzać różne pliki dziennika i dostosowywać reguły zapory, aby serwer „znikał”, gdy wykryje potencjalnie złośliwe zachowanie klienta. W debianie wychodzi z pudełka skonfigurowanego do wykrywania wielu nieudanych logowań ssh z określonego adresu IP, a po 3 (myślę) porzuci wszystkie pakiety z tego adresu IP. Działa doskonale, aby powstrzymać te skrypty, ataki brutalnej siły.

Jak @sufferer wspomniał w innej odpowiedzi, niektóre dystrybucje Linuksa obejmują monitory do ochrony przed atakami siłowymi na zewnętrzne widoczne usługi, takie jak SSH, na przykład DenyHostslub fail2ban. Monitory te sprawdzają pliki dziennika w poszukiwaniu nieudanych prób i dodają filtry do blokowania adresów IP, które zawierają zbyt wiele awarii (liczbę można konfigurować i niezależnie od konfiguracji sshd).

Jeśli Twoja dystrybucja zawiera fail2ban, które chronią usługi dodające reguły do ​​zapory iptables, możesz sprawdzić, które usługi lub „więzienia” są nadzorowane za pomocą polecenia:

sudo fail2ban-client status

Więzieniem dla usługi SSH jest sshd, więc aby sprawdzić, czy istnieją zabronione adresy IP, możesz użyć:

sudo fail2ban-client status sshd

i aby odblokować trochę abcd IP:

sudo fail2ban-client set sshd unbanip a.b.c.d

Jeśli tak DenyHosts, zablokowana lista znajduje się w pliku /etc/hosts.deny; możesz edytować ten plik bezpośrednio jako root. Aby przyznać trwały dostęp do abcd IP, możesz dodać linię sshd:a.b.c.ddo pliku /etc/hosts.allow.

Jak zawsze, manpolecenie to twój przyjaciel:

man fail2ban
man hosts.deny

Powinny istnieć inne podobne narzędzia, ale ja tylko z nich korzystałem.

Zauważ, że zwiększenie liczby ponownych prób w konfiguracji sshd nie zwalnia zbanowanych adresów IP, pozwala tylko na więcej awarii w tym samym połączeniu. Jeśli dozwolona liczba zostanie przekroczona, użytkownik / atakujący po prostu ponownie się łączy, aby spróbować n razy więcej.

Inne usługi miały zintegrowaną listę banów (jak pokazano w odpowiedzi Rajnesha Thakura na temat ponownego uruchomienia serwera VNC).

Rozwiązałem ten problem, wykonując dwa proste kroki na moim serwerze Ubuntu 16.04 -

Najpierw zatrzymaj mój serwer VNC lub zabij proces -

vncserver -kill :1

a następnie uruchom go ponownie -

vncserver

Następnie podłącz go z klienta pulpitu zdalnego -

192.0.2.99:5901

Gotowy !!

wykonaj poniższe czynności, aby rozwiązać problem

1. Utwórz kopię zapasową / etc / ssh / sshd_config
2. Zwiększ wartość MaxAuthTries w sshd_config
3. stoprc -s sshd; Startrc -s sshd

I sprawdź ponownie po powyższych zmianach

Miałem ten sam problem, w którym otrzymywałem komunikat „Serwer SSER wysłał rozłączoną wiadomość typu 2 (błąd protokołu): zbyt wiele błędów uwierzytelnienia dla użytkownika”

Rozwiązałem ten problem, usuwając wszystkie moje ssh (klucze .ppk), a następnie zalogowałem się na zintegrowanym serwerze AD.