Wiederherstellen, wenn SSH nicht mehr funktioniert

Server Manager spricht mit deinem Server ausschließlich über SSH. Wenn SSH nicht mehr funktioniert, kann Server Manager nicht helfen — es gibt keinen anderen Kanal auf die Maschine. Aber dein Server ist in Ordnung, und du hast andere Wege, wieder hineinzukommen. Dieser Artikel grenzt die häufigsten Symptome ein und zeigt dir die passenden Wege zur Wiederherstellung.

Lies das, bevor du in Panik gerätst. Keines der üblichen „SSH kaputt“-Szenarien bedeutet, dass deine Daten weg sind. Der Server selbst läuft weiter; du kannst dich nur von dort, wo du es normalerweise tust, nicht mehr anmelden. Im schlimmsten Fall stellst du den SSH-Zugang über die Webkonsole deines Cloud-Anbieters wieder her — gleiche Maschine, gleiche Festplatten, gleiche Dateien.

Schritt 1 — Lies die Fehlermeldung in verständlicher Sprache

Wenn du versucht hast, dich über Server Manager zu verbinden, und es fehlgeschlagen ist, zeigt der Dialog Connect bereits eine verständliche Diagnose, was wahrscheinlich schiefgelaufen ist:

Diese Meldung nennt die wahrscheinlichste Ursache. Die folgende Tabelle ordnet die Meldung, die Server Manager dir zeigt, dem nächsten sinnvollen Prüfpunkt zu.

Schritt 2 — Stelle den Zugriff über die Webkonsole deines Anbieters wieder her

Wenn die Diagnose oben auf „auf dem Server selbst ist etwas kaputt“ hindeutet (die meisten Zeilen in der Tabelle), führt der Weg zurück über die Webkonsole deines Cloud-Anbieters — ein browserbasiertes Terminal, das SSH vollständig umgeht. Jeder große Anbieter hat so etwas, nur unter unterschiedlichen Namen:

Sobald du über die Webkonsole drin bist, hast du vollständigen Shell-Zugriff ohne den Weg über SSH — du kannst also reparieren, was SSH blockiert, und danach zu Server Manager zurückkehren.

Die Webkonsole fragt nach dem lokalen Passwort des Servers. Das ist das Passwort auf Betriebssystemebene für deinen Benutzer auf dem Server selbst — normalerweise das, das dein Anbieter dir per E-Mail geschickt hat, oder das Passwort, das du bei der Ersteinrichtung festgelegt hast. Es ist nicht deine Server Manager-Passphrase und auch nicht das Passwort für dein Cloud-Anbieter-Konto. Wenn du nie eines festgelegt und nur einen Schlüssel verwendet hast, führe passwd <user> über den Metadaten-Dienst deines Anbieters aus (DigitalOcean hat „Reset root password“ → sendet ein neues per E-Mail; AWS bietet Passwortzurücksetzung über Systems Manager).

Schritt 3 — Behebe die häufigsten Ursachen

Wenn du über die Webkonsole drin bist, geh diese Punkte durch:

„Ich habe sshd_config bearbeitet und mich ausgesperrt“

Der Klassiker. Du hast etwas in /etc/ssh/sshd_config geändert, sshd neu gestartet und kommst jetzt nicht mehr rein. So stellst du den Zugriff wieder her:

bashsudo sshd -t                                  # aktuelle Konfiguration auf Syntax prüfen
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.broken
sudo nano /etc/ssh/sshd_config                # problematische Änderung rückgängig machen
sudo sshd -t                                  # Syntax erneut prüfen
sudo systemctl restart sshd                   # sauber neu starten

Häufige Dinge, mit denen man sich aussperrt:

• PermitRootLogin no, während du dich als root verbindest → entweder root wieder erlauben oder zuerst einen Nicht-root-Benutzer mit sudo anlegen
• PasswordAuthentication no, bevor du deinen Schlüssel zu ~/.ssh/authorized_keys hinzugefügt hast
• Port 2222 (oder ein anderer Nicht-Standardwert) — der Server läuft noch, lauscht aber woanders; verbinde dich erneut mit dem neuen Port
• AllowUsers alice, wodurch der Benutzer ausgeschlossen wird, mit dem du dich tatsächlich anmeldest

„fail2ban hat meine IP gesperrt“

Wenn du 3–5 Mal hintereinander das falsche Passwort eingegeben hast, blockiert fail2ban (oder sshguard) deine IP oft für 10 Minuten bis eine Stunde. Prüfen und entsperren:

bashsudo fail2ban-client status sshd               # gesperrte IPs anzeigen
sudo fail2ban-client unban <YOUR-IP>           # eigene IP entsperren

