SSH: „Too many authentication failures“ beheben

Bedeutung von „Too many authentication failures“

„Too many authentication failures“ bedeutet, dass Ihr SSH-Client dem Server mehr Schlüssel angeboten hat, als dieser prüfen wollte. Der Server hat die Verbindung beendet, bevor Ihr korrekter Schlüssel überhaupt angeboten wurde. Das ist fast immer ein Client-Problem. Der Schlüssel liegt auf Ihrer Festplatte, der Server hat ihn in authorized_keys, und trotzdem hilft keiner dieser Umstände, weil die Verbindung zu früh beendet wurde.

Der Ablauf ist wie folgt. ssh-agent enthält jeden privaten Schlüssel, den Sie dort geladen haben. Ihr Client bietet dem Server diese Schlüssel nacheinander an, weil er nicht wissen kann, welchen Schlüssel das Konto akzeptiert. Der Server weist jeden Schlüssel zurück, der nicht in authorized_keys enthalten ist, und zählt jede Zurückweisung als fehlgeschlagenen Authentifizierungsversuch. MaxAuthTries in sshd_config begrenzt, wie viele Fehlversuche eine Verbindung zulässt. Der Standardwert ist 6. Wenn Ihr Agent zehn Schlüssel enthält und der richtige Schlüssel an achter Stelle steht, beendet der Server die Verbindung, bevor er diesen Schlüssel erreicht.

Die Lösung besteht daher darin, dass der Client nur einen Schlüssel anbietet: den richtigen.

Was der Server zählt und wo MaxAuthTries ins Spiel kommt

Die Authentifizierung mit einem öffentlichen Schlüssel beginnt als Ratespiel. Der Client sendet einen öffentlichen Schlüssel und fragt, ob der Server eine damit erzeugte Signatur akzeptieren würde. Der Server antwortet mit Ja oder Nein. Ein „Nein“ ist ein fehlgeschlagener Versuch, genau wie ein falsches Passwort.

Die Handbuchseite sshd_config(5) beschreibt das Limit: „Gibt die maximale Anzahl von Authentifizierungsversuchen pro Verbindung an. Sobald die Anzahl der Fehler die Hälfte dieses Werts erreicht, werden weitere Fehler protokolliert. Der Standardwert ist 6.“

Sechs Versuche reichen für eine Person, die ein Passwort eingibt. Für einen Agenten mit zehn Schlüsseln ist das nicht viel. Sobald der Fehlerzähler das Limit überschreitet, trennt sshd die Verbindung und schreibt eine Zeile wie diese in das Systemprotokoll:

error: maximum authentication attempts exceeded for deploy from 203.0.113.10 port 51292 ssh2

Ihr Client gibt die andere Hälfte desselben Ereignisses aus:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures
Disconnected from 203.0.113.10 port 22

Das ist ein anderer Fehler als der Fehler SSH permission denied (publickey). In diesem Fall hat der Server alles geprüft, was Sie angeboten haben, und keinen der Schlüssel akzeptiert. Hier hat der Server die Prüfung beendet. Wer beide Fälle gleich behandelt, verbringt leicht einen Nachmittag damit, einen Schlüssel erneut zu kopieren, der bereits korrekt war.

Warum derselbe Schlüssel auf dem Laptop Ihres Kollegen funktioniert

Am Schlüssel und am Server ist nichts anders. Der Agent Ihres Kollegen enthält zwei Schlüssel, Ihrer enthält zwölf. Das Angebot, das bei ihm zuerst eintrifft, kommt bei Ihnen an neunter Stelle. Zu diesem Zeitpunkt ist die Verbindung bereits beendet.

Die Anzahl wächst unbemerkt. AddKeysToAgent yes in ~/.ssh/config fügt jeden von Ihnen verwendeten Schlüssel dem Agent hinzu und lässt ihn dort. Desktop-Keyring-Agenten wie GNOME Keyring unter Linux oder der Anmelde-Schlüsselbund unter macOS laden Schlüssel bei der Anmeldung, ohne nachzufragen. Fügen Sie im Laufe eines Jahres einen Client-Schlüssel, einen Git-Host-Schlüssel und einen Schlüssel für einen Laborserver hinzu, verweigert Ihnen eines Tages ein Server, der bisher immer funktioniert hat, die Verbindung. Am Server wurde nichts geändert. Ihr Agent enthält einfach mehr Schlüssel.

So sehen Sie die angebotenen Schlüssel mit ssh -v

Führen Sie die fehlschlagende Verbindung mit -v aus und lesen Sie die Ablaufverfolgung.

ssh -v deploy@203.0.113.10

