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

Mam konto hostgator z włączonym dostępem ssh. Podczas próby przesłania wygenerowanego pliku klucza .pub za pomocą tego polecenia:

rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub username@111.222.33.44:.ssh/authorized_keys

Ciągle otrzymuję:

Otrzymano rozłączenie z 111.222.33.44: 2: Zbyt wiele błędów uwierzytelnienia dla nazwy użytkownika
rsync: połączenie niespodziewanie zamknięte (do tej pory odebrano 0 bajtów) [nadawca]
błąd rsync: niewyjaśniony błąd (kod 255) w io.c (601) [sender = 3.0.7]

Wcześniej bawiłem się ssh, dopóki nie dostałem awarii uwierzytelnienia. Ale teraz wydaje się, że licznik awarii uwierzytelniania nie resetuje się (czekał już ponad 12 godzin, wsparcie techniczne „zakłada”, że resetuje się po 30 minutach do 1 godziny, a inny facet powiedział mi „resetuje się za każdym razem, gdy próbujesz się zalogować nazwa użytkownika ”, jeesh).

To doprowadza mnie do szału. Miałem to nawet skonfigurowane na niestandardowym serwerze Slicehost i miałem mniej problemów niż z tymi facetami.

Jakieś wskazówki? Być może jest to coś po stronie klienta, a nie po stronie serwera.

Jest to zwykle spowodowane przypadkowym zaoferowaniem wielu kluczy ssh na serwerze. Serwer odrzuci dowolny klucz po zaoferowaniu zbyt wielu kluczy.

Możesz to zobaczyć, dodając -vflagę do sshpolecenia, aby uzyskać pełne wyjście. Zobaczysz, że oferuje się kilka kluczy, dopóki serwer nie odrzuci połączenia, mówiąc: „Zbyt wiele niepowodzeń uwierzytelniania dla [użytkownika]” . Bez trybu pełnego pojawi się niejednoznaczny komunikat „Resetowanie połączenia przez użytkownika” .

Aby zapobiec oferowaniu nieistotnych kluczy, musisz jawnie określić to w każdej pozycji hosta w ~/.ssh/configpliku (na komputerze klienta), dodając w ten IdentitiesOnlysposób:

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

Jeśli używasz ssh-agent, pomaga uruchomić, ssh-add -Daby wyczyścić tożsamości.

Jeśli nie używasz żadnej konfiguracji hostów ssh, musisz jawnie określić poprawny klucz w sshpoleceniu w następujący sposób:

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

Uwaga: parametr „IdentitiesOnly yes” musiał znajdować się między cudzysłowami.

lub

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

Znalazłem łatwiejszy sposób na zrobienie tego (jeśli używasz uwierzytelniania za pomocą hasła):

ssh -o PubkeyAuthentication=no username@hostname.com

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

Odniesienie

Otrzymywałem również ten błąd i stwierdziłem, że to się dzieje, ponieważ serwer skonfigurowano tak, aby akceptował maksymalnie 6 prób:

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

Oprócz ustawienia IdentitiesOnly yesw ~/.ssh/configpliku masz kilka innych opcji.

1. Zwiększ MaxAuthTries(na serwerze ssh)
2. usuń niektóre pary kluczy, które masz w swoim ~/.ssh/katalogu i uruchomssh-add -D
3. jawnie połącz klucz z danym hostem w swoim ~/.ssh/configpliku

Tak jak:

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

1. Prawdopodobnie nie jest to dobry sposób, aby to zrobić, ponieważ osłabia nieco twój serwer ssh, ponieważ akceptuje teraz więcej kluczy podczas danej próby połączenia. Pomyśl tutaj o wektorach ataku brutalnej siły.

2. To dobry sposób, aby założyć, że masz klucze, które nie są potrzebne i mogą zostać trwale usunięte.

3. Podejście do ustalania tożsamości jest prawdopodobnie preferowanym sposobem radzenia sobie z tym problemem!

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

Host *
IdentitiesOnly yes

Domyślnie włącza opcję IdentitiesOnly = yes. Jeśli będziesz musiał połączyć się z kluczem prywatnym, powinieneś podać go z opcją -i

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 katalogu .ssh i jeśli opcja „-i” nie jest 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ć).

Jeśli masz kilka kluczy prywatnych w swoim katalogu .ssh, możesz wyłączyć „Uwierzytelnianie klucza publicznego” w wierszu 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, aby się zalogować, oto jak to zrobić.

Aby użyć TYLKO uwierzytelnienia hasłem i NIE używać klucza publicznego, a NIE używać nieco wprowadzającej w błąd „interaktywnej klawiatury” (która jest nadzbiorem zawierającym hasło), możesz to zrobić z wiersza poleceń:

ssh -o PreferredAuthentications=password user@example.com

Po @David powiedz, po prostu dodaj to IdentitiesOnly yes do swojego .ssh / config, robi to samo cossh -o PubkeyAuthentication=no.

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

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no user@IP_ADDR 'cat >> .ssh/authorized_keys'. To powinno ponownie włączyć twój ssh z kluczem publicznym

Wiem, że to stary wątek, ale chciałem tylko dodać tutaj, że natrafiłem na ten sam komunikat o błędzie, ale było to spowodowane tym, że właściciel folderu .ssh jest rootem, a nie użytkownik, który używał klucza. Rozwiązałem problem, uruchamiając następujące polecenia:

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

Upewniłem się również, że uprawnienia są prawidłowe w folderze .ssh:

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 do katalogu. Naprawiłem to dla mnie:

$ chmod 750 ~;chmod 700 ~/.ssh

W moim przypadku tak się działo, ponieważ użyłem nazwy użytkownika „ubuntu”, ale nazwa użytkownika w tym przypadku to „ec2-user”

Po zrobieniu tego, co sugerował „John T”, otrzymałem ten błąd:

Odmowa dostępu (publickey).

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

Miałem swój klucz publiczny .ssh/authorized_keys2, ale serwer skonfigurowano 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 pliku do .ssh/authorized_keysmogę pomyślnie zalogować się za pomocą mojego klucza.

Zbyt wiele błędów uwierzytelnienia

Ten komunikat jest spowodowany zbyt dużą liczbą nieudanych prób uwierzytelnienia, biorąc pod uwagę dozwolone limity narzucone na zdalnym serwerze SSH. To potencjalnie oznacza, że ​​masz za dużo tożsamości dodanych w agencie SSH.

Oto kilka sugestii:

• Dodaj, -vaby zobaczyć, czy tak jest w przypadku (używasz zbyt wielu tożsamości).
• Wyświetl listę dodanych tożsamości według ssh-add -l.
• Usuń braku tożsamości ze środka przez: ssh-add -d.
• Możesz również usunąć wszystkie tożsamości ssh-add -Di ponownie dodać tylko jedną odpowiednią.

• Jeśli masz dostęp do serwera SSH, zaznacz MaxAuthTriesopcję (patrz man sshd_config:).

  ^{Temat pokrewny: Jakie jest powiązanie z sshd_configlimitem „MaxAuthTries”?}

• Jeśli to nie pomoże, upewnij się, że używasz odpowiednich poświadczeń lub pliku.

Ten komunikat 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