SSH: Too many authentication failures vor dem Passwort

Die echte, verifizierte Lösung

1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:

1. 1.

   Die im Agenten geladenen Schlüssel zählen

   ssh-add -l listet die Schlüssel, die der Agent gerade hält. Sind es mehr als sechs, kann der Server in der Vorgabe nicht einmal alle durchprobieren; er beendet die Verbindung vorher. Die Zahl erklärt dann auch, warum die Anmeldung gegen manche Hosts klappt und gegen andere nicht: Dort, wo der passende Schlüssel früh in der Liste liegt, reicht das Kontingent, dort, wo er spät liegt oder gar nicht, nicht. Auf Rechnern mit Agent-Weiterleitung aus einer anderen Sitzung kommen zudem fremde Schlüssel dazu.

   ssh-add -l
   

2. 2.

   Den Ablauf mit -v sichtbar machen

   ssh -v zeigt, in welcher Reihenfolge der Client Schlüssel anbietet und welche der Server ablehnt. Die Meldung Too many authentication failures erscheint dann als Abbruch durch den Server, nicht als Fehler des Clients. Wer dort sieht, dass fünf fremde Schlüssel vor dem richtigen angeboten werden, hat die Ursache, ohne auf dem Server nachsehen zu müssen. Das Protokoll lohnt sich auch, um zu prüfen, ob der richtige Schlüssel überhaupt in der Liste ist.

   ssh -v ziel.example 2>&1 | grep -E 'Offering|Authentications that can continue|Too many'
   

3. 3.

   Für den Host nur den einen Schlüssel anbieten

   In der eigenen ssh_config ein Host-Block mit IdentityFile und IdentitiesOnly yes. Damit bietet der Client für diesen Host laut Handbuchseite nur die konfigurierte Identitätsdatei an, auch wenn der Agent mehr anbietet. Der Agent kann den Schlüssel trotzdem entsperrt halten; die Option schränkt nur ein, was angeboten wird, nicht, woher die Entsperrung kommt. Für einen einmaligen Versuch geht dasselbe auf der Kommandozeile mit -o IdentitiesOnly=yes und -i.

   # ~/.ssh/config
   Host ziel.example
       HostName ziel.example
       User benutzer
       IdentityFile ~/.ssh/id_ed25519_ziel
       IdentitiesOnly yes
   

4. 4.

   Als Server-Administrator den Wert bewusst wählen, nicht blind erhöhen

   MaxAuthTries in sshd_config legt die Versuche je Verbindung fest, Vorgabe 6; ab der Hälfte werden weitere Fehlschläge protokolliert. Wer den Wert anhebt, erlaubt jedem Client mehr Rateversuche pro Verbindung und verschiebt zugleich die Schwelle, ab der das Protokoll füllt. Die Handbuchseite führt MaxAuthTries unter den Schlüsselwörtern, die in einem Match-Block stehen dürfen; ein höherer Wert ließe sich also auf bestimmte Nutzer oder Adressen beschränken, statt global zu gelten. Nach einer Änderung die Konfiguration mit sshd -t prüfen und den Dienst neu laden.

   # /etc/ssh/sshd_config
   MaxAuthTries 6
   # Prüfen und neu laden
   sshd -t && systemctl reload sshd   # Dienstname je nach Distribution ssh oder sshd
   

Häufige Fragen (FAQ)

Belege

Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.

1. [1]

   sshd_config(5) – OpenSSH daemon configuration file, Handbuchseite auf man7.org, Schlüsselwörter MaxAuthTries, Match und LogLevel (abgerufen 17.10.2026)

   man7.org · abgerufen am 17.10.2026

2. [2]

   ssh_config(5) – OpenSSH client configuration file, Handbuchseite auf man7.org, Schlüsselwörter IdentitiesOnly, IdentityFile und IdentityAgent (abgerufen 17.10.2026)

   man7.org · abgerufen am 17.10.2026

Zuletzt geprüft am 17.10.2026. Dokumentation altert – ein Datum daneben ist der einzige ehrliche Umgang damit.