Zwei Arten von Zeilen sind relevant. Will attempt key: listet die Identitäten auf, die der Client zusammengestellt hat, und zwar in der Reihenfolge, in der er sie verwendet. Offering public key: erscheint für jeden Schlüssel, der tatsächlich an den Server gesendet wurde.

debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:AAAA... agent
debug1: Will attempt key: /home/you/.ssh/id_rsa RSA SHA256:BBBB... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:AAAA... agent
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/you/.ssh/id_rsa RSA SHA256:BBBB... agent

Ihre Pfade, Schlüsseltypen und Fingerabdrücke unterscheiden sich. Sie zählen die Anzahl der Offering public key:-Zeilen vor dem Verbindungsabbruch. Wenn die Angebote fortgesetzt werden und die Sitzung endet, ohne dass Ihr vorgesehener Schlüssel jemals erscheint, ist die Diagnose eindeutig. Das Wort agent am Ende einer Zeile bedeutet, dass diese Identität aus ssh-agent stammt. Das Wort explicit bedeutet, dass sie aus einer IdentityFile-Zeile oder aus -i in der Befehlszeile stammt.

Fragen Sie anschließend den Agenten ab, welche Schlüssel er geladen hat:

ssh-add -l

Jede Ausgabezeile entspricht einem geladenen Schlüssel. Wenn The agent has no identities. ausgegeben wird, ist der Agent nicht die Ursache. Prüfen Sie stattdessen die IdentityFile-Zeilen in ~/.ssh/config. Wenn Could not open a connection to your authentication agent. ausgegeben wird, läuft kein Agent. Die Angebote stammen dann aus Ihren Standard-Schlüsseldateien.

Fix 1: IdentitiesOnly mit einem Schlüssel pro Host

IdentitiesOnly yes weist ssh an, nur die von Ihnen konfigurierten Identitäten anzubieten und die zusätzlichen Identitäten zu ignorieren, die der Agent selbst bereitstellt. Zusammen mit einer IdentityFile-Zeile sendet der Client ein einziges Angebot.

Host vps
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519_vps
  IdentitiesOnly yes

Speichern Sie das unter ~/.ssh/config und führen Sie anschließend chmod 600 ~/.ssh/config aus. Eine Datei, die für die Gruppe oder für alle Benutzer schreibbar ist, führt dazu, dass ssh die Ausführung mit Bad owner or permissions on /home/you/.ssh/config verweigert. ssh vps bietet dann einen Schlüssel an, und ssh -v vps sollte genau eine Offering public key:-Zeile anzeigen.

Hier sorgen zwei Details häufig für Überraschungen.

• IdentitiesOnly yes allein bedeutet nicht „ein Schlüssel“. Die Standard-Identitätsdateien zählen als konfigurierte Identitäten. ssh versucht daher weiterhin ~/.ssh/id_ed25519, ~/.ssh/id_rsa und alle anderen gefundenen Standarddateien. Sie benötigen zusätzlich die IdentityFile-Zeile.
• Der Agent führt die Signatur weiterhin aus. IdentitiesOnly steuert, welche Schlüssel angeboten werden, nicht wer sie signiert. Wenn der in IdentityFile angegebene private Schlüssel im Agent geladen ist, erzeugt der Agent die Signatur, und Sie werden nie nach einer Passphrase gefragt. Sie können IdentityFile sogar auf die passende .pub-Datei verweisen. Das ist sinnvoll, wenn der private Schlüssel nur im Agent oder auf einem Hardware-Token vorhanden ist.

Eine Einstellung in ~/.ssh/config kann diese Korrektur unbemerkt außer Kraft setzen. Bei den meisten Schlüsselwörtern wird der erste gefundene Wert verwendet. Deshalb gehören spezifische Host-Blöcke vor Host *. IdentityFile folgt dieser Regel nicht. Im Handbuch steht: „In Konfigurationsdateien können mehrere Identitätsdateien angegeben werden; alle diese Identitäten werden nacheinander ausprobiert.“ Ein IdentityFile unter Host * wird zu dem Schlüssel pro Host hinzugefügt und nicht durch ihn ersetzt. Eine vergessene globale Zeile fügt daher jeder Verbindung wieder ein zusätzliches Angebot hinzu.

Wenn Sie eine globale Sicherheitsvorgabe möchten, setzen Sie am Ende der Datei nur das Flag:

Host *
  IdentitiesOnly yes

Jeder Host benötigt dann eine eigene IdentityFile. Das entspricht ohnehin dem gewünschten Ergebnis. Die Zuordnung eines Schlüssels pro Server ermöglicht außerdem, den Zugriff einer einzelnen Maschine später zu widerrufen, ohne alle Schlüssel neu ausstellen zu müssen. Diese Vorgehensweise sollten Sie früh einführen: siehe SSH-Schlüssel pro Maschine verwalten.

