termalSSH-Fehlermeldungen sind mit Absicht knapp – das Protokoll verrät einem Fremden nicht, warum es ihn abgewiesen hat. Das ist gute Sicherheit und schlechte Ergonomie: Die Meldung, die du siehst, ist oft zwei Schritte vom eigentlichen Problem entfernt. Dies ist ein Feldführer zu den dreizehn Fehlern, die dir wirklich begegnen, was jeder davon tatsächlich bedeutet und der schnellste Weg zur Lösung.
Ein Werkzeug vorweg: ssh -v user@host (bis zu -vvv – diese Ausgabe lesen (auf Englisch)). Fast jedes Rätsel weiter unten hört auf, eines zu sein, sobald du siehst, an welchem Schritt des Handshakes es stirbt.
Die Fehler auf einen Blick
| Fehler | Was er bedeutet | Erster Schritt |
|---|---|---|
Connection refused | Host hat geantwortet; nichts lauscht auf diesem Port | Prüfen, ob sshd läuft und auf dem Port, den du gewählt hast |
Connection timed out | Pakete sind auf dem Weg verschwunden | Cloud-Firewall / Security Group prüfen |
Permission denied (publickey) | Kein angebotener Schlüssel wurde akzeptiert | Benutzer prüfen, dann den Schlüssel, dann authorized_keys |
Permission denied (keine Abfrage) | Passwort-Auth ist aus; ein Schlüssel muss gehen | Schlüssel nutzen oder über die Provider-Konsole rein |
Host key verification failed | Der Schlüssel des Servers hat sich seit deinem Vertrauen geändert | Über einen anderen Kanal prüfen, dann ssh-keygen -R |
Too many authentication failures | Der Agent hat zu viele Schlüssel angeboten | -o IdentitiesOnly=yes mit -i |
UNPROTECTED PRIVATE KEY FILE | Die Schlüsseldatei ist für andere lesbar | chmod 600 auf den privaten Schlüssel |
Broken pipe | Eine untätige Verbindung wurde gekappt | ServerAliveInterval hinzufügen |
no matching key exchange method | Alter Server, moderner Client | Einen Algorithmus nur für diesen Host wieder aktivieren |
Connection reset by peer | TCP wurde vor dem SSH-Hallo zugeschlagen | fail2ban / MaxStartups prüfen |
Bad configuration option | Dein Client ist zu alt für eine Config-Zeile | ssh aktualisieren oder die Zeile absichern |
did not receive identification string | Etwas hat sich verbunden, aber kein Banner gesendet | Meist ein Scanner; serverseitig ignorieren |
Unspecified GSS failure | Ein Kerberos-Versuch scheiterte, dann Rückfall | Ignorieren, wenn der Login trotzdem klappt |
1. Connection refused
Die Maschine ist erreichbar, aber auf dem Port, an den du geklopft hast, lauscht nichts. Das liegt fast nie an dir:
- sshd läuft nicht –
systemctl status sshdvon einer Konsole aus (VPS-Anbieter haben für genau diesen Moment eine Web-Konsole); - es lauscht auf einem nicht standardmäßigen Port – probier
ssh -p 2222oder prüfe/etc/ssh/sshd_configaufPort; - eine Firewall weist den Port aktiv ab (statt ihn zu verwerfen).
Wenn du den Server gerade eben neu aufgesetzt hast, ist es die Firewall. Wenn es gestern ging, ist sshd abgestürzt oder der Port hat sich geändert.
Komplette Lösung: Connection refused vs. timed out, entschlüsselt.
2. Connection timed out
Anders als refused: Deine Pakete verschwinden. Der Host ist aus, die IP ist falsch oder – am häufigsten auf Cloud-Maschinen – eine Security Group / Netzwerk-ACL verwirft Port 22 stillschweigend. Prüfe zuerst die Firewall-Regeln des Anbieters, dann, ob du in einem Netz bist, das ausgehenden Port 22 blockt (Hotel- und Büro-Gäste-WLANs lieben das; probier zur Bestätigung einen Zugang über Port 443 oder ein anderes Netz).
Komplette Lösung: Dieselbe Anleitung refused vs. timed out hat den Timed-out-Zweig Schritt für Schritt.
3. Permission denied (publickey)
Der ewige Champion. Der Server akzeptiert nur Schlüssel-Auth und hat keinen von dir angebotenen Schlüssel angenommen. Nach Wahrscheinlichkeit geordnet:
- Falscher Benutzer.
ubuntubei Ubuntu-Images,ec2-userbei Amazon Linux,rootauf den meisten blanken VPS. Derselbe Schlüssel mit dem falschen Benutzernamen erzeugt genau diesen Fehler – Cloud-Images wählen jeweils ihren eigenen Login-Benutzer, was die Hälfte des ersten EC2-/VPS-Logins (auf Englisch) ausmacht. - Dein Schlüssel wurde nicht angeboten.
ssh -vzeigt jeden versuchten Schlüssel. Wenn deiner nicht in der Liste steht, verweise explizit darauf:ssh -i ~/.ssh/id_ed25519 user@host. - Der Schlüssel ist nicht auf dem Server. Seine öffentliche Hälfte muss als eine Zeile in
~user/.ssh/authorized_keysstehen – für diesen Benutzer, nicht den von root. - Serverseitige Berechtigungen. sshd berücksichtigt
authorized_keysnicht, wenn das Home-Verzeichnis,~/.ssh(700) oder die Datei selbst (600) für die Gruppe schreibbar ist. Das ist das klassische „Ich habe den Schlüssel kopiert und es geht trotzdem nicht“.
Komplette Lösung: Permission denied (publickey), eine schnelle systematische Lösung (auf Englisch) arbeitet jeden Übeltäter der Reihe nach ab.
4. Permission denied, wenn du eine Passwortabfrage erwartet hast
Wenn du Passwort-Auth wolltest und nie gefragt wurdest, hat der Server PasswordAuthentication no – die meisten Cloud-Images kommen so, und das ist die richtige Voreinstellung. Nutze die Konsole des Anbieters oder deinen vorhandenen Schlüssel, um reinzukommen, und füge dann den neuen Schlüssel ordentlich hinzu, statt Passwörter wieder einzuschalten.
5. Host key verification failed / REMOTE HOST IDENTIFICATION HAS CHANGED
Das gruselige Banner mit der Aura eines ASCII-Totenkopfs. Der Server hat einen anderen Schlüssel präsentiert als den, dem du vorher vertraut hast. Zwei Erklärungen: Die Maschine wurde rechtmäßig neu aufgesetzt/neu installiert (der überwältigend häufige Fall), oder etwas zwischen dir und dem Server gibt sich als er aus (der Fall, für den die Warnung existiert).
Wenn – und nur wenn – du weißt, dass der Server neu aufgesetzt wurde: ssh-keygen -R hostname entfernt den veralteten Eintrag, und die nächste Verbindung vertraut neu. Skripte dieses Entfernen nicht blind in deinen Arbeitsablauf; das eine Mal, in dem die Warnung echt ist, ist sie die einzige, die du bekommst.
Komplette Lösung: Host key verification failed, und wie man es richtig behebt (auf Englisch).
6. Too many authentication failures
Dein Agent hat eifrig sechs Schlüssel angeboten, das MaxAuthTries des Servers sagte: genug. Sag dem Client, nur den Schlüssel anzubieten, den du meinst:
ssh -o IdentitiesOnly=yes -i ~/.ssh/the_right_key user@host…oder mach es pro Host dauerhaft in ~/.ssh/config. Wenn du viele Schlüssel mit dir führst, erspart dir IdentitiesOnly yes unter Host * diesen Fehler für immer.
7. WARNING: UNPROTECTED PRIVATE KEY FILE
Dein privater Schlüssel ist für andere lesbar, und der Client weigert sich, ihn zu nutzen. chmod 600 ~/.ssh/id_ed25519. Unter Windows taucht das nach dem Kopieren von Schlüsseln zwischen Maschinen oder aus einem Cloud-Laufwerk auf – behebe es über die Sicherheitseigenschaften der Datei oder halte Schlüssel ganz aus synchronisierten Ordnern heraus.
8. client_loop: send disconnect: Broken pipe (die Sitzung, die stirbt, sobald du wegschaust)
Untätige Verbindungen, gekappt von einem NAT-Router oder einer aggressiven Firewall zwischen dir und dem Server. Keepalives beheben das clientseitig:
Host *
ServerAliveInterval 30
ServerAliveCountMax 4Zwei Minuten Stille toleriert, Pakete alle 30 Sekunden, damit die NAT-Tabelle dich nie vergisst. Wenn Sitzungen unter Last statt im Leerlauf sterben, ist das ein anderes Tier – sieh dir die MTU an (besonders bei VPNs), nicht die Keepalives.
9. no matching key exchange method found / no matching cipher
Du redest mit etwas Altem – einem Router, einem Switch, einer Appliance, die auf alter Krypto festhängt. Modernes OpenSSH hat diese Algorithmen aus gutem Grund entfernt. Aktiviere sie nur für diesen einen Host wieder, niemals global:
Host ancient-switch
KexAlgorithms +diffie-hellman-group14-sha1
Ciphers +aes256-cbcDie Fehlermeldung nennt die vom Server angebotenen Algorithmen; füge den am wenigsten schlechten hinzu, den sie auflistet.
10. ssh_exchange_identification: read: Connection reset by peer
Die TCP-Verbindung öffnete sich und wurde sofort zugeschlagen, bevor SSH überhaupt Hallo sagte. Übliche Verdächtige: fail2ban oder DenyHosts hat deine IP gesperrt (prüfe /etc/hosts.deny und das fail2ban-Jail von einer Konsole aus), sshd ist überlastet (MaxStartups erschöpft durch einen Scanner, der auf den Port einhämmert), oder der Health-Check eines Load Balancers frisst Verbindungen. Wenn es fail2ban ist und es dein eigener Server ist, besteht die Lösung aus einem Konsolen-Login und fail2ban-client unban <your-ip> – dann bring SSH aus dem Radar der Scanner oder zieh das Jail enger, damit du nicht nächste Woche der Kollateralschaden bist.
11. Bad configuration option: pubkeyacceptedalgorithms
Kein Server-Problem – dein lokales ssh ist zu alt für deine Config-Datei. PubkeyAcceptedAlgorithms kam mit OpenSSH 8.5 (es ersetzte PubkeyAcceptedKeyTypes); gibst du diese Zeile einem älteren Client – einem macOS-ssh gewissen Alters, einer alten Distribution, einem minimalen Container-Image –, weigert es sich, die Datei überhaupt zu parsen. Drei Auswege: Aktualisiere den Client (ssh -V sagt dir, wo du stehst); nutze die alte Schreibweise PubkeyAcceptedKeyTypes, die neuere Versionen noch als Alias akzeptieren; oder sichere die Zeile so ab, dass nur fähige Clients sie lesen:
Match all
# only OpenSSH >= 8.5 gets here via Include ordering– in der Praxis ist die einfachste Absicherung, versionsabhängige Optionen in einer eigenen Datei zu halten, die per Include eingebunden wird, sodass ein alter Client mit denselben Dotfiles sie einfach überspringt. Dieselbe Fehlerform (Bad configuration option: <something>) bedeutet immer dasselbe: Dieses Wort ist dieser Binärdatei unbekannt – prüfe zuerst die Schreibweise der Option, dann die Version der Binärdatei.
12. did not receive identification string / invalid ssh identification string
Beide sitzen am allerersten Schritt von SSH – dem Banner-Austausch, vor jeder Krypto. did not receive identification string from <ip> wird serverseitig von sshd protokolliert, wenn etwas eine TCP-Verbindung zu Port 22 öffnete, aber nie die SSH-2.0-...-Zeile sendete: ein Portscanner, der Health-Check eines Load Balancers, eine Monitoring-Sonde oder ein Client, der aufgab. In deinen Server-Logs ist das fast immer Hintergrundrauschen, kein Fehler – es sei denn, es ist dein Client, der sich nicht verbinden kann; dann frisst etwas auf dem Weg (ein Proxy, ein TCP-Wrapper, ein IDS) das Banner.
kex_exchange_identification: ... invalid ssh identification string ist das Spiegelbild: Etwas hat geantwortet, aber mit Nicht-SSH-Daten. Übliche Ursachen, der Reihe nach: Du hast ssh auf den falschen Port gerichtet – einen HTTP-Server, eine Datenbank, ein Captive Portal, das HTML zurückgibt; eine Middlebox auf dem Weg fängt die Verbindung ab und antwortet anstelle des Servers; oder eine fehlerhafte ProxyCommand/ProxyJump-Konfiguration leitet etwas, das kein SSH-Strom ist, in den Client – die Fehlerseite eines Proxys landet dort, wo ein Banner stehen sollte. Stell sicher, dass du wirklich mit einem sshd redest: nc <host> 22 sollte sofort ein SSH-2.0-OpenSSH...-Banner ausgeben. Gibt es HTML oder nichts aus, ist der Port (oder der Host oder der Proxy-Hop) falsch, nicht dein Schlüssel.
13. Unspecified GSS failure / debug1: unspecified GSS failure. Minor code may provide more information
Kerberos-Rauschen. OpenSSH versucht standardmäßig GSSAPI-(Kerberos-)Auth vor deinem Schlüssel, und wenn du in keinem Kerberos-Realm bist – wie die meisten –, scheitert das und wird auf Debug-Ebene protokolliert, dann fällt es auf Schlüssel-Auth zurück und verbindet sich problemlos. Wenn die Verbindung am Ende klappt, ist diese Zeile harmlos; ignoriere sie. Sie ist nur dann wichtig, wenn du tatsächlich auf Kerberos-SSO setzt und die Auth scheitert; dann ist es ein echtes Ticket-/Realm-Problem (prüfe klist, den Zeitversatz und den SPN des Hosts im DNS). Um das Rauschen in einem Nicht-Kerberos-Setup abzustellen, füge GSSAPIAuthentication no zu deiner Config hinzu.
Mach die Lösungen dauerhaft
Die Hälfte davon sind einmalige Lösungen; die andere Hälfte verdient eine Zeile in ~/.ssh/config, damit sie nie wiederkommt – Keepalives, IdentitiesOnly, Ports und Identitäten pro Host. Config schlägt Gedächtnis.
Das andere, was das Gedächtnis schlägt, ist ein Client, der den Zustand für dich behält. Termalin speichert Einstellungen pro Host – Port, Benutzer, Schlüssel, Keepalives – beim Host selbst, verifiziert Server beim ersten Verbinden und warnt laut, wenn sich ein Fingerabdruck ändert, und seine Statusleiste zeigt die Vitalwerte der Maschine live, sodass „läuft die Kiste überhaupt?“ aufhört, ein Diagnoseschritt zu sein. Der Free-Tarif hat kein Host-Limit – hol es dir und leg ein paar dieser Fehler dauerhaft zu den Akten.