Zu viele Authentifizierungsfehler für * Benutzername *

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

rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub username@111.222.33.44:.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 Bytes bisher empfangen) [Absender]
rsync error: unerklärlicher Fehler (Code 255) bei io.c (601) [sender = 3.0.7]

Ich habe vorher mit ssh rumgespielt, bis ich den Auth-Fehler bekam. Aber jetzt scheint es, dass der Auth-Fehlerzähler nicht zurückgesetzt wird (ich habe 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 anzumelden den Benutzernamen ", jeesh).

Das macht mich verrückt. Ich hatte dies sogar in einem benutzerdefinierten Slicehost-Server eingerichtet und hatte weniger Probleme als mit diesen Jungs.

Irgendwelche Tipps? Vielleicht ist es etwas Client-Seite und nicht Server-Seite.

Dies wird normalerweise dadurch verursacht , dass dem Server versehentlich mehrere SSH-Schlüssel angeboten werden. Der Server weist jeden Schlüssel zurück, nachdem zu viele Schlüssel angeboten wurden.

Sie können sich davon überzeugen, indem Sie -vIhrem sshBefehl das Flag 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]" ablehnt . 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 ~/.ssh/config(auf dem Client-Computer) -Datei explizit angeben, indem Sie Folgendes hinzufügen IdentitiesOnly:

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

Wenn Sie den ssh-agent verwenden, hilft ssh-add -Des, die Identitäten zu löschen.

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

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

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

oder

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

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

ssh -o PubkeyAuthentication=no username@hostname.com

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

Referenz

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

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

Zusätzlich zum Festlegen der IdentitiesOnly yesin Ihrer ~/.ssh/configDatei haben Sie ein paar andere Optionen.

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

Wie so:

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

1. Dies ist wahrscheinlich kein guter Weg, da Ihr 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. Dies ist eine gute Möglichkeit, 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!

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 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 root@host

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-interactiven" (der eine Obermenge einschließlich des Kennworts ist) zu verwenden, können Sie dies über die Befehlszeile tun:

ssh -o PreferredAuthentications=password user@example.com

Wenn Sie @David loslassen und sagen, fügen Sie dies einfach IdentitiesOnly yes zu Ihrer .ssh / config hinzu, es macht dasselbe wiessh -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 user@IP_ADDR 'cat >> .ssh/authorized_keys'. Dies sollte Ihr ssh mit öffentlichem Schlüssel wieder aktivieren

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

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

$ chmod 750 ~;chmod 700 ~/.ssh

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 (dh Ändern des Benutzernamens in "ec2-user") in dieser Antwort: https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue

Ich hatte meinen öffentlichen Schlüssel eingegeben .ssh/authorized_keys2, aber der Server war so konfiguriert, dass er nur gelesen werden kann .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

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

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 dies hinzu -v, um festzustellen , ob dies der Fall ist (Sie haben zu viele Identitäten verwendet).
• Listet hinzugefügte Identitäten nach auf ssh-add -l.
• Entfernen Sie von dem Agenten Fehler Identität durch: ssh-add -d.
• Sie können auch alle Identitäten durch löschen ssh-add -Dund nur eine relevante erneut hinzufügen.

• Wenn Sie Zugriff auf den SSH-Server haben, aktivieren Sie die MaxAuthTriesOption (siehe:) man sshd_config.

  ^{In Verbindung stehender Beitrag: Was ist eine Verbindung für sshd_config's' MaxAuthTries'-Limit?}

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

Diese Meldung kann angezeigt werden, wenn der richtige Benutzername und das richtige Passwort nicht eingegeben wurden.

Überprüfen Sie zunächst, ob der Benutzer aufgelistet ist:

vim /etc/passwd