☰

Zu viele Authentifizierungsfehler für *Benutzername*

tag-icon • tag-icon ssh certificate authentication
Zu viele Authentifizierungsfehler für *Benutzername*

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

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

Ich erhalte ständig die Meldung:

Trennung von 111.222.33.44 empfangen: 2: Zu viele Authentifizierungsfehler für Benutzernamen
rsync: Verbindung unerwartet geschlossen (bisher 0 Bytes empfangen) [Absender]
rsync-Fehler: unerklärlicher Fehler (Code 255) bei io.c(601) [sender=3.0.7]

Ich habe vorher mit SSH herumgespielt, bis ich den Authentifizierungsfehler bekam. Aber jetzt scheint es, dass der Authentifizierungsfehlerzähler nicht zurückgesetzt wird (ich warte jetzt schon mehr als 12 Stunden, der technische Support „nimmt an“, dass er nach 30 Minuten bis 1 Stunde zurückgesetzt wird, und ein anderer Typ sagte mir, „er wird jedes Mal zurückgesetzt, wenn Sie versuchen, sich mit dem Benutzernamen anzumelden“, meine Güte).

Das macht mich wahnsinnig. Ich habe das sogar auf einem benutzerdefinierten Slicehost-Server eingerichtet und hatte weniger Probleme als mit diesen Jungs.

Irgendwelche Tipps? Vielleicht liegt es an der Clientseite und nicht an der Serverseite.

Antwort1

Dies ist normalerweiseverursacht durch versehentliches Anbieten mehrerer SSH-Schlüsselan den Server. Der Server lehnt jeden Schlüssel ab, wenn zu viele Schlüssel angeboten wurden.

Sie können dies selbst überprüfen, indem Sie -vIhrem sshBefehl das Flag hinzufügen, um eine ausführliche Ausgabe zu erhalten. Sie werden sehen, dass eine Reihe von Schlüsseln angeboten werden, bis der Server die Verbindung mit folgender Aussage ablehnt:„Zu viele Authentifizierungsfehler für [Benutzer]“Ohne den ausführlichen Modus sehen Sie nur die mehrdeutige Meldung"Verbindung von Peer zurückgesetzt".

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

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

Wenn Sie den SSH-Agenten verwenden, ist es hilfreich, ihn auszuführen, ssh-add -Dum die Identitäten zu löschen.

Wenn Sie keine SSH-Hostkonfiguration verwenden, müssen Sie den richtigen Schlüssel im sshBefehl explizit angeben, und zwar wie folgt:

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

Hinweis: Der Parameter „IdentitiesOnly yes“ muss in Anführungszeichen stehen.

oder

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

Antwort2

Ich habe einen einfacheren Weg gefunden, dies zu tun (bei Verwendung der Kennwortauthentifizierung):

ssh -o PubkeyAuthentication=no [email protected]

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

Referenz

Antwort3

Ich habe diesen Fehler auch erhalten und festgestellt, dass er auftrat, weil der Server so konfiguriert war, dass er bis zu 6 Versuche zuließ:

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

Zusätzlich zum Festlegen IdentitiesOnly yesin Ihrer ~/.ssh/configDatei stehen Ihnen noch einige weitere Optionen zur Verfügung.

  1. Erhöhen Sie die MaxAuthTries(auf dem SSH-Server)
  2. Löschen Sie einige der Schlüsselpaare, die Sie in Ihrem ~/.ssh/Verzeichnis haben und führen Siessh-add -D
  3. Verknüpfen Sie einen Schlüssel explizit mit einem bestimmten Host in Ihrer ~/.ssh/configDatei

So:

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

  1. Dies ist wahrscheinlich keine gute Vorgehensweise, da es Ihren SSH-Server etwas schwächt, da er nun bei einem bestimmten Verbindungsversuch mehr Schlüssel akzeptiert. Denken Sie hier an Brute-Force-Angriffsvektoren.

  2. Dies ist eine gute Vorgehensweise, vorausgesetzt, Sie haben Schlüssel, die nicht benötigt werden und dauerhaft gelöscht werden können.

  3. Und der Ansatz zum Festlegen von IdentitiesOnly ist wahrscheinlich die bevorzugte Methode zum Umgang mit diesem Problem!

Antwort4

Wenn Sie den folgenden SSH-Fehler erhalten:

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

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

Der SSH-Client versucht zunächst, sich mit jeder Identität (privater Schlüssel) anzumelden und fordert dann zur Kennwortauthentifizierung auf. Allerdings trennt SSHD die Verbindung nach fünf fehlgeschlagenen Anmeldeversuchen (auch hier kann der Standardwert abweichen).

Wenn Sie mehrere private Schlüssel in Ihrem .ssh-Verzeichnis haben, können Sie die „Public Key Authentication“ in der Befehlszeile mit dem optionalen Argument „-o“ deaktivieren.

Zum Beispiel:

$ ssh -o PubkeyAuthentication=no root@host

verwandte Informationen