WardtermSSH-Client
DE
Herunterladen

SSH-Fehler "Too many authentication failures" beheben

Ihr SSH-Client hat mehr Schlüssel angeboten, als der Server erlaubt, meist weil der Agent viele hält, und jeder falsche Schlüssel zählt als fehlgeschlagener Versuch. Das Standardlimit ist 6. Verbinden Sie sich mit ssh -o IdentitiesOnly=yes -i ~/.ssh/the_right_key user@server und tragen Sie dann IdentitiesOnly yes und IdentityFile in einen Host-Block ein.

Keine Lust, Schlüssel und Hosts von Hand zuzuordnen? In Wardterm gehört zu jedem Server sein eigener Schlüssel. Zeigen

Aktualisiert am . Reproduziert mit OpenSSH 10.3 unter macOS und einem separaten Test-ssh-agent mit 8 Schlüsseln, gegen OpenSSH 10.0 unter Debian 13 mit dem Standard-MaxAuthTries von 6 und mit einem niedrigeren Wert.

Die Meldung

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

Auf dem Server steht im Log:

maximum authentication attempts exceeded for user from 203.0.113.20 port 47120 ssh2 [preauth]

Oft wurden Sie gar nicht nach einem Passwort gefragt. In unserem Test scheiterte ein Konto mit funktionierendem Passwort mit dieser Meldung vor jeder Abfrage, weil die Schlüssel zuvor alle Versuche verbraucht hatten.

Die Ursache prüfen

Zählen Sie die Schlüssel in Ihrem Agent:

ssh-add -l

Sehen Sie dann nach, was tatsächlich angeboten wird:

ssh -v user@server 2>&1 | grep -E 'Offering|Too many'
debug1: Offering public key: key1 ED25519 SHA256:...
debug1: Offering public key: key2 ED25519 SHA256:...
debug1: Offering public key: key3 ED25519 SHA256:...
debug1: Offering public key: key4 ED25519 SHA256:...
debug1: Offering public key: key5 ED25519 SHA256:...
debug1: Offering public key: key6 ED25519 SHA256:...
Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

Jeder Schlüssel, den der Server nicht akzeptiert, zählt als ein Fehlschlag, und das Limit ist MaxAuthTries, standardmäßig 6. In unserem Test kam der sechste Schlüssel noch an die Reihe: Mit dem richtigen Schlüssel an sechster Stelle funktionierte die Anmeldung, mit sechs falschen davor scheiterte sie. Ein Server mit niedrigerem Limit scheitert früher.

Die Lösung: ssh sagen, welchen Schlüssel es nehmen soll

Für einen Versuch:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_server user@server

Um es dauerhaft zu machen, fügen Sie dies in ~/.ssh/config ein:

Host server
    HostName 203.0.113.10
    User user
    IdentityFile ~/.ssh/id_ed25519_server
    IdentitiesOnly yes

-i allein genügt nicht. Wir haben es ausprobiert: Ohne IdentitiesOnly kamen die Schlüssel des Agents trotzdem zuerst, und derselbe Fehler kehrte zurück. IdentitiesOnly yes beschränkt ssh auf die Schlüssel, die Sie genannt haben.

Weitere Einstellungen pro Host finden Sie in diesen Beispielen für die SSH-Config-Datei.

Wenn der Schlüssel nur im Agent liegt

IdentityFile kann auf die Datei des öffentlichen Schlüssels zeigen. ssh wählt dann anhand dieser Datei den Schlüssel aus, und der Agent übernimmt das Signieren:

Host server
    IdentityFile ~/.ssh/id_ed25519_server.pub
    IdentitiesOnly yes

Wenn Sie sich mit Passwort anmelden

Schlüssel stören hier nur, schalten Sie sie für diese Anmeldung also ab:

ssh -o PubkeyAuthentication=no user@server

In einer Konfigurationsdatei ist das PubkeyAuthentication no im Block des Hosts.

Weitere Möglichkeiten

Weniger Schlüssel im Agent halten

ssh-add -l                      # list
ssh-add -d ~/.ssh/old_key       # remove one
ssh-add -D                      # remove all

Das entfernt Schlüssel nur aus dem Agent und lässt die Dateien in Ruhe. Wenn Sie für jeden Server einen eigenen Schlüssel haben, wächst die Liste schnell, die Konfiguration oben ist also die dauerhafte Antwort.

Den Agent für einen Host überspringen

Host server
    IdentityAgent none
    IdentityFile ~/.ssh/id_ed25519_server

Das funktioniert auch, aber Sie tippen jedes Mal die Passphrase des Schlüssels, falls er eine hat.

IdentitiesOnly für alle Hosts setzen

Sie können IdentitiesOnly yes unter Host * setzen. Ohne IdentityFile für einen Host probiert ssh die Standarddateien wie ~/.ssh/id_ed25519 und ignoriert andere Schlüssel im Agent. Hosts, die auf einen dieser anderen Schlüssel angewiesen waren, brauchen also eine eigene IdentityFile-Zeile.

Erhöhen Sie dafür nicht MaxAuthTries

Auf einem Server, den Sie kontrollieren, können Sie das Limit erhöhen, aber die Ursache liegt beim Client. Jeder andere Server, mit dem Sie sich verbinden, behält sein Limit, und ein höheres Limit gibt jedem, der Passwörter errät, mehr Versuche pro Verbindung.

Wiederholte Fehlschläge können zur Sperre führen

Läuft auf dem Server fail2ban, kann jeder solche Verbindungsabbruch gegen Ihre Adresse zählen. In unserem Test erhöhte ein solcher Abbruch die Fehlschläge im sshd-Jail um eins. Wird der Fehler nach einigen Versuchen zu Connection refused, sind Sie womöglich gesperrt. Siehe fail2ban für SSH.

Fragen

Was ist der Standardwert von MaxAuthTries?

6. Jeder Schlüssel, den der Server ablehnt, zählt als Versuch. Ein Agent mit vielen Schlüsseln kann sie also aufbrauchen, bevor der richtige an der Reihe ist.

Warum hilft ssh -i nicht?

Ohne IdentitiesOnly yes bietet ssh die Schlüssel des Agents trotzdem vor dem mit -i genannten an.

Wie sehe ich, welche Schlüssel ssh anbietet?

Führen Sie ssh -v user@server aus und suchen Sie die Zeilen Offering public key.

Quellen

Mehr zu Fehlermeldungen

Alle Anleitungen