Zbyt wiele błędów uwierzytelniania dla *nazwy użytkownika*

Zazwyczaj jest to spowodowane przez niezamierzone oferowanie wielu kluczy ssh do serwera. Serwer odrzuci każdy klucz po zaoferowaniu zbyt wielu kluczy.

Możesz to zobaczyć sam, dodając flagę -v do swojej komendy ssh, aby uzyskać wyjście verbose. Zobaczysz, że oferowane są klucze do momentu, gdy serwer odrzuci polecenie połączenia: “Zbyt wiele błędów uwierzytelniania dla [użytkownika]”. Bez trybu verbose, zobaczysz tylko niejednoznaczną wiadomość “Połączenie zresetowane przez peer”.

Aby zapobiec oferowaniu nieistotnych kluczy, musisz to wyraźnie określić w każdym wpisie hosta w pliku ~/.ssh/config (na komputerze klienckim) dodając IdentitiesOnly jak:

Host www.somehost.com
  IdentityFile ~/.ssh/key_for_somehost_rsa
  IdentitiesOnly yes
  Port 22

Jeśli używasz ssh-agenta, pomaga to uruchomić ssh-add -D w celu wyczyszczenia tożsamości.

Jeśli nie używasz żadnych hostów ssh, musisz wyraźnie określić odpowiedni klucz w komendzie ssh jak:

ssh -i some_id_rsa -o 'IdentitiesOnly yes' them@there:/path/

Uwaga: parametr ‘IdentyfikacjeTylko tak’ musiał być pomiędzy cudzysłowami.

lub

ssh -i some_id_rsa -o IdentitiesOnly=yes them@there:/path/

Znalazłem łatwiejszy sposób, aby to zrobić (jeśli używasz uwierzytelniania hasłem):

ssh -o PubkeyAuthentication=no username@hostname.com

Wymusza to uwierzytelnianie bez klucza. Byłem w stanie zalogować się natychmiast. Odniesienie

Ja też dostałem ten błąd i stwierdziłem, że tak się dzieje b/c serwer został skonfigurowany tak, aby akceptować do 6 prób:

/etc/ssh/sshd_config
...
...
#MaxAuthTries 6

Oprócz ustawienia IdentitiesOnly yes w pliku ~/.ssh/config masz jeszcze kilka innych opcji.

1. Zwiększenie MaxAuthTries (na serwerze ssh)
2. usuń niektóre z par kluczy, które masz w swoim katalogu ~/.ssh/ i uruchom ssh-add -D
3. wyraźnie połącz klucz do danego hosta w swoim pliku ~/.ssh/config

W podobny sposób:

host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo

1. prawdopodobnie nie jest to dobry sposób, biorąc pod uwagę, że osłabia to nieco Twój serwer ssh, ponieważ będzie teraz akceptował więcej kluczy w danej próbie połączenia. Pomyśl o wektorach brutalnego ataku siłowego.

2. Jest to dobry sposób, aby przejść, zakładając, że masz klucze, które nie są potrzebne i mogą być trwale usunięte.

3. A podejście polegające na ustawieniu IdentityOnly jest prawdopodobnie preferowanym sposobem na rozwiązanie tego problemu!

Dodałem do ~/.ssh/config to:

Host *
IdentitiesOnly yes

Włącza opcję IdentityOnly=yes domyślnie. Jeśli będziesz potrzebował połączyć się z kluczem prywatnym, powinieneś określić go za pomocą opcji -i

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

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

To może się zdarzyć, jeśli masz (domyślnie w moim systemie) pięć lub więcej plików tożsamości DSA/RSA przechowywanych w katalogu .ssh i jeśli opcja ‘-i’ nie jest podana w wierszu poleceń.

Klient ssh najpierw spróbuje zalogować się przy użyciu każdej tożsamości (klucz prywatny), a następnie poprosi o uwierzytelnienie hasła. Jednakże sshd porzuca połączenie po pięciu błędnych próbach logowania (ponownie domyślnie może się różnić).

Jeśli masz kilka kluczy prywatnych w swoim katalogu .ssh, możesz wyłączyć opcję “Public Key Authentication” w linii poleceń używając opcjonalnego argumentu ‘-o’.

