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

64

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

user11722
quelle
1
Stellen Sie sicher, dass Sie Ihren ssh-Agenten deaktivieren (z. B. Festzug unter Windows), wenn Sie eine Too many Authentication FailuresFehlermeldung erhalten, bevor Sie sich überhaupt anmelden können.
Mahn

Antworten:

8

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.

Damorg
quelle
120

"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).
Peta Sittek
quelle
9
Dies sollte wirklich die akzeptierte Antwort sein!
Benjamin
4
Um eine akzeptierte Antwort zu sein, müsste sich die Antwort wirklich auf die in der Frage erwähnte Software beziehen. =)
Rakslice
4
Eine andere Ursache für die Überschreitung des Limits könnte Ihr SSH-Agent sein. ssh -vvEs wurden mehrere Versionen von zwei Schlüsseln (von ssh-agent bereitgestellt) ausprobiert. Ich gehe davon aus, dass ich selten neu gestartet und einige abgelaufene Schlüssel ersetzt habe. anscheinend überschreibt ssh-agent alte schlüssel nicht mit neuen. Ich habe ssh-agent getötet und das Problem ist verschwunden.
Mark
Welchen Nachteil würde eine Zunahme haben MaxAuthTries? Ich bezweifle, dass viele Angriffe mit vielen verschiedenen Schlüsseln ausgeführt werden. Außerdem kann ein Angreifer, wenn er dies möchte, die Verbindung einfach schließen und jedes Mal eine neue öffnen, wenn er das Limit erreicht. Es wird ihnen sowieso nicht gelingen, einen Schlüssel zu erzwingen.
Kasperd
@ Mark Danke! Das Neustarten von ssh-agent hat es für mich behoben!
Winduptoy
90

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
Will Verna
quelle
1
Ich danke dir sehr! Mit Ubuntu Server kann ich hier nur per SSH zugreifen. Ich hatte "MaxAuthTries 1" eingestellt, nachdem ich blind einem Tutorial im Internet gefolgt war.
Andre Figueiredo
Du hast mir gerade das Leben gerettet! Ohne Schlüsselauthentifizierung halfen die anderen Antworten nicht. Das hat es soooo leicht gelöst !!
George Green
5
Dies ist die Antwort
smac89
Ich habe meinen Schlüssel einfach mit der Kennwortauthentifizierung erneut kopiert und jetzt funktioniert es jedes Mal. Ich habe viele Schlüssel in meinem .sshVerzeichnis, ich glaube nicht, dass es auf den Betrag ankommt.
Ken Sharp
Dies ist die relevanteste Antwort und sollte eigentlich das Standardverhalten für ssh-copy-id sein. Wenn ich meine ID auf einen Server kopieren möchte, ist sie normalerweise nicht vorhanden. Wenn ssh jedoch zuerst versucht, sich mit pubkey beim Server zu authentifizieren, bricht der Server die Verbindung ab, bevor er das Kennwort eingeben kann.
Sprinterfreak
17

Ö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ß.


quelle
In meinem speziellen Fall bestand das Problem darin, dass ich mit Agentenweiterleitung angemeldet war und versuchte, ein Skript auszuführen, das seine eigene SSH-Identität verwendete. Als ich es mit der Agentenweiterleitung ausführte, waren es zu viele Identitäten, bevor es seine eigenen versuchte. Also habe ich das Skript so eingerichtet, dass die Agentenumgebung weggeworfen wird, und das hat es aufgeräumt. Ich hätte auch die MaxAuthTries erhöhen können, aber das musste ich in diesem Fall nicht.
Sean Reifschneider
1
Vielen Dank. -vIch habe meinem ssh-Client gezeigt, wie er versucht, mehrere Schlüssel zu verwenden (ich habe jetzt einige). Ich habe sie vom Agenten mitssh-add -D
joeytwiddle 14.07.14
12

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.

Anonym
quelle
10

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.

Ninjaxor
quelle
6

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 .

Nager43
quelle
5

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 .)

Prabath Dolawatta
quelle
1
Wir sind nicht sehr an Nur-Links-Antworten interessiert, da die Links verrotten und die Antwort unbrauchbar wird. Behalten Sie den Link auf jeden Fall bei, aber wenn Sie die Lösung in ein oder zwei Absätzen zusammenfassen könnten, könnten Sie hier eine positive Antwort haben.
MadHatter
2
Ich hoffe, Sie werden meine nachfolgende Bearbeitung verzeihen. Jetzt (ich hoffe) wird klargestellt, dass der Rat, auf den Sie sich beziehen, der Rat ist, den Sie geben, aber die ursprüngliche Quelle immer noch gutschreibt. +1 von mir für das Bemühen, deine Antwort zu verbessern!
MadHatter
Ich hatte auch in Putty das Problem "Zu viele Authentifizierungsfehler". Nachdem ich alle anderen Schlüssel von PageAnt entfernt habe, meldete ich mich endlich erfolgreich an.
klor
4

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

Sunil Shakya
quelle
3

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>
andyfeller
quelle
2

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.

Igor Stoppa
quelle
1

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".
tallbr00
quelle
0

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.

Adam Witorean
quelle
0

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.

Leidende
quelle
0

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).

Fjor
quelle
-2

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 !!

Rajnesh Thakur
quelle
Das hat nichts mit der Frage zu tun.
Ken Sharp
-3

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

Arun Mathuria
quelle
-4

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.

Eskimo-Jbk
quelle
Diese Antwort ist nicht nützlich und es ist gefährlich, .ppk-Dateien zu entfernen. Bitte Leute, wenn Sie denken, Sie müssen .ppk-Dateien entfernen (und ich kann mir keinen guten Grund vorstellen, warum Sie möchten), benennen Sie sie in etwas anderes um und löschen Sie sie nicht. Sie enthalten Ihre Schlüssel, die Sie wahrscheinlich brauchen.
Law29