Zu viele Authentifizierungsfehler für *Benutzername*

Dies wird normalerweise verursacht, indem dem Server versehentlich mehrere ssh-Schlüssel angeboten werden. Der Server lehnt jeden Schlüssel ab, nachdem zu viele Schlüssel angeboten wurden.

Sie können sich selbst davon überzeugen, indem Sie das Flag -v zu Ihrem Befehl ssh hinzufügen, um eine ausführliche Ausgabe zu erhalten. Sie werden sehen, dass ein Bündel von Schlüsseln angeboten wird, bis der Server die Verbindung mit den Worten ablehnt: “Zu viele Authentifizierungsfehler für [Benutzer]”. Ohne den ausführlichen Modus sehen Sie nur die zweideutige Meldung “Verbindung von der Gegenstelle zurückgesetzt”.

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-Rechner) 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, hilft es, ssh-add -D auszuführen, um die Identitäten zu löschen.

Wenn Sie keine ssh-Host-Konfiguration verwenden, müssen Sie explizit den korrekten Schlüssel im Befehl ssh angeben, z.B. so:

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 (bei Verwendung der Kennwortauthentifizierung):

ssh -o PubkeyAuthentication=no username@hostname.com

Dies erzwingt eine Nicht-Schlüssel-Authentifizierung. Ich konnte mich sofort anmelden: Verweis

Ich bekam auch diesen Fehler und fand heraus, daß es b/c passierte, weil der Server so konfiguriert war, daß er bis zu 6 Versuche akzeptiert:

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

Zusätzlich zur Einstellung von IdentitiesOnly yes in Ihrer ~/.ssh/config-Datei haben Sie noch einige andere Optionen.

1. erhöhen Sie die MaxAuthTries (auf dem ssh-Server)
2. löschen Sie einige der Schlüsselpaare, die Sie in Ihrem Verzeichnis ~/.ssh/ haben, und führen Sie ssh-add -D aus 3. verknüpfen Sie einen Schlüssel explizit mit einem bestimmten Host in Ihrer Datei ~/.ssh/config

Wie folgt:

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

1. ist wahrscheinlich kein guter Weg, dies zu tun, da es Ihren ssh-Server ein wenig schwächt, da er nun mehr Schlüssel bei einem bestimmten Verbindungsversuch 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 zu setzen, sind wahrscheinlich die bevorzugten Wege, mit diesem Problem umzugehen!

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

Host *
IdentitiesOnly yes

Es aktiviert standardmäßig die Option IdentitiesOnly=yes. Wenn Sie sich mit einem privaten Schlüssel verbinden müssen, sollten Sie ihn mit der Option -i angeben

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 wenn die Option ‘-i’ nicht auf der Kommandozeile angegeben ist.

Der ssh-Client versucht zunächst, sich mit jeder Identität (privater Schlüssel) anzumelden, und fragt dann nach der Passwort-Authentifizierung. Allerdings bricht sshd die Verbindung nach fünf fehlerhaften Anmeldeversuchen ab (auch hier kann die Vorgabe variieren).

Wenn Sie eine Anzahl privater Schlüssel in Ihrem .ssh-Verzeichnis haben, können Sie “Public Key Authentication” an 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 Passwort-Authentifizierung zu verwenden und NICHT den öffentlichen Schlüssel und NICHT die etwas irreführende “Tastatur-interaktive” (die eine Obermenge einschließlich Passwort ist) zu verwenden, können Sie dies von der Befehlszeile aus tun:

ssh -o PreferredAuthentications=password user@example.com

Wenn David sagt: “Fügen Sie einfach IdentitiesOnly yes zu Ihrer .ssh/config hinzu, es macht dasselbe wie ssh -o PubkeyAuthentication=no.

Nachdem Sie sich angemeldet haben, entfernen Sie .ssh/authorized_keys. Gehen Sie nun zurück zum lokalen Rechner 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 auf die gleiche Fehlermeldung gestoßen bin, aber sie wurde dadurch verursacht, dass der Besitzer des .ssh-Ordners Root war und nicht der Benutzer, der den Schlüssel verwendet hat. Ich habe das Problem durch Ausführen der folgenden Befehle behoben:

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

Ich habe auch sichergestellt, dass die Berechtigungen im .ssh-Ordner korrekt waren:

sudo chmod 700 /home/user/.ssh

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

sudo chmod 600 /home/user/.ssh/authorized_keys

In meinem Fall lag das Problem bei den Verzeichnisberechtigungen. Dies hat es für mich behoben:

$ chmod 750 ~;chmod 700 ~/.ssh

Das war ein Spaß für mich. Es stellte sich heraus, dass ich mein Passwort lokal geändert habe, während ich mich in einem anderen Lokalisierungsmodus befand als auf einer Tastatur, die ich zur Fernanmeldung benutzte. Dadurch unterschied sich mein Passwort effektiv von dem, was ich dachte, wahrscheinlich deshalb, weil eines meiner Sonderzeichen nicht mit dem übereinstimmte, was auf der Tastatur stand.

Zu viele Authentifizierungsfehler

Diese Meldung wird durch zu viele fehlgeschlagene Authentifizierungsversuche angesichts der auf dem entfernten SSH-Server erzwungenen zulässigen Grenzen verursacht. Dies bedeutet möglicherweise, dass Sie zu viele Identitäten im SSH-Agenten hinzugefügt haben.

Hier sind einige Vorschläge:

• Fügen Sie -v hinzu, um zu sehen, ob dies der Fall ist (Sie haben zu viele Identitäten verwendet).
• Listen Sie hinzugefügte Identitäten auf bis: ssh-add -l.
• Sie können auch alle Identitäten durch ssh-add -d löschen und nur eine relevante neu hinzufügen.

• Wenn Sie Zugriff auf den SSH-Server haben, markieren Sie die Option ssh-add -D (siehe: MaxAuthTries ).

• Wenn nichts davon hilft, stellen Sie sicher, ob Sie die richtigen Anmeldedaten oder die richtige Datei verwenden.

Ich hatte meinen öffentlichen Schlüssel in .ssh/authorized_keys2, aber der Server war so konfiguriert, dass er nur lesen 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 .ssh/authorized_keys verschoben habe, kann ich mich erfolgreich mit meinem Schlüssel anmelden.

In meinem Fall geschah es, weil ich den Benutzernamen “ubuntu” benutzte, aber der Benutzername war in diesem Fall “ec2-user”

Nachdem ich getan hatte, was “John T” vorschlug, bekam ich diesen Fehler:

Erlaubnis verweigert (publickey).

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

Diese Meldung kann erscheinen, wenn der korrekte Benutzername und das Kennwort nicht eingegeben wurden.

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

vim /etc/passwd