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 [email protected]:.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.
ssh
authentication
Gabriel A. Zorrilla
źródło
źródło
Odpowiedzi:
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
-v
flagę dossh
polecenia, 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/config
pliku (na komputerze klienta), dodając w tenIdentitiesOnly
sposób:Jeśli używasz ssh-agent, pomaga uruchomić,
ssh-add -D
aby wyczyścić tożsamości.Jeśli nie używasz żadnej konfiguracji hostów ssh, musisz jawnie określić poprawny klucz w
ssh
poleceniu w następujący sposób:Uwaga: parametr „IdentitiesOnly yes” musiał znajdować się między cudzysłowami.
lub
źródło
ssh -i some_id_rsa -o "IdentitiesOnly yes" them@there:/path/
ssh
„oferuje wiele kluczy” (cokolwiek poniżej~/.ssh
), nawet jeśli reguła dla hosta ma jawneIdentityFile /path/to/private_key_file
ustawienie. Czy ten wyraźnie określony klucz nie powinien być (przynajmniej) oferowany jako pierwszy? Czy to nie jest błąd / błąd w kliencie openssh?IdentityFile
opcji? Na przykład bez tejIdentitiesOnly
opcji próbuje użyć mojegogithub
klucza, gdy próbujęssh gitlab.com
. To nie ma sensu.Znalazłem łatwiejszy sposób na zrobienie tego (jeśli używasz uwierzytelniania za pomocą hasła):
Wymusza to uwierzytelnianie bez klucza. Byłem w stanie zalogować się natychmiast.
Odniesienie
źródło
rsync
:rsync -av -e 'ssh -o PubkeyAuthentication=no' '[email protected]:~/remote_file' 'local_file'
Otrzymywałem również ten błąd i stwierdziłem, że to się dzieje, ponieważ serwer skonfigurowano tak, aby akceptował maksymalnie 6 prób:
Oprócz ustawienia
IdentitiesOnly yes
w~/.ssh/config
pliku masz kilka innych opcji.MaxAuthTries
(na serwerze ssh)~/.ssh/
katalogu i uruchomssh-add -D
~/.ssh/config
plikuTak jak:
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.
To dobry sposób, aby założyć, że masz klucze, które nie są potrzebne i mogą zostać trwale usunięte.
Podejście do ustalania tożsamości jest prawdopodobnie preferowanym sposobem radzenia sobie z tym problemem!
źródło
Dodałem do ~ / .ssh / config to:
Domyślnie włącza opcję IdentitiesOnly = yes. Jeśli będziesz musiał połączyć się z kluczem prywatnym, powinieneś podać go z opcją -i
źródło
Jeśli pojawi się następujący błąd SSH:
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:
źródło
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ń:
źródło
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 poleceniecat ~/.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źródło
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:
Upewniłem się również, że uprawnienia są prawidłowe w folderze .ssh:
Pliki w katalogu .ssh powinny mieć uprawnienia 600:
źródło
W moim przypadku problemem były uprawnienia do katalogu. Naprawiłem to dla mnie:
źródło
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:
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
źródło
Miałem swój klucz publiczny
.ssh/authorized_keys2
, ale serwer skonfigurowano tylko do odczytu.ssh/authorized_keys
:Po przeniesieniu pliku do
.ssh/authorized_keys
mogę pomyślnie zalogować się za pomocą mojego klucza.źródło
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:
-v
aby zobaczyć, czy tak jest w przypadku (używasz zbyt wielu tożsamości).ssh-add -l
.ssh-add -d
.ssh-add -D
i ponownie dodać tylko jedną odpowiednią.Jeśli masz dostęp do serwera SSH, zaznacz
MaxAuthTries
opcję (patrzman sshd_config
:).Temat pokrewny: Jakie jest powiązanie z
sshd_config
limitem „MaxAuthTries”?Jeśli to nie pomoże, upewnij się, że używasz odpowiednich poświadczeń lub pliku.
źródło
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:
źródło