Behebung 2: Agent bereinigen oder neu starten

Wenn Sie die Konfiguration noch nicht bearbeiten können, leeren Sie den Agent und laden Sie nur die benötigten Schlüssel.

ssh-add -l                    # list what is loaded
ssh-add -d ~/.ssh/id_rsa      # remove one key
ssh-add -D                    # remove every key
ssh-add ~/.ssh/id_ed25519_vps # load the one you need

Wenn die Verbindung direkt nach ssh-add -D funktioniert, war der Agent die Ursache. Betrachten Sie das als Test, nicht als Reparatur. Ein Desktop-Keyring-Agent lädt seine Schlüssel bei Ihrer nächsten Anmeldung erneut. Das Problem tritt daher morgen wieder auf. Eine IdentitiesOnly-Zeile in ~/.ssh/config bleibt über einen Reboot hinweg erhalten. Ein leerer Agent nicht.

Sie können einem Schlüssel auch eine Gültigkeitsdauer zuweisen. Dann entfernt der Agent ihn automatisch:

ssh-add -t 1800 ~/.ssh/id_ed25519_vps

Der Schlüssel wird 1800 Sekunden nach dem Hinzufügen entfernt. Ein Neustart des Agents funktioniert ebenfalls. Wie Sie ihn neu starten, hängt davon ab, wodurch er gestartet wurde. Ein von Ihnen selbst gestarteter ssh-agent wird mit ssh-agent -k beendet. Wenn Sie ihn über eine von Ihnen erstellte systemd-User-Unit ausführen, starten Sie diese Unit mit systemctl --user restart <unit> neu. Ein Keyring-Agent wird zusammen mit Ihrer Desktop-Sitzung neu gestartet.

Korrektur 3: der einmalige Befehl für einen Server, den Sie nur einmal verwenden

Für einen Host, den Sie nicht in Ihre Konfiguration aufnehmen, geben Sie dieselben Einstellungen in der Befehlszeile an:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10

-i allein ist die häufigste fehlerhafte Korrektur. -i fügt einen Schlüssel zur Liste der Identitäten hinzu. Die Schlüssel des Agents werden dadurch nicht aus dieser Liste entfernt. Deshalb werden alle anderen Schlüssel weiterhin vor Ihrem Schlüssel angeboten, und die Verbindung scheitert beim Limit. Wenn Sie ssh -v -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10 ohne IdentitiesOnly ausführen, sehen Sie, dass zuerst die Schlüssel des Agents angeboten werden. Neben -i muss -o IdentitiesOnly=yes angegeben werden.

Um den Agent für eine einzelne Verbindung vollständig zu deaktivieren:

ssh -o IdentityAgent=none -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10

ssh liest den privaten Schlüssel dann von der Festplatte und fordert dessen Passphrase an, sofern eine gesetzt ist.

Die auf ssh aufbauenden Werkzeuge akzeptieren dieselbe Option:

scp -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps report.tar.gz deploy@203.0.113.10:/tmp/
rsync -av -e "ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps" ./site/ deploy@203.0.113.10:/srv/site/
GIT_SSH_COMMAND="ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps" git clone git@example.com:team/repo.git

Warum der Fehler beim zweiten Hop auftritt

Mit ForwardAgent yes wird der Agent-Socket auf dem Server verfügbar gemacht, mit dem Sie sich verbinden. Ein auf diesem Server ausgeführter Befehl ssh verwendet Ihren lokalen Agent mit allen Ihren Schlüsseln über den weitergeleiteten Socket. Deshalb kann der Fehler beim Hop von einem Jump Host zum endgültigen Server auftreten, obwohl der erste Hop problemlos funktioniert hat. Führen Sie auf dem mittleren Rechner echo $SSH_AUTH_SOCK aus: Ein Socket-Pfad zeigt, dass ein weitergeleiteter Agent erreichbar ist. Eine leere Ausgabe bedeutet, dass kein Agent verfügbar ist.

Agent Forwarding verursacht ein zusätzliches Sicherheitsrisiko. Jeder Benutzer mit root-Zugriff auf den mittleren Rechner kann Ihren Agent verwenden, um sich als Sie zu authentifizieren, solange Ihre Sitzung geöffnet ist. ProxyJump vermeidet beide Probleme:

ssh -J deploy@jump.example.com deploy@10.0.0.5

