it-swarm.com.de

Zu viele Authentifizierungsfehler für * Benutzername *

Ich habe ein Hostgator-Konto mit aktiviertem SSH-Zugriff und beim Versuch, die generierte .pub-Schlüsseldatei mit folgendem Befehl hochzuladen:

 rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub [email protected]: .ssh/authorized_keys 

Ich bekomme immer:

 Verbindungstrennung von 111.222.33.44 erhalten: 2: Zu viele Authentifizierungsfehler für Benutzername 
 Rsync: Verbindung unerwartet geschlossen (0 Byte bisher empfangen) [Absender] 
 Rsync-Fehler: unerklärlicher Fehler (Code 255) bei io.c (601) [Absender = 3.0.7] 

Ich habe vorher mit ssh rumgespielt, bis ich den Auth-Fehler bekam. Aber jetzt scheint, dass der Auth-Fehlerzähler nicht zurückgesetzt wird (ich habe jetzt mehr als 12 Stunden gewartet, der technische Support "vermutet", dass er nach 30 Minuten auf 1 Stunde zurückgesetzt wird, und ein anderer Typ sagte mir, dass er jedes Mal zurückgesetzt wird, wenn Sie versuchen, sich mit dem anzumelden Benutzername ", jeesh).

Das macht mich verrückt. Ich hatte dies sogar in einem benutzerdefinierten Slicehost-Server eingerichtet und hatte weniger Probleme als mit diesen Jungs. Irgendein Tipp? Vielleicht ist es etwas Client-Seite und nicht Server-Seite.

248

Dies wird normalerweise verursacht durch das versehentliche Anbieten mehrerer SSH-Schlüssel zum Server. Der Server weist jeden Schlüssel zurück, nachdem zu viele Schlüssel angeboten wurden.

Sie können sich davon überzeugen, indem Sie das Flag -v zu Ihrem Befehl ssh hinzufügen, um eine ausführliche Ausgabe zu erhalten. Sie werden feststellen, dass eine Reihe von Schlüsseln angeboten werden, bis der Server die Verbindung mit den Worten "" Zu viele Authentifizierungsfehler für [Benutzer] "zurückweist. Ohne ausführlichen Modus wird nur die mehrdeutige Meldung "Verbindung von Peer zurückgesetzt" angezeigt.

Um zu verhindern, dass irrelevante Schlüssel angeboten werden, müssen Sie dies in jedem Host-Eintrag in der Datei ~/.ssh/config (auf dem Client-Computer) explizit angeben, indem Sie IdentitiesOnly wie folgt hinzufügen:

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

Wenn Sie den ssh-agent verwenden, ist es hilfreich, ssh-add -D auszuführen, um die Identitäten zu löschen.

Wenn Sie keine ssh-Hosts-Konfiguration verwenden, müssen Sie den richtigen Schlüssel im Befehl ssh wie folgt explizit angeben:

ssh -i some_id_rsa -o 'IdentitiesOnly yes' [email protected]:/path/

Hinweis: Der Parameter 'IdentitiesOnly yes' muss zwischen Anführungszeichen stehen.

oder

ssh -i some_id_rsa -o IdentitiesOnly=yes [email protected]:/path/
406
John T

Ich habe einen einfacheren Weg gefunden, dies zu tun (wenn ich eine Passwortauthentifizierung verwende):

ssh -o PubkeyAuthentication=no [email protected]

Dies erzwingt die Authentifizierung ohne Schlüssel. Ich konnte mich sofort anmelden.

Referenz

179
Ben West

Ich habe auch diesen Fehler erhalten und festgestellt, dass er aufgetreten ist, da der Server so konfiguriert wurde, dass er bis zu 6 Versuche akzeptiert:

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

Zusätzlich zum Festlegen des IdentitiesOnly yes in Ihrer ~/.ssh/config-Datei stehen Ihnen einige weitere Optionen zur Verfügung.

  1. Erhöhen Sie die MaxAuthTries (auf dem SSH-Server)
  2. lösche einige der Schlüsselpaare, die du in deinem ~/.ssh/ Verzeichnis hast & führe ssh-add -D aus
  3. verknüpfen Sie einen Schlüssel explizit mit einem bestimmten Host in Ihrer ~/.ssh/config-Datei

Wie so:

Host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo
  1. Dies ist wahrscheinlich kein guter Weg, da der SSH-Server dadurch etwas geschwächt wird, da er jetzt bei einem bestimmten Verbindungsversuch mehr Schlüssel akzeptiert. Denken Sie hier an Brute-Force-Angriffsvektoren.

  2. Ist ein guter Weg, vorausgesetzt, Sie haben Schlüssel, die nicht benötigt werden und dauerhaft gelöscht werden können.

  3. Und der Ansatz, IdentitiesOnly festzulegen, ist wahrscheinlich die bevorzugte Art, mit diesem Problem umzugehen!

24
slm

Ich habe zu ~/.ssh/config folgendes hinzugefügt:

Host *
IdentitiesOnly yes

Standardmäßig ist die Option IdentitiesOnly = yes aktiviert. Wenn Sie eine Verbindung mit einem privaten Schlüssel herstellen müssen, geben Sie dies mit der Option -i an

Wenn Sie ein Passwort haben und sich einfach mit diesem Passwort anmelden möchten, gehen Sie wie folgt vor.

Um NUR die Kennwortauthentifizierung und NICHT den öffentlichen Schlüssel zu verwenden und NICHT den etwas irreführenden "keyboard-interactive" (der eine Obermenge einschließlich des Kennworts ist) zu verwenden, können Sie dies über die Befehlszeile tun:

ssh -o PreferredAuthentications=password [email protected]
6
Greg Rundlett

Wenn Sie den folgenden SSH-Fehler erhalten:

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

Dies kann passieren, wenn Sie (standardmäßig auf meinem System) fünf oder mehr DSA/RSA-Identitätsdateien in Ihrem .ssh-Verzeichnis gespeichert haben und die Option '-i' in der Befehlszeile nicht angegeben ist.

Der ssh-Client versucht zunächst, sich mit jeder Identität (privatem Schlüssel) anzumelden, und fordert dann zur Kennwortauthentifizierung auf. Sshd trennt die Verbindung jedoch nach fünf fehlerhaften Anmeldeversuchen (die Standardeinstellung kann ebenfalls variieren).

Wenn Sie eine Reihe von privaten Schlüsseln in Ihrem .ssh-Verzeichnis haben, können Sie "Public Key Authentication" in der Befehlszeile mit dem optionalen Argument "-o" deaktivieren.

Zum Beispiel:

$ ssh -o PubkeyAuthentication=no [email protected]
5
Will Verna

Wenn Sie @David loslassen und sagen, fügen Sie einfach diesen IdentitiesOnly yes zu Ihrer .ssh/config hinzu, er macht das Gleiche wie ssh -o PubkeyAuthentication=no.

Nachdem Sie sich angemeldet haben, entfernen Sie .ssh/authorized_keys. Kehren Sie nun zum lokalen Computer zurück und geben Sie Folgendes ein

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no [email protected]_ADDR 'cat >> .ssh/authorized_keys'. Dies sollte Ihr ssh mit öffentlichem Schlüssel wieder aktivieren

3
Alan Dong

Ich weiß, dass dies ein alter Thread ist, aber ich wollte hier nur hinzufügen, dass ich dieselbe Fehlermeldung erhalten habe, die jedoch darauf zurückzuführen ist, dass der Besitzer des .ssh-Ordners root ist und nicht der Benutzer, der den Schlüssel verwendet. Ich habe das Problem behoben, indem ich die folgenden Befehle ausgeführt habe:

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

Ich habe auch sichergestellt, dass die Berechtigungen für den Ordner .ssh korrekt sind:

Sudo chmod 700 /home/user/.ssh

Die Dateien im Verzeichnis .ssh sollten die Berechtigung 600 haben:

Sudo chmod 600 /home/user/.ssh/authorized_keys
2
Adam

In meinem Fall war das Problem Verzeichnisberechtigungen. Das hat es für mich behoben:

$ chmod 750 ~;chmod 700 ~/.ssh
1
tbc0

In meinem Fall geschah dies, weil ich den Benutzernamen "ubuntu" verwendete, der Benutzername in diesem Fall jedoch "ec2-user" war.

Nachdem ich getan habe, was "John T" vorgeschlagen hat, habe ich folgenden Fehler erhalten:

Erlaubnis verweigert (publickey).

Dann fand ich die Lösung (d. H. Ändern des Benutzernamens in "ec2-user") in dieser Antwort: https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue

0
Deepak Joy

Zu viele Authentifizierungsfehler

Diese Nachricht wird durch zu viele fehlgeschlagene Authentifizierungsversuche verursacht, wenn die zulässigen Grenzwerte auf dem Remote-SSH-Server eingehalten werden. Dies bedeutet möglicherweise, dass dem SSH-Agenten zu viele Identitäten hinzugefügt wurden.

Hier sind einige Vorschläge:

  • Fügen Sie -v hinzu, um festzustellen, ob dies der Fall ist (Sie haben zu viele Identitäten verwendet).
  • Listet hinzugefügte Identitäten nach ssh-add -l auf.
  • Entfernen Sie die fehlgeschlagene Identität vom Agenten durch: ssh-add -d.
  • Sie können auch alle Identitäten durch ssh-add -D löschen und nur eine relevante hinzufügen.
  • Wenn Sie Zugriff auf den SSH-Server haben, aktivieren Sie die Option MaxAuthTries (siehe: man sshd_config ).

    In Verbindung stehender Beitrag: Was ist eine Verbindung für das 'MaxAuthTries'-Limit von sshd_config?

  • Wenn dies nicht hilft, stellen Sie sicher, dass Sie die richtigen Anmeldeinformationen oder Dateien verwenden.

0
kenorb

Ich hatte meinen öffentlichen Schlüssel in .ssh/authorized_keys2, aber der Server war so konfiguriert, dass nur .ssh/authorized_keys gelesen werden kann:

# 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

Nachdem ich meine Datei nach .ssh/authorized_keys verschoben habe, kann ich mich erfolgreich mit meinem Schlüssel anmelden.

0