SSH-Fehler am Ubuntu VPS gezielt eingrenzen

Fehlerbild und tatsächliche Verbindung erfassen

Prüfe Zieladresse, Benutzer und Port. Nutze lokal Bash unter Linux, macOS oder WSL und ersetze Beispieladresse, Benutzer und Schlüsselpfad durch deine Werte. Die ausführliche Ausgabe zeigt, wie weit die Verbindung kommt:

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

ssh -G zeigt die wirksame Client-Konfiguration. Mit -S none vermeidest du, dass eine vorhandene Multiplex-Verbindung das Ergebnis verdeckt. Die Ausgabe von -v kann Pfade und Adressen enthalten; teile sie nur nach entsprechender Prüfung.

Timeout: vor oder nach dem Verbindungsaufbau?

Kommt es vor der Meldung Connection established zum Timeout, prüfe Adresse, Routing und Firewall auf beiden Seiten. Bei einem öffentlichen Cloud-Server gehören öffentliche IP, Internetroute und zugewiesene Sicherheitsregeln dazu.

Tritt die Verzögerung erst nach dem TCP-Verbindungsaufbau auf, ist die reine Portfreigabe nicht mehr die ganze Erklärung. Prüfe die folgenden Protokollschritte, Serverlast und Dienstprotokolle. Öffne nicht vorsorglich sämtliche Ports.

Connection refused: erreichbares Ziel, kein passender Listener

Eine abgelehnte Verbindung kann bedeuten, dass am erreichten Ziel und Port kein Dienst lauscht oder eine Regel aktiv zurückweist. Kontrolliere den tatsächlichen SSH-Port und den Serverzustand über einen anderen funktionierenden Zugang.

Eine geänderte Domainauflösung kann ebenfalls zum falschen Rechner führen. Vergleiche die Ziel-IP mit den Daten der Instanz, bevor du den SSH-Dienst eines anderen Systems veränderst.

Dienst, Socket und Konfiguration auf Ubuntu prüfen

Nutze dafür eine funktionierende Sitzung oder die Anbieter-Konsole. Die Prüfungen berücksichtigen sowohl den Dienst als auch eine mögliche Socket-Aktivierung:

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

Eine inaktive ssh.service allein beweist bei aktiver ssh.socket noch keinen Defekt. Vergleiche Listener und Protokolle. Führe sshd -t vor einer Konfigurationsübernahme aus; lade keine fehlerhafte Konfiguration nach.

Permission denied (publickey): Benutzer und Schlüssel

Prüfe lokal, welcher private Schlüssel angeboten wird. Der entsprechende öffentliche Schlüssel muss beim richtigen Serverbenutzer hinterlegt sein. Ein nicht passender Benutzername erzeugt denselben Eindruck wie ein falscher Schlüssel.

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Prüfe auf dem Server das tatsächliche Home-Verzeichnis, Eigentümer, Rechte und die Fingerprints der hinterlegten öffentlichen Schlüssel:

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

Korrigiere nur den festgestellten Fehler. Lade keinen privaten Schlüssel hoch und verwende kein rekursives chmod auf dem gesamten Home-Verzeichnis. Zusatzregeln wie AllowUsers oder ein abweichender AuthorizedKeysFile-Pfad können ebenfalls relevant sein.

Geänderter Hostschlüssel: Identität vor Korrektur

Eine Neuinstallation kann einen neuen Hostschlüssel erzeugen. Die Warnung kann aber auch auf eine falsche Adresse oder einen unerwarteten Rechner hinweisen. Vergleiche zunächst den Fingerprint des betroffenen Schlüsseltyps über die vertrauenswürdige Konsole.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Erst nach erfolgreichem Vergleich entfernst du den konkreten veralteten Eintrag für Host und gegebenenfalls abweichenden Port aus known_hosts. Lösche nicht die gesamte Datei und umgehe die Prüfung nicht mit StrictHostKeyChecking=no.

Änderung in einer zweiten Sitzung bestätigen

Öffne nach der Korrektur eine neue Verbindung mit den beabsichtigten Zugangsdaten. Prüfe bei einem administrativen Benutzer auch sudo. Schließe den alten Zugang erst, wenn dieser Test funktioniert.

Dokumentiere die konkrete Ursache und Änderung. Für einen neuen Server beschreibt die Einrichtungsanleitung die Reihenfolge; für Dateiverlust brauchst du einen separaten Wiederherstellungsweg.

Fragen und Antworten