ProxyJump stellt über den Jump Host eine Verbindung her und authentifiziert sich von Ihrem eigenen Rechner aus beim endgültigen Server. Dadurch gilt Ihre lokale Einstellung ~/.ssh/config für jeden Hop, einschließlich IdentitiesOnly. Das Deaktivieren von ForwardAgent ist ein üblicher Schritt beim Härten von SSH auf einem VPS.

Sollten Sie MaxAuthTries auf dem Server erhöhen?

In der Regel nicht. Prüfen Sie zuerst den aktuellen Wert:

sudo sshd -T | grep -i maxauthtries

sshd -T gibt die effektive Konfiguration einschließlich der Standardwerte aus. Dadurch wird der tatsächliche Wert angezeigt, auch wenn sshd_config dazu nichts ausgibt. Fügen Sie -C user=deploy,host=example.com,addr=203.0.113.10 hinzu, wenn Sie Match-Blöcke verwenden. Diese werden pro Verbindung ausgewertet und andernfalls übersprungen.

Das Erhöhen des Limits funktioniert im engen Sinne: Ein höherer Wert gibt einem fehlerhaften Client mehr Spielraum:

MaxAuthTries 20

Prüfen Sie die Datei und laden Sie den Dienst neu. Lassen Sie dabei eine zweite Sitzung geöffnet:

sudo sshd -t
sudo systemctl reload ssh      # Debian and Ubuntu
sudo systemctl reload sshd     # RHEL family

Wenn systemctl is-enabled ssh.socket unter Ubuntu 24.04 enabled meldet, wird sshd über einen Socket aktiviert. Für jede Verbindung wird ein neuer Prozess gestartet, der sshd_config erneut einliest. Neue Verbindungen übernehmen die Änderung dadurch automatisch.

Prüfen Sie nun, was diese Änderung bewirkt hat. Der Client bietet Schlüssel an, die dieser Server niemals akzeptieren wird. Durch das Erhöhen des Limits verarbeitet der Server für jede Verbindung bis zu zwanzig abgelehnte Angebote statt sechs. Das gilt für jeden verbundenen Client und für jeden Angreifer im Internet, der Passwörter ausprobiert. Jedes Angebot verursacht eine Abfrage in authorized_keys. Ihre eigene Anmeldung bleibt langsam, weil der richtige Schlüssel weiterhin an letzter Stelle steht. Fügen Sie Ihrem Agenten einen dreizehnten Schlüssel hinzu, und Sie stehen wieder am Anfang. Dann benötigen Sie erneut einen höheren Wert.

Erhöhen Sie den Wert nur, wenn ein legitimer Client tatsächlich mehrere Identitäten vorlegen muss. Beheben Sie in allen anderen Fällen die Client-Konfiguration. Eine Verringerung ist eine sinnvolle Härtungsmaßnahme, sobald sich jeder Benutzer mit einem konfigurierten Schlüssel anmeldet. Ein kleinerer Wert gibt einem Angreifer dann weniger Versuche pro Verbindung.

Warum fail2ban Sie dafür sperren kann

Mit der standardmäßigen Protokollstufe protokolliert sshd jeden abgelehnten öffentlichen Schlüssel:

Failed publickey for deploy from 203.0.113.10 port 51292 ssh2: ED25519 SHA256:AAAA...

Eine Verbindung mit einem vollständig geladenen Agent erzeugt innerhalb von ein oder zwei Sekunden mehrere solcher Zeilen von derselben Adresse. Das fail2ban-sshd-Jail zählt die von sshd protokollierten Fehlversuche und sperrt die Quelladresse, sobald maxretry innerhalb von findtime erreicht ist. Diese Zeitfenster sind standardmäßig kurz. Daher können zwei Wiederholungsversuche einer fehlerhaften Verbindung ausreichen, um Ihre eigene Adresse zu sperren.

Das Fehlerbild ändert sich anschließend. Genau das führt häufig zu Verwirrung. Die Meldung „Too many authentication failures“ wird nicht mehr angezeigt. Stattdessen sehen Sie gar nichts: Die Verbindung hängt und läuft schließlich in einen Timeout, weil die Firewall Ihre Pakete jetzt verwirft, anstatt darauf zu antworten. Ein Timeout an einer Stelle, an der zuvor eine Fehlermeldung erschien, ist das entscheidende Signal. Der Unterschied wird in SSH-Verbindung abgelehnt oder Timeout bei der Verbindung erläutert.

Prüfen Sie über die Konsole Ihres Providers oder von einer anderen Adresse aus das Jail und heben Sie die Sperre auf:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 203.0.113.10

