Wiederherstellen nach "Zu vielen Authentifizierungsfehlern für Benutzer root"

Ich habe mehrere Versuche unternommen, eine SSH-Verbindung für den Benutzer root @ host mithilfe des Putty-Terminals herzustellen. Dabei habe ich mehrmals falsche Anmeldeinformationen angegeben, und danach habe ich sie korrekt angegeben. Nachdem die Anmeldeinformationen akzeptiert wurden, bricht die ssh-Sitzung mit ab

"Server unerwartet geschlossene Netzwerkverbindung".

Dieser Fehler wird vom Putty Terminal gemeldet. Wenn Sie versuchen, root @ localhost von der lokalen Konsole aus zu sshen, funktioniert dies einwandfrei. Es funktioniert auch gut, wenn ich otheruser @ host von einem anderen Host ssh. Netzwerkverbindungsprobleme sind also nicht schuld. Der einzige Fehler, an den ich denke, ist: "Zu viele Authentifizierungsfehler für Benutzer root", obwohl Putty einen anderen Fehler gemeldet hat.

Die Frage ist: Wie kann ich mich von diesem Fehlerzustand erholen und Putty wieder anmelden lassen? Ein Neustart von sshd scheint nicht zu helfen

Sind Sie sicher, dass die Anmeldung als root bei ssh erlaubt ist?

Überprüfen Sie sshd_config und stellen Sie sicher, dass die Root-Anmeldung zulässig ist. sshd muss neu gestartet werden, wenn sich die Einstellung ändert.

"Zu viele Authentifizierungsfehler für Benutzer root" bedeutet, dass das MaxAuthTries-Limit Ihres SSH-Servers überschritten wurde . Es kommt vor, dass Ihr Client versucht, sich mit allen möglichen Schlüsseln zu authentifizieren, die in /home/USER/.ssh/ gespeichert sind.

Diese Situation kann folgendermaßen gelöst werden:

1. ssh -i / path / to / id_rsa root @ host
2. Geben Sie das Host / IdentityFile- Paar in /home/USER/.ssh/config an .
   • Host host
   • IdentityFile /home/USER/.ssh/id_rsa
   • Host host2
   • IdentityFile /home/USER/.ssh/id_rsa2
3. Erhöhen Sie MaxAuthTries Wert auf dem SSH - Server in / etc / ssh / sshd_config (nicht empfohlen).

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 .sshVerzeichnis gespeichert haben . In diesem Fall -iversucht der SSH-Client zunächst, sich mit jeder Identität (privatem Schlüssel) anzumelden, und fordert anschließend zur Kennwortauthentifizierung auf, wenn die Option in der Befehlszeile nicht angegeben ist. Sshd trennt die Verbindung jedoch nach fünf fehlerhaften Anmeldeversuchen (die Standardeinstellung kann ebenfalls variieren).

Wenn Sie also mehrere private Schlüssel in Ihrem .ssh-Verzeichnis haben, können Sie diese Public Key Authenticationüber die Befehlszeile mit dem -ooptionalen Argument deaktivieren .

Zum Beispiel:

$ ssh -o PubkeyAuthentication=no root@host

Öffnen Sie auf dem Remote-Computer / etc / sshd_config und ändern Sie den Wert

MaxAuthTries 30

Dies ist ein typisches Problem, wenn Sie mehrere Schlüssel installiert oder mehrere Verbindungen geöffnet haben. Die schrittweise Überprüfung jedes Schlüssels durch den Server und wenn MaxAuthTries auf 3 eingestellt ist, werden Sie nach den ersten 3 Versuchen von der Verbindung getrennt. Typische SSH-Sicherheit.

Ich empfehle Ihnen, den ausführlichen Modus während der Verbindung zum Remote-Computer zu verwenden, um das Problem zu analysieren.

ssh -v -p Portnummer Benutzer @ Servername

Wie die meisten Leute in diesem Forum raten, ist FALSCH und seine Zeitverschwendung. Versuchen Sie zuerst, das Problem zu analysieren, sammeln Sie Informationen und fragen Sie dann.

Habe Spaß.

Das ist eine schlechte Praxis. Haben Sie einfach einen regulären Benutzer auf der Remote-Box und stellen Sie mit ssh eine Verbindung her. Dann erhalten Sie Root-Zugriff mit su / sudo.

Für mich wurde dieses Problem gelöst, indem die folgende ssh_config für den Host erstellt wurde, zu dem ich eine Verbindung herstellte.

(~ / .ssh / config)

Host example
HostName example.com
User admin
IdentityFile ~/path/to/ssh_key_rsa
IdentitiesOnly=yes