Deine aktuelle IP ist die, die curl ifconfig.me von deinem Heimanschluss aus zeigt (nicht vom Server). Um das beim nächsten Mal zu verhindern, füge dich in /etc/fail2ban/jail.local unter ignoreip = hinzu, sobald du wieder drin bist.

„ufw / iptables hat mich ausgesperrt“

Du hast die Firewall aktiviert, ohne Port 22 ausdrücklich zu erlauben:

bashsudo ufw status                                # aktuelle Regeln anzeigen
sudo ufw allow 22/tcp                          # SSH ausdrücklich erlauben
sudo ufw reload

Direkt mit iptables:

bashsudo iptables -L INPUT -n -v                   # anzeigen, was blockiert
sudo iptables -I INPUT -p tcp --dport 22 -j ACCEPT
sudo netfilter-persistent save                 # speichern (Debian/Ubuntu)

„Ich habe meinen eigenen öffentlichen Schlüssel aus authorized_keys entfernt“

Wenn du ~/.ssh/authorized_keys versehentlich geleert hast (oder mit chmod die falschen Rechte gesetzt hast), füge den Schlüssel über die Webkonsole wieder hinzu:

bashmkdir -p ~/.ssh && chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys                    # deinen öffentlichen Schlüssel einfügen, speichern
chmod 600 ~/.ssh/authorized_keys

Der öffentliche Schlüssel ist die kurze, einzeilige Datei, die auf deinem Laptop normalerweise unter ~/.ssh/id_ed25519.pub (oder id_rsa.pub) liegt. Füge die ganze Zeile ein, einschließlich des Präfixes ssh-ed25519 … und des Suffixes user@host.

Wenn du den ursprünglichen öffentlichen Schlüssel nicht mehr hast, erzeuge auf deinem Laptop ein neues Schlüsselpaar:

bashssh-keygen -t ed25519 -C "you@laptop"          # erstellt ~/.ssh/id_ed25519 + .pub
cat ~/.ssh/id_ed25519.pub                       # das hier in authorized_keys einfügen

„Die Firewall meines Anbieters hat sich von selbst geändert“

Sie hat sich nicht von selbst geändert, aber Anbieter passen gelegentlich Standardrichtlinien an. Öffne bei deinem Anbieter die Seite Security List / Network Security Group / Firewall Rules und prüfe, ob Port 22 (oder der Port, auf dem dein SSH lauscht) weiterhin aus dem öffentlichen Internet (0.0.0.0/0) oder aus deinem konkreten IP-Bereich erlaubt ist.

Wenn sich deine IP geändert hat (Heim-ISP, Umzug in eine andere Stadt, Wechsel auf Mobilfunk) und du die Firewall auf deine alte IP eingeschränkt hattest, ist die neue IP blockiert. Erweitere die Regel vorübergehend wieder auf 0.0.0.0/0, komm hinein und schränke sie danach wieder ein, wenn du möchtest.

Schritt 4 — Verbinde dich erneut über Server Manager

Sobald SSH von deinem Terminal aus funktioniert (teste mit ssh -v <user>@<host>), kehre zu Server Manager zurück und klicke auf Connect server. Gib die Zugangsdaten erneut ein, und du bist wieder da, wo du warst. Der Chatverlauf aus der vorherigen Sitzung ist weg (SSH-Sitzungen liegen absichtlich nur im RAM), aber deine Websites und Dienste auf dem Server sind unverändert.

Wenn du den Server gespeichert hast (mit einer Server Manager-Verschlüsselungs-Passphrase), wähle ihn aus dem Dropdown aus, statt alles neu einzugeben.

Optionen für den Notfall

Wenn du selbst über die Webkonsole des Anbieters nicht hineinkommst, hast du immer noch Möglichkeiten:

• Snapshot-Rollback — wenn du einen Snapshot erstellt hast, bevor etwas schiefging (und die meisten Anbieter bieten Snapshots an, manchmal automatisch), stelle diesen Snapshot wieder her. Du verlierst Änderungen seitdem, bekommst aber ein bekanntermaßen funktionierendes System zurück.
• Aus einem Backup neu aufbauen — wenn du ein Server Manager-.tar.gz-Bundle hast (siehe Backups), starte einen frischen Server, installiere Server Manager darauf und nutze den Assistenten Aus einem Backup wiederherstellen. Gleiche Website, neuer Server.
• Festplatte abtrennen und auf einer anderen VM einhängen — fortgeschritten, funktioniert aber bei den meisten Anbietern. Stoppe die defekte VM, trenne ihre Boot-Festplatte, hänge sie als sekundäre Festplatte an eine funktionierende VM an, mounte sie, bearbeite die kaputten Dateien (sshd_config, authorized_keys), hänge sie aus, verbinde sie wieder mit der ursprünglichen VM und starte neu. Die Dokumentation deines Anbieters enthält Schritt-für-Schritt-Anleitungen.