Na przykład:

$ ssh -o PubkeyAuthentication=no root@host

Jeśli masz hasło i chcesz po prostu użyć hasła do logowania, oto jak to robisz.

Aby używać TYLKO uwierzytelniania hasłem i NIE używać klucza publicznego, a NIE używać nieco mylącego “klawiatura-interaktywna” (który jest supersetem zawierającym hasło), możesz to zrobić z linii poleceń:

ssh -o PreferredAuthentications=password user@example.com

Wychodząc z @David mówiąc, po prostu dodaj to IdentitiesOnly yes do swojego .ssh/config, robi to samo co ssh -o PubkeyAuthentication=no.

Po zalogowaniu się, usuń .ssh/authorized_keys. Teraz, wróć do lokalnego komputera i wpisz następujące

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no user@IP_ADDR 'cat >> .ssh/authorized_keys'. To powinno umożliwić ponowne uruchomienie Twojego ssh za pomocą klucza publicznego

Wiem, że jest to stary wątek, ale chciałem tylko dodać tutaj, że wpadłem na ten sam komunikat o błędzie, ale został on spowodowany przez właściciela folderu .ssh będącego rootem, a nie przez użytkownika, który używał klucza. Poprawiłem błąd wykonując następujące komendy:

sudo chown -R user:user /home/user/.ssh

Upewniłem się również, że uprawnienia w katalogu .ssh były poprawne:

sudo chmod 700 /home/user/.ssh

Pliki w katalogu .ssh powinny mieć uprawnienia 600:

sudo chmod 600 /home/user/.ssh/authorized_keys

W moim przypadku, problemem były uprawnienia katalogowe. To naprawiło to dla mnie:

$ chmod 750 ~;chmod 700 ~/.ssh

To było dla mnie zabawne. Okazało się, że zmieniłem swoje hasło lokalnie, podczas gdy w trybie lokalizacji innym niż klawiatura, której używałem do zdalnego logowania. To skutecznie sprawiło, że moje hasło różniło się od tego, co myślałem, że to prawdopodobnie dlatego, że jeden z moich znaków specjalnych był inny od tego, co mówiła klawiatura.

Too many authentication failures

Ta wiadomość jest spowodowana zbyt dużą liczbą nieudanych prób uwierzytelnienia, biorąc pod uwagę dopuszczalne limity narzucone przez zdalny serwer SSH. Potencjalnie oznacza to, że masz zbyt wiele tożsamości dodanych do agenta SSH.

Oto kilka sugestii:

• Dodaj -v aby sprawdzić, czy tak jest (używasz zbyt wielu tożsamości).
• Lista dodanych tożsamości przez ssh-add -l.
• Usuń nieudaną tożsamość z agenta przez: ssh-add -d.
• Możesz również usunąć wszystkie tożsamości przez ssh-add -D i ponownie dodać tylko jedną odpowiednią.

• Jeśli masz dostęp do serwera SSH, zaznacz opcję MaxAuthTries (zobacz: man sshd_config ).

• Jeśli żadna z tych pomocy nie pomoże, upewnij się czy używasz właściwych danych uwierzytelniających lub pliku.

Miałem swój klucz publiczny w .ssh/authorized_keys2, ale serwer był skonfigurowany tylko do odczytu .ssh/authorized_keys:

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

Po przeniesieniu mojego pliku do .ssh/authorized_keys, mogę się zalogować z moim kluczem.

W moim przypadku działo się tak, ponieważ używałem nazwy użytkownika “ubuntu”, ale nazwa użytkownika w tym przypadku brzmiała “ec2-user”

Po tym jak zrobiłem to, co sugerował “John T”, dostałem ten błąd:

Permission denied (publickey).

Następnie znalazłem rozwiązanie (tzn. zmianę nazwy użytkownika na “ec2-user”) w tej odpowiedzi: https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue

Ta wiadomość może się pojawić, gdy nie zostanie wprowadzona poprawna nazwa użytkownika i hasło.

Najpierw sprawdź, czy użytkownik jest na liście:

vim /etc/passwd