Das Problem ist aufgetreten, weil ich viel zu viele SSH-Schlüssel in meinem ~/.sshOrdner habe, z. B. 16 oder so. Und ohne diese IdentityFileUND- IdentitiesOnlyAnweisungen in der Konfiguration hat mein Computer anscheinend alle Schlüssel eingegeben ~/.sshund die maximale Anzahl von Versuchen erreicht, bevor er versucht hat, die richtige Identitätsdatei zu erstellen.

Ich würde Ihnen empfehlen, wie oben von Anon gepostet, einen anderen Benutzer zu verwenden, um ssh-Zugriff zu erhalten, und dann den suBefehl zu verwenden, um rootZugriff zu erhalten.

Stellen Sie außerdem sicher, dass PermitRootLoginin der /etc/ssh/sshd_configDatei auf dem Server aktiviert ist .

Ich stand auch vor dem gleichen Problem. Dies kann leicht passieren, wenn Sie Pageant verwenden und eine große Anzahl von Schlüsseln geladen haben , da diese Server jedes Angebot eines öffentlichen Schlüssels als Authentifizierungsversuch betrachten.

(Dieser Rat wird von hier übernommen .)

Ich habe dieses Problem in meinen Systemen behoben, indem ich folgende Befehle ausgeführt habe:

eval $(ssh-agent)
ssh-add  ~/.ssh/keyname

Dann versuchen Sie es mit ssh auf einem entfernten Rechner

Um dieses Problem vorübergehend zu beheben, bis die an anderer Stelle genannten Probleme vollständig behoben sind, können Sie die PAM-Liste eines Benutzers zurücksetzen, damit er es erneut versuchen kann:

pam_tally --reset --user <USERNAME>
pam_tally2 --reset --user <USERNAME>

Ich wurde von einem ähnlichen Problem gebissen. Die eigentliche Ursache war jedoch, dass ich ForwardAgent yesin der Konfigurationsdatei eine Maschine entlang der Pipe hatte. Ich habe eine Verbindung von Maschine A zu Maschine B zu Maschine C hergestellt.

Die Fehlermeldung wurde beim SSH-Versuch von B -> C angezeigt, wurde jedoch dadurch verursacht, dass A die Weiterleitung aktiv hatte. Also hat C zuerst alle Schlüssel von A und erst dann die von B bekommen.

Es erschien plötzlich, als ich noch einen Schlüssel zu A hinzufügte.

Ich habe dieses Problem auf meinem Mac behoben durch:

1. Setzen Sie dann das root-Passwort mit "sudo passwd root"
2. Bearbeiten und Speichern der ssh-Konfigurationsdatei mit "nano / etc / ssh_config" und
3. Ändern der RSAAuthentication auf "nein" anstatt auf "ja".

OK, also in meinem Fall war das ziemlich komisch, hier geht es ...

Ich habe eine standardmäßige virtuelle Maschine mit einem SSH-Schlüssel und kann mit Putty eine SSH-Verbindung herstellen. Beim Versuch, während der Bereitstellung in PHPStorm darauf zuzugreifen, wird eine too many authentication failuresFehlermeldung angezeigt . Also habe ich das MaxAuthTriesin meinem erhöht sshd_configund dann bin ich mit Auth failedFehler getroffen worden und dann Auth cancel.

Ich weiß nicht genau, warum ich das überhaupt versucht habe, aber ... ich habe den Punkt am Ende meines SSH-Schlüsselpfads im Bereitstellungsfenster von PHPStorm hinzugefügt. So war es also:

C:\Users\Deadpool\\.ssh\chimichanga

und jetzt ist es so:

C:\Users\Deadpool\\.ssh\chimichanga.

Und es funktioniert ... In meinem ".ssh" -Ordner habe ich weitere Dateien:

chimichanga - copy of "id_rsa" from vagrant machine
chimichanga.ppk
chimichanga.pub

Ich bin mir nicht sicher, was dieser verdammte Punkt tut, aber die Verwendung der .ppkDatei funktioniert nicht, also denke ich, dass es eine Art Magie ist;) Oh, und ich könnte die MaxAuthTries nach diesem "Punkttrick" loswerden.

In anderen Antworten erfahren Sie, wie Sie am besten als Root verbunden werden und welche Auswirkungen dies auf die Sicherheit hat. Ihre ausdrückliche Frage lautete jedoch

Wie kann ich mich von diesem Fehlerzustand erholen und Putty erneut anmelden lassen?

Sie erwähnen beim letzten Verbindungsaufbau, dass der Remote-Server die Verbindung abgebrochen hat.

Ich denke, Sie werden feststellen, dass auf dem Remote-Server fail2ban (*) ausgeführt wird und Ihre IP-Adresse nach der erfolgreichen Anmeldung "gesperrt" wurde. Sie können dies testen, indem Sie versuchen, sich erneut anzumelden, und Sie erhalten nicht einmal die Anmeldeaufforderung.

