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

64

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ć

użytkownik11722
źródło
superuser.com/questions/187779/...
Ciro Santilli 事件 改造 中心 法轮功 六四 事件
1
Pamiętaj, aby wyłączyć agenta ssh (np. Pageant w systemie Windows), jeśli pojawi się Too many Authentication Failuresbłąd, zanim będziesz mógł w ogóle się zalogować.
Mahn

Odpowiedzi:

8

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.

damorg
źródło
120

„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).
Peta Sittek
źródło
9
To naprawdę powinna być zaakceptowana odpowiedź!
Benjamin
4
Aby być zaakceptowaną odpowiedzią, odpowiedź musiałaby dotyczyć oprogramowania wymienionego w pytaniu. =)
rakslice,
4
Inną przyczyną przekroczenia limitu może być agent ssh. ssh -vvpokazało próbowanie wielu wersji dwóch kluczy (dostarczonych przez ssh-agent). Zakładam, że jest to spowodowane rzadkim ponownym uruchamianiem komputera i zastępowaniem niektórych kluczy, które wygasły; najwyraźniej ssh-agent nie zastępuje starych kluczy nowymi. Zabiłem ssh-agent i problem zniknął.
Mark
Jaką wadą byłoby zwiększenie MaxAuthTries? Wątpię, aby wiele ataków przeprowadzano próbując wielu różnych kluczy. Poza tym, jeśli atakujący chce to zrobić, może po prostu zamknąć połączenie i otworzyć nowe za każdym razem, gdy osiągnie limit. I tak nie uda im się brutalnie wymusić klucza.
kasperd
@ Mark Dziękuję! Ponowne uruchomienie ssh-agent naprawiło to dla mnie!
winduptoy
90

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
Will Verna
źródło
1
Dziękuję bardzo! Używam tutaj Ubuntu Server, do którego mam dostęp tylko przez SSH. Ustawiłem „MaxAuthTries 1” po ślepym śledzeniu samouczka w Internecie.
Andre Figueiredo,
Właśnie uratowałeś mi życie! Nieużywanie klucza autoryzacji, więc inne odpowiedzi nie pomagały. To rozwiązało to bardzo łatwo !!
George Green
5
To odpowiedź
smac89
Po prostu ponownie skopiowałem swój klucz, używając uwierzytelniania hasłem, a teraz działa za każdym razem. W moim .sshkatalogu jest wiele kluczy , nie sądzę, że liczy się ich ilość.
Ken Sharp
Jest to najbardziej odpowiednia odpowiedź i naprawdę powinna być domyślnym zachowaniem dla ssh-copy-id, dlatego jeśli chcę skopiować mój identyfikator na serwer, zwykle nie ma go. Ale jeśli ssh spróbuje najpierw uwierzytelnić się na serwerze za pomocą klucza pub, serwer przerywa połączenie, zanim będzie mógł wprowadzić hasło.
Sprinterfreak
17

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.


źródło
W moim konkretnym przypadku problem polegał na tym, że zalogowałem się przy użyciu przekazywania agenta, próbując uruchomić skrypt wykorzystujący jego własną tożsamość SSH. Kiedy uruchomiłem to z przekazywaniem agentów, było zbyt wiele tożsamości, zanim spróbowałem swoich własnych. Skonfigurowałem więc skrypt, aby wyrzucił środowisko agenta i to go wyczyściło. Mógłbym również zwiększyć MaxAuthTries, ale nie musiałem w tym przypadku.
Sean Reifschneider,
1
Dzięki. -vpokazałem mojemu klientowi ssh, że próbuje użyć wielu kluczy (teraz mam ich całkiem sporo). Wyczyściłem je od agenta za pomocąssh-add -D
joeytwiddle
12

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.

Anonimowy
źródło
10

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.

Ninjaxor
źródło
6

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.

Gryzonie 43
źródło
5

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

Prabath Dolawatta
źródło
1
Nie bardzo nam zależy na odpowiedziach zawierających tylko linki, ponieważ linki gniją, a odpowiedź staje się bezużyteczna. Zachowaj link, na wszelki wypadek, ale jeśli możesz podsumować rozwiązanie w akapicie lub dwóch, możesz mieć tutaj dobrą odpowiedź.
MadHatter
2
Mam nadzieję, że wybaczysz mojej późniejszej edycji; teraz (mam nadzieję) wyjaśnia, że ​​rada, do której się odwołujesz, to rada, którą dajesz, ale nadal przypisuje oryginalne źródło. Daj ode mnie +1 za ciężkie próby poprawienia swojej odpowiedzi!
MadHatter
Miałem też problem z „Zbyt wieloma błędami uwierzytelnienia” w Putty. Po usunięciu wszystkich innych kluczy z PageAnt w końcu zalogowałem się pomyślnie.
klor
4

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

Sunil Shakya
źródło
3

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>
andyfeller
źródło
2

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.

Igor Stoppa
źródło
1

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.
tallbr00
źródło
0

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

Adam Witorean
źródło
0

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.

Poszkodowany
źródło
0

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

Fjor
źródło
-2

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

Rajnesh Thakur
źródło
To nie ma nic wspólnego z pytaniem.
Ken Sharp
-3

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

Arun Mathuria
źródło
-4

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.

Eskimo-Jbk
źródło
Ta odpowiedź nie jest przydatna, a zalecanie usuwania plików .ppk jest niebezpieczne. Proszę ludzi, jeśli uważasz, że musisz usunąć pliki .ppk (i nie mogę znaleźć dobrego powodu, dla którego chcesz), zmień ich nazwę na inną, nie usuwaj ich. Zawierają twoje klucze, których prawdopodobnie potrzebujesz.
Ustawa 29