Vorbeugung — bevor du etwas an SSH änderst

Eine kurze Checkliste für die Zeit vor dem Bearbeiten von sshd_config, die vielen Leuten schon eine 2-Uhr-morgens-Panik erspart hat:

1. Öffne eine zweite SSH-Sitzung, bevor du etwas bearbeitest — so bleibt die alte Sitzung aktiv, falls du dich mit der neuen aussperrst, und du kannst zurückrollen.
2. **sudo sshd -t** vor dem Neustart — findet die meisten Syntaxfehler.
3. Teste die neue Konfiguration, ohne sie dauerhaft zu machen. sudo /usr/sbin/sshd -D -p 2222 -f /etc/ssh/sshd_config.new startet einen Test-sshd auf Port 2222 mit einer Test-Konfiguration. Melde dich per SSH mit -p 2222 an, um sie zu prüfen; wenn es funktioniert, tausche danach die Konfiguration aus und starte wirklich neu.
4. Halte den Zugriff auf die Webkonsole deines Anbieters bereit, bevor du anfängst. Öffne den Tab, melde dich an, bestätige, dass die Konsole funktioniert, und beginne erst dann mit dem Bearbeiten.
5. **Führe ufw enable nicht über SSH aus**, ohne vorher sudo ufw allow 22/tcp auszuführen.

Bei Änderungen, die Server Manager über den Chat vornimmt, hält Faro bei jedem Befehl für deine Bestätigung an und schlägt nichts vor, was SSH kaputtmachen würde (keine sshd_config-Änderungen, kein ufw enable ohne ausdrückliche Allow-Regel). Es sind die manuellen nano /etc/ssh/sshd_config-Sitzungen, mit denen sich Leute aussperren.

Häufige Fragen

Habe ich etwas verloren? Nein — deine Dateien, deine Websites und deine Datenbanken sind genau so, wie du sie zurückgelassen hast. SSH ist nur der Kanal; der Server selbst ist unverändert.

Ist der Chatverlauf weg? Ja. SSH-Sitzungen liegen nur im RAM — wenn die Sitzung endet (bei dir oder auf dem Server), wird der Chat zurückgesetzt. Die Arbeit, die der Chat auf dem Server erledigt hat, bleibt aber erhalten: bereitgestellte Websites, bearbeitete Konfigurationen und installierte Dienste bleiben ganz normal bestehen.

Kann ich das komplett vermeiden? Größtenteils. Der Weg über Server Manager ist sicherer (jede Freigabe wird abgefragt; keine sshd_config-Änderungen). Das Risiko entsteht durch manuelle SSH-Sitzungen, in denen du die Konfiguration selbst bearbeitest. Wenn du alles über Server Manager machst, passiert dieses Aussperr-Szenario fast nie.

Mein Server läuft bei einem Anbieter, der in der Tabelle oben nicht aufgeführt ist. Das Prinzip ist universell: Die meisten Anbieter haben irgendeine Form von Out-of-Band-Konsole (VNC, seriell, Web-Shell). Suche in der Dokumentation deines Anbieters nach „console“ oder „rescue mode“. Wenn du physischen Zugriff hast (Homelab), erledigen Monitor + Tastatur denselben Job.

Server Manager sagt „Connection refused“, aber ich habe vor 5 Minuten gerade noch SSH aus meinem Terminal benutzt. Entweder ist sshd abgestürzt (prüfe über die Konsole deines Anbieters: systemctl status sshd), oder fail2ban hat die IP des Server Manager-VPS gesperrt (eine andere als deine Heim-IP — Server Manager läuft in seinem eigenen Rechenzentrum, und dein Server sieht diese IP als Quelle). Setze die ausgehende IP von Server Manager in fail2bans ignoreip = auf die Whitelist oder lockere die Einstellungen für findtime/maxretry.

Was hier NICHT abgedeckt ist

• Wiederherstellung auf Kontoebene (Server Manager-Login vergessen, Passwort für das Cloud-Anbieter-Konto vergessen) — das läuft außerhalb dieses Kanals: Kontowiederherstellung des Anbieters + Passwortzurücksetzung von Server Manager auf der Anmeldeseite.
• Rettung verschlüsselter Festplatten (LUKS-verschlüsseltes Root-Dateisystem, das nicht entsperrt) — anbieterspezifisch; suche in der Dokumentation deines Anbieters nach „rescue mode“ oder „single-user boot“.
• Dauerhaft verlorener SSH-Schlüssel ohne andere Zugriffsmethode — dann ist ein Neuaufbau aus einem Backup der praktikable Weg. Sieh dir Aus einem Backup wiederherstellen und Backups an, um das Gesamtbild zu verstehen.