Es gibt zwei Lösungen: Sie können entweder die Gefängniszeit abwarten, bis die Dinge wieder normal sind, aber die Gefängniszeit kann alles Mögliche sein. Oder Sie können einen anderen Computer finden, von dem aus Sie sich anmelden, das tun und Ihre IP "aus dem Gefängnis entfernen". In diesem Fall ist "anders" aus der Sicht des Remote-Servers, sodass ein anderer Computer hinter derselben Firewall wahrscheinlich auch nicht funktioniert .

(*) fail2ban ist ein sehr praktischer Daemon, der in regelmäßigen Abständen verschiedene Protokolldateien überprüft und Firewall-Regeln anpasst, damit der Server "verschwindet", wenn er potenziell böswilliges Verhalten von einem Client erkennt. Unter Debian ist es standardmäßig so konfiguriert, dass mehrere fehlgeschlagene SSH-Anmeldungen von einer bestimmten IP-Adresse erkannt werden. Nach 3 (glaube ich) werden alle Pakete von dieser IP-Adresse verworfen. Funktioniert hervorragend, um diese skriptbasierten Brute-Force-Angriffe zu stoppen.

Wie @sufferer in einer anderen Antwort erwähnte, enthalten einige Linux-Distributionen Monitore, um sich vor Brute-Force-Angriffen auf externe sichtbare Dienste wie beispielsweise SSH DenyHostsoder zu schützen fail2ban. Diese Monitore überprüfen die Protokolldateien auf fehlgeschlagene Versuche und fügen Filter hinzu, um IP-Adressen zu blockieren, die zu viele Fehler aufweisen (die Anzahl ist konfigurierbar und unabhängig von der sshd-Konfiguration).

Wenn Ihre Distribution enthält fail2ban, welche Dienste das Hinzufügen von Regeln zur Firewall von iptables schützen, können Sie mit dem folgenden Befehl überprüfen, welche Dienste oder "Jails" überwacht werden:

sudo fail2ban-client status

Das Gefängnis für den SSH-Dienst ist sshd. Um zu überprüfen, ob gesperrte IP-Adressen vorhanden sind, können Sie Folgendes verwenden:

sudo fail2ban-client status sshd

und um eine IP-Adresse aufzuheben:

sudo fail2ban-client set sshd unbanip a.b.c.d

Wenn ja DenyHosts, befindet sich die gesperrte Liste in der Datei /etc/hosts.deny. Sie können diese Datei direkt als root bearbeiten. Um einen dauerhaften Zugriff auf IP abcd zu gewähren, können Sie die Zeile sshd:a.b.c.dzur Datei /etc/hosts.allow hinzufügen .

Wie immer ist der manBefehl dein Freund:

man fail2ban
man hosts.deny

Es sollte andere ähnliche Dienstprogramme geben, aber ich habe nur diese verwendet.

Beachten Sie, dass das Erhöhen der Anzahl der in der sshd-Konfiguration zulässigen Wiederholungsversuche keine gesperrten IP-Adressen freigibt, sondern nur mehr Fehler in derselben Verbindung zulässt. Wenn die zulässige Anzahl überschritten wird, stellt der Benutzer / Angreifer einfach erneut eine Verbindung her, um n-mal mehr zu versuchen.

Andere Dienste hatten die Sperrliste integriert (wie in der Antwort von Rajnesh Thakur zum Neustart des VNC-Servers gezeigt).

Ich habe dieses Problem in zwei einfachen Schritten auf meinem Ubuntu 16.04 Server behoben -

Stoppen Sie zuerst meinen VNC-Server oder beenden Sie den Prozess -

vncserver -kill :1

und dann wieder von vorne anfangen -

vncserver

Danach verbinden Sie es vom Remotedesktop-Client -

192.0.2.99:5901

Getan !!

Bitte befolgen Sie die nachstehenden Schritte zur Lösung

1. Sichern Sie / etc / ssh / sshd_config
2. Erhöhen Sie den Wert von MaxAuthTries in sshd_config
3. stopsrc -s sshd; startsrc -s sshd

Und nach den obigen Änderungen erneut prüfen

Ich hatte das gleiche Problem, bei dem ich immer wieder "SServer sendete getrennte Nachricht vom Typ 2 (Protokollfehler): Zu viele Authentifizierungsfehler für Benutzer" erhielt.

Ich habe dieses Problem behoben, indem ich alle meine ssh-Dateien (.ppk-Schlüssel) entfernt und mich dann beim integrierten AD-Server angemeldet habe.