Tragen Sie Ihre eigene Adresse während der Fehlersuche am Client in ignoreip in jail.local ein. Entfernen Sie sie anschließend wieder. Die Einrichtung des Jails wird im fail2ban-Leitfaden für Ubuntu 24.04 beschrieben.

Was Sie einmalig tun sollten, damit das Problem nicht wieder auftritt

Geben Sie jedem Server einen eigenen Host-Block in ~/.ssh/config mit HostName, User und IdentityFile sowie IdentitiesOnly yes. Danach ist ssh vps kurz einzugeben, bietet genau einen Schlüssel an und kann MaxAuthTries nicht auslösen, unabhängig davon, wie viele Schlüssel Ihr Agent später verwaltet. Außerdem hält es die Ausgabe von ssh -v kurz genug, um sie an dem Tag zu lesen, an dem etwas anderes ausfällt.

FAQ

Wie behebe ich „Too many authentication failures“ sofort?

Bieten Sie statt aller Schlüssel nur einen Schlüssel an. Für eine sofortige Verbindung führen Sie ssh -o IdentitiesOnly=yes -i ~/.ssh/your_key user@host aus. Für eine dauerhafte Lösung fügen Sie einen Block mit HostName, User und IdentityFile, die auf diesen Schlüssel verweisen, sowie IdentitiesOnly yes zu ~/.ssh/config hinzu und führen Sie anschließend chmod 600 ~/.ssh/config aus. Bestätigen Sie die Konfiguration mit ssh -v: Für diesen Host sollte genau eine Zeile mit Offering public key: angezeigt werden.

Warum bietet ssh -i weiterhin meine anderen Schlüssel an?

Weil -i einen Schlüssel zur Liste hinzufügt, die Liste aber nicht einschränkt. Die in ssh-agent geladenen Schlüssel bleiben in der Liste und werden weiterhin angeboten, oft vor Ihrem Schlüssel. Deshalb kann der Server MaxAuthTries weiterhin erreichen, bevor Ihr Schlüssel angeboten wird. -o IdentitiesOnly=yes ist die Option, die ssh auf die von Ihnen angegebenen Identitäten beschränkt. Verwenden Sie -i und -o IdentitiesOnly=yes gemeinsam oder -o IdentityAgent=none, um den Agenten für diese eine Verbindung vollständig zu ignorieren.

Sollte ich MaxAuthTries auf dem Server erhöhen, um das Problem zu beheben?

Nein, in nahezu allen Fällen. Der Client sendet Schlüssel, die dieser Server niemals akzeptiert. Ein höherer Grenzwert veranlasst den Server lediglich, pro Verbindung mehr abgelehnte Angebote zu prüfen. Das gilt für jeden Client und jeden Brute-Force-Versuch, der den Server erreicht. Das Problem tritt außerdem erneut auf, sobald ein weiterer Schlüssel in Ihrem Agenten landet. Prüfen Sie den effektiven Wert mit sudo sshd -T | grep -i maxauthtries, wenn Sie die Ursache untersuchen möchten, und beheben Sie die Client-Konfiguration mit IdentitiesOnly.

Warum tritt das jetzt auf einem Server auf, der im letzten Monat noch problemlos funktioniert hat?

Ihr Agent enthält mehr Schlüssel. AddKeysToAgent yes in ~/.ssh/config sorgt dafür, dass jeder von Ihnen verwendete Schlüssel geladen bleibt. Agenten von Desktop-Schlüsselbunddiensten laden Schlüssel außerdem selbstständig bei der Anmeldung. Sobald die Anzahl der geladenen Schlüssel den Wert von MaxAuthTries auf dem Server überschreitet, schlagen Verbindungen zu jedem Server fehl, dessen Schlüssel in der Angebotsreihenfolge spät an der Reihe ist. Führen Sie ssh-add -l aus und vergleichen Sie die Anzahl mit dem Grenzwert auf dem Server.

Kann fail2ban dadurch meine IP-Adresse sperren?

Ja. Jeder abgelehnte Schlüssel erzeugt eine Failed publickey for ...-Zeile im Server-Log. Dadurch kann eine einzige Verbindung innerhalb weniger Sekunden mehrere Fehlschläge von Ihrer Adresse erzeugen. Das fail2ban-sshd-Jail sperrt die Adresse, sobald maxretry innerhalb von findtime erreicht ist. Ein Hinweis darauf ist, dass sich der Fehler in eine hängende Verbindung und anschließend in einen Timeout ändert, weil Pakete verworfen statt beantwortet werden. Löschen Sie die Sperre über die Konsole mit sudo fail2ban-client set sshd unbanip <your address> und beheben Sie die Client-Konfiguration, bevor Sie die Verbindung erneut herstellen.