Frage Zu viele Authentifizierungsfehler für * Benutzername *


Ich habe ein Hostgator-Konto mit ssh-Zugriff aktiviert und beim Versuch, die generierte .pub-Schlüsseldatei mit diesem Befehl hochzuladen:

rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub benutzername@111.222.33.44: .ssh / authorized_keys

Ich bekomme immer wieder:

Erhaltene Trennung von 111.222.33.44: 2: Zu viele Authentifizierungsfehler für Benutzername
rsync: Verbindung unerwartet geschlossen (bisher 0 Bytes) [Absender]
rsync error: ungeklärter Fehler (Code 255) bei io.c (601) [sender = 3.0.7]

Ich habe vorher mit ssh gespielt, bis ich den Auth-Fehler bekam. Aber jetzt scheint der auth failure counter nicht zurückgesetzt (warte mehr als 12 Stunden jetzt, Tech Support "angenommen" es nach 30 min auf 1 Stunde zurückgesetzt, und ein anderer Typ sagte mir, "es setzt jedes Mal, wenn Sie versuchen, mit der Anmeldung Benutzername ", jeesh).

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


223
2017-09-12 17:14


Ursprung




Antworten:


Das ist normalerweise verursacht durch unbeabsichtigtes Anbieten mehrerer ssh-Schlüssel zum Server. Der Server wird jeden Schlüssel ablehnen, nachdem zu viele Schlüssel angeboten wurden.

Sie können dies selbst sehen, indem Sie das hinzufügen -v Flagge zu deinem ssh Befehl, um eine ausführliche Ausgabe zu erhalten. Sie werden feststellen, dass eine Reihe von Schlüsseln angeboten werden, bis der Server die Verbindung ablehnt und sagt: "Zu viele Authentifizierungsfehler für [Benutzer]". Ohne den ausführlichen Modus sehen Sie nur die mehrdeutige Nachricht "Verbindung von Peer zurückgesetzt".

Um zu verhindern, dass irrelevante Schlüssel angeboten werden, müssen Sie dies explizit in jedem Host - Eintrag in der ~/.ssh/config (auf der Client-Maschine) Datei durch Hinzufügen IdentitiesOnly so:

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

Wenn Sie den ssh-agent verwenden, hilft es zu laufen ssh-add -D um die Identitäten zu löschen.

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

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/

359
2017-09-12 17:53



Es ist mir nicht klar, wo ich diese Zeile setzen soll. Auf dem Server, auf dem ich mich anmelde, hat .ssh / config nur Informationen für andere Server. Meinst du, dass das in der .ssh / config-Datei auf dem Computer gehen sollte, von dem ich versuche, ssh? Wenn dies der Fall ist, ist dies unklar, da Ihre Antwort "sobald Sie wieder eingeloggt sind" lautet. - David LeBauer
Ich muss die Option in doppelte Anführungszeichen setzen: ssh -i some_id_rsa -o "IdentitiesOnly yes" them@there:/path/ - knb
Windows-Benutzer, die PAGENT (Putty Agent) ausführen, überprüfen, ob Sie nur die benötigten Schlüssel geladen haben. Ich bin auf dieses Problem gestoßen, nachdem ich ALLE meine privaten Schlüssel versehentlich geladen habe. - Chris Rasco
Jedoch für sshfs (fuse) Ich muss die Option mit einem obligatorischen Gleichheitszeichen wie folgt schreiben: sshfs -o "IdentitiesOnly=yes" -o IdentityFile=~/.ssh/id_dsa them@there/var/tmp /mnt/tmp  (Ubuntu 13.10) - knb
Es kann ohne Anführungszeichen wie folgt verwendet werden: -o IdentitiesOnly=yes - Valentin Kantor


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

ssh -o PubkeyAuthentication=no username@hostname.com

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

Referenz


159
2018-03-25 00:14



