SSH verbraucht Anmeldeversuche vor dem richtigen Schlüssel · Linux Fix Lab

Symptome und Geltungsbereich

SSH trennt die Verbindung wegen zu vieler Authentifizierungsfehler.
Der vorgesehene Schlüssel steht hinter mehreren anderen Identitäten.

Betroffene Umgebung

OpenSSH-Client mit ssh-agent oder Schlüsselanbieter; Konfiguration ohne Verbindungsaufbau prüfen.

Erkennbare Meldungen (synthetische Beispiele)

sshd[921]: maximum authentication attempts exceeded for example from 192.0.2.10 port 50121 ssh2

Eine falsche Schlüsselauswahl ist möglich; die Serverzeile nennt nicht das Verfahren, das die Versuche verbraucht hat.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

Der Agent kann vor dem freigegebenen Schlüssel andere Schlüssel anbieten.
Wiederholte Passwort- oder interaktive Fehlversuche können dasselbe Limit verbrauchen.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Listet Fingerabdrücke des aktuellen Agenten; private Schlüssel werden weder ausgegeben noch Agent-Inhalte verändert.

ssh-add -l

Ergebnis einordnen: Eine lange Liste stützt ein Problem mit der Reihenfolge. Ein Agent-Verbindungsfehler oder ein leerer Agent spricht für einen anderen Anmeldepfad.

Prüfschritt 2

HOSTNAME durch den betroffenen SSH-Alias ersetzen. -G wertet die Konfiguration ohne Verbindung aus.

ssh -G HOSTNAME

Ergebnis einordnen: identityfile, identitiesonly, identityagent und preferredauthentications prüfen; mehrere IdentityFile-Einträge bleiben auch mit IdentitiesOnly zulässig.

Nächste Schritte nach Befund

Vorgesehene Identität für diesen Host auswählen

Wenn fremde Agent-Schlüssel das Problem sind, hostspezifisch IdentityFile und IdentitiesOnly yes setzen. Mit ssh -o IdentitiesOnly=yes -i /pfad/zum/schluessel HOSTNAME dieselbe Auswahl testen. Der Befehl versucht eine Anmeldung und gehört nicht in unbeaufsichtigte Diagnosen.

Vorsicht: Den vorhandenen Pfad zum privaten Schlüssel verwenden; niemals dessen Inhalt einfügen. Keine Vorgabe für alle Hosts ändern.

Wiederherstellung / Rücknahme: Die neuen hostspezifischen Optionen entfernen oder die gesicherte SSH-Konfiguration wiederherstellen; ein einmaliger Aufruf benötigt keine Dateiwiederherstellung.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Konto oder Anmeldeverfahren korrigieren

Wenn der Agent nicht verantwortlich ist, Benutzername und erforderliche Anmeldereihenfolge mit der Serververwaltung prüfen. Das freigegebene Schlüssel-Konto-Paar verwenden oder den nötigen zweiten Faktor abschließen, statt weitere Passwörter gegen das verbrauchte Limit zu probieren.

Vorsicht: MaxAuthTries nicht global erhöhen, um eine beliebig lange Agent-Liste zu ermöglichen.

Wiederherstellung / Rücknahme: Den vorherigen Benutzernamen oder die Einstellung zum Anmeldeverfahren wiederherstellen, falls die hostspezifische Änderung falsch war.