+1, ich wünschte, ich könnte dir mehr geben. Raspberry Pi ist das einzige Gerät, in das ich ohne öffentlichen Schlüssel schalte. Wurde erhalten: "Zu viele Authentifizierungsfehler für Pi" - blak3r
Und das mit zu benutzen rsync: rsync -av -e 'ssh -o PubkeyAuthentication=no' 'user@host.com:~/remote_file' 'local_file' - Ciro Santilli 新疆改造中心 六四事件 法轮功
Sie können auch einen Alias ​​erstellen, um die Passwortauthentifizierung noch schneller zu machen. Alias ​​sshp = 'ssh -o PubkeyAuthentication = Nein' - dhempler


Ich habe diesen Fehler auch bekommen und festgestellt, dass es passiert b / c der Server wurde konfiguriert, um bis zu 6 Versuche zu akzeptieren:

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

Zusätzlich zum Einstellen der IdentitiesOnly yes in deinem ~/.ssh/config Datei Sie haben ein paar andere Optionen.

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

Wie so:

host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo
  1. Ist wahrscheinlich nicht ein guter Weg, um es zu tun, da es Ihren ssh-Server ein wenig schwächt, da es jetzt mehr Schlüssel in einem bestimmten Verbindungsversuch akzeptiert. Denken Sie Brute-Force-Angriffsvektoren hier.

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

  3. Und der Ansatz, IdentitiesOnly zu setzen, ist wahrscheinlich der bevorzugte Weg, um mit diesem Problem umzugehen!


24
2018-06-09 04:56



In Ihrer letzten Zeile haben Sie die Datei /home/YOU/.ssh/foo, aber es sollte identityfile sein (a t nicht an f) - Nin
@Nin - danke, behoben. - slm


Wenn Sie ein Passwort haben und einfach das Passwort zum Einloggen verwenden möchten, hier ist, wie Sie es tun.

Um NUR die Kennwortauthentifizierung zu verwenden und NICHT den öffentlichen Schlüssel zu verwenden, und NICHT die etwas irreführende "Tastatur-interaktiv" verwenden (was eine Obermenge inklusive Passwort ist), können Sie dies über die Befehlszeile tun:

ssh -o PreferredAuthentications=password user@example.com

6
2018-06-19 14:22





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 wenn die Option '-i' nicht in der Befehlszeile angegeben ist.

Der ssh-Client versucht zunächst, sich mit jeder Identität (privater Schlüssel) und der nächsten Aufforderung zur Kennwortauthentifizierung anzumelden. Sshd löscht jedoch die Verbindung nach fünf fehlerhaften 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.

Beispielsweise:

$ ssh -o PubkeyAuthentication=no root@host

5
2017-09-20 21:44



Genau das passierte mir! Vielen Dank für die Erklärung;) - El Ninja Trepador


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

Host *
IdentitiesOnly yes

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


3
2017-07-23 17:29





Wenn du @David sagst, füge einfach das hinzu IdentitiesOnly yes zu Ihrer .ssh / config, tut es das gleiche wie ssh -o PubkeyAuthentication=no.

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

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no user@IP_ADDR 'cat >> .ssh/authorized_keys'. Dies sollte Ihren ssh mit dem öffentlichen Schlüssel wieder aktivieren


2
2018-01-25 05:48





Ich weiß, dass dies ein alter Thread ist, aber ich wollte hier nur hinzufügen, dass ich die gleiche Fehlermeldung habe, aber es wurde durch den Besitzer des .ssh-Ordners verursacht, der root ist und nicht der Benutzer, der den Schlüssel benutzt hat. Ich habe das Problem durch Ausführen der folgenden Befehle behoben:

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

Ich stellte auch sicher, dass die Berechtigungen für den Ordner .ssh korrekt waren:

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
2018-06-13 17:37



Ich würde vorsichtig sein, wenn ich das ohne Vorbehalt benutze. SSH-Schlüsselberechtigungen sind für einige Schlüssel, insbesondere AWS, normalerweise auf 400 beschränkt. Wenn Sie versuchen, sie höher zu setzen, führt dies dazu, dass der Schlüssel nicht akzeptiert wird und Sie Ihr AWS-Konto sperren können. - Michael Ryan Soileau