SSH Connection Refused auf Linux-Servern: 5 Prüfschritte

Sie haben gerade einen frischen Linux-VPS hochgefahren – oder es ist 2 Uhr nachts und Ihr Monitoring meldet: SSH ist down. Die Konsole wirft ssh: connect to host … port 22: Connection refused aus, und der Puls geht hoch. Schlimmer noch: kein VNC, keine Cloud-Konsole in Reichweite, nur ein blinkender Cursor.

So etwas sehen wir mehrmals im Monat. Mal hat ein Junior sshd_config geändert und das Reload vergessen. Mal erlaubt die Security Group 80 und 443, aber nicht 22. Mal bannt fail2ban still Ihre Heim-IP nach einer Serie fehlgeschlagener Logins. Die gute Nachricht: Connection refused lässt sich meist eingrenzen – ohne Esoterik. Dieser Leitfaden packt die fünf häufigsten Produktions-Pfade in eine Checkliste. Zuerst die Fehlermeldung lesen, dann Schicht für Schicht vorgehen. In den meisten Fällen finden Sie die Ursache innerhalb von zwanzig Minuten.

Eine Annahme vorweg: Sie haben einen alternativen Zugang – Cloud-VNC, Seriellkonsole oder eine andere Maschine im selben VPC. Wenn Sie komplett ausgesperrt sind, springen Sie zu Wenn Sie völlig ausgesperrt sind.

Vor dem Troubleshooting: Drei „keine Verbindung“-Fehler sind nicht gleich

Viele werfen Connection refused, Connection timed out und Permission denied in einen Topf – und jagen eine Stunde lang das falsche Problem. Laut OpenSSH-Dokumentation zeigt jede Meldung auf eine andere Schicht des Stacks:

Diese Unterscheidung spart echte Zeit. Connection refused heißt: Ihr Paket ist angekommen – das Problem liegt serverseitig oder direkt an der Netzwerkgrenze. Timed out heißt: Etwas dazwischen verschluckt den Traffic; an sshd_config auf einer unerreichbaren Maschine zu drehen, bringt nichts, bis der Pfad stimmt. Permission denied ist fast immer Credentials, Kontorichtlinie oder ein IP-Ban nach erfolgreichem TCP-Handshake.

Im Team: Posten Sie die exakte Fehlerzeichenkette im Incident-Channel. „SSH kaputt“ lädt zu zwölf Vermutungen ein; „Connection refused auf Port 2222 von Büro-IP“ grenzt die Suche sofort ein.

Methode 1: IP, DNS und Port-Erreichbarkeit prüfen (Netzwerkschicht)

Bevor Sie sshd beschuldigen, beweisen Sie, dass die Straße offen ist. Bei frischen VPS-Instanzen sind falsche IPs, noch nicht propagierte DNS-Einträge oder sshd auf einem Nicht-Standard-Port die häufigsten Übeltäter – während Sie noch Port 22 nutzen.

Führen Sie das auf Ihrem lokalen Rechner der Reihe nach aus:

# 1. Confirm resolved IP is correct
                dig +short your.domain.com
                ping -c 3 your.server.ip

                # 2. Probe whether SSH port is open (replace 22 with your actual port)
                nc -zv your.server.ip 22
                # or
                telnet your.server.ip 22

                # 3. Connect with explicit port (avoids ~/.ssh/config surprises)
                ssh -p 22 -i ~/.ssh/id_ed25519 user@your.server.ip

Liefert nc Connection refused, erreichen Pakete den Server – das Problem liegt beim lokalen Dienst oder der lokalen Firewall. Weiter zu Methode 2. Bei timed out oder hängendem Probe priorisieren Sie die Security Group / Network ACL des Cloud-Providers: Erlaubt die Inbound-Regel TCP auf 22 (oder Ihren Custom-Port)? Ist die Quelle 0.0.0.0/0 oder versehentlich auf ein privates Subnetz beschränkt?

Prüfen Sie auch Ihr eigenes Netz. Firmen-VPNs, Uni-Netze und manche ISPs filtern Port 22. sshd vorübergehend auf 443 oder 2222 zu legen ist ein Klassiker: Funktioniert der alternative Port, liegt die Ursache in der Filterung auf dem Weg – nicht am Server selbst.

Bei mehreren Hosts lohnt sich ein Spickzettel mit öffentlichen IPs und SSH-Ports. Copy-Paste-Fehler aus alten Tickets sind überraschend häufig, besonders nach Provider-Migrationen oder neuen Elastic IPs.

Bei hostname-basiertem Zugriff: TTL und Caching nicht vergessen. DNS wurde vielleicht vor fünf Minuten aktualisiert, aber Ihr Laptop oder Resolver zeigt noch auf die alte Adresse. dig +short auf Ihrer Maschine ist die Wahrheit – nicht die Registrar-Oberfläche.

Methode 2: Prüfen, ob der sshd-Dienst läuft

Eine der häufigsten Ursachen für Connection refused: sshd ist nie gestartet, oder der Dienstname hat sich nach einem OS-Upgrade geändert. Unter Ubuntu/Debian heißt die Unit meist ssh; unter RHEL/CentOS/Rocky sshd. Nicht raten – mit Befehlen verifizieren.

Nach Login per VNC oder Cloud-Konsole:

# Debian/Ubuntu
                sudo systemctl status ssh
                sudo systemctl start ssh
                sudo systemctl enable ssh

                # RHEL/CentOS/Rocky
                sudo systemctl status sshd
                sudo systemctl start sshd

                # Is it listening? Which address and port?
                sudo ss -tlnp | grep ssh
                # Expect 0.0.0.0:22 or [::]:22

                # Config syntax check (run after every edit)
                sudo sshd -t
                sudo systemctl reload ssh   # or sshd

Zeigt systemctl status failed, sofort Logs ziehen: sudo journalctl -u ssh -n 50 --no-pager. Typische Fatal Errors: Tippfehler in der Config, fehlende HostKey-Datei, ListenAddress an der falschen Schnittstelle. Nach jeder Änderung immer sshd -t vor dem Reload – blind reloaden, sshd startet nicht, und Sie sperren sich aus: das sehen wir zu oft.

Bei frisch installierten Systemen openssh-server prüfen: sudo apt install openssh-server (Debian-Familie) oder sudo dnf install openssh-server (RHEL-Familie). Minimale Cloud-Images liefern manchmal gar keinen SSH-Server.

Volle Platte kann sshd am Starten oder Annehmen von Sessions hindern. Ein schnelles df -h an der Konsole spart zehn Minuten Remote-Rätselraten. Wurde MaxStartups während einer Brute-Force-Welle zu aggressiv gesetzt, sehen legitime Clients unter Last ebenfalls refused – in journalctl nach „drop connection“ suchen.

Bei mehreren sshd-Versionen nach partiellem Upgrade sollten which sshd und der ExecStart-Pfad der Unit übereinstimmen. Falsche Binaries und Config-Pfade erzeugen verwirrende „gestern ging's noch“-Vorfälle.

Methode 3: Host-Firewall und Cloud-Security-Groups prüfen

sshd läuft, ss zeigt einen Listener – trotzdem refused von außen? Nächster Verdächtiger: Firewall-Regeln, die Traffic droppen oder ablehnen. Linux-Server stapeln meist zwei Schichten: Cloud-Security-Group (außerhalb der NIC) und ufw/iptables/nftables im OS (innen). Beide müssen Ihren SSH-Port erlauben.

Übliche Checks auf dem System:

sudo ufw status verbose
                sudo ufw allow 22/tcp
                sudo ufw allow 2222/tcp   # if you changed the port
                sudo ufw reload

                # firewalld (CentOS, etc.)
                sudo firewall-cmd --list-all
                sudo firewall-cmd --permanent --add-service=ssh
                sudo firewall-cmd --reload

                # Inspect nftables/iptables directly
                sudo iptables -L INPUT -n -v

Cloud-Security-Groups ändern Sie in der Provider-Konsole, wenn SSH down ist – es gibt kein Wunder-CLI vom Laptop. Drei Details: Protokoll TCP, Portbereich enthält Ihren SSH-Port, Quell-CIDR nicht versehentlich auf einen internen Host beschränkt. Zum Testen vorübergehend 0.0.0.0/0 ist in Ordnung; danach auf Ihre Büro-Egress-IP einschränken.

Läuft Docker oder Kubernetes auf dem VPS, werden iptables-Regeln oft automatisch umgeschrieben. sudo iptables-save | grep 22 ausführen und nach DROP/REJECT vor ACCEPT suchen. Für Minimal-Exposure und den SSH-vs.-HTTPS-Port-Tradeoff siehe unser Linux-Minimal-Exposure-Firewall SSH/HTTPS-Entscheidungs-FAQ.

IPv6 wird leicht übersehen: IPv4 in der Security Group gefixt, während ssh user@host AAAA bevorzugt und einen blockierten v6-Pfad trifft. Mit ssh -4 und ssh -6 testen, wenn das Verhalten inkonsistent wirkt.

Dokumentieren Sie, welche Schicht blockiert hat. Teams, die nur ufw fixen und die Security Group vergessen, wiederholen denselben Ausfall beim nächsten „Hardening“.

Methode 4: Port und sshd_config-Einstellungen verifizieren

Viele Admins verlegen SSH von Port 22 oder setzen ListenAddress nur auf interne Interfaces. Clients auf Port 22 sehen refused. Die Server-Config liegt unter /etc/ssh/sshd_config. Wichtige Direktiven (vollständige Referenz in der sshd_config-Manpage):

Port 2222
                # ListenAddress 0.0.0.0   # default: all interfaces; 127.0.0.1 blocks external access
                PermitRootLogin prohibit-password
                PasswordAuthentication no
                AllowUsers deploy admin

Sichere Port-Wechsel-Reihenfolge: neuen Port lauscht bestätigen, Firewall anpassen, dann alten Port schließen. Nicht in einem rücksichtslosen Schritt – „22 auf 2222 und sofort Port 22 in der Security Group zu“ sperrt oft aus, bevor der neue Port verifiziert ist.

Mit aktivem SELinux auf RHEL-Familie nach Portänderung sudo semanage port -a -t ssh_port_t -p tcp 2222 ausführen, sonst bindet sshd evtl. nicht. Ubuntus AppArmor kann Pfade einschränken; Logs sagen es klar.

Auf dem Client ~/.ssh/config auf falschen Port oder HostName prüfen. Bei Host prod-Aliasen ist das Kopieren ohne -p ein Dauerbrenner.

AllowUsers und DenyUsers können verwirren: TCP verbindet, sshd antwortet, dann Auth-Fehler – oder in manchen Setups früher Abbruch. Nach verschärfter Benutzerrichtlinie lokalen Username mit Server-Allow-Liste abgleichen.

Jump Hosts und ProxyJump addieren eine Variable. Refused auf dem letzten Hop kann heißen: Bastion ok, Ziel-Port oder Security Group nicht. Jede Strecke mit nc und ssh -J einzeln testen.

Methode 5: IP-Sperren prüfen (fail2ban / hosts.deny)

Sehen Sie Permission denied statt refused, sind aber sicher, der Key stimmt, verdächtigen Sie einen IP-Ban. fail2ban fügt nach wiederholten Passwortfehlern oder seltsamen Handshakes iptables- oder hosts.deny-Regeln hinzu. Das fail2ban-Wiki erklärt Jail-Mechanik im Detail.

Auf dem Server prüfen:

# fail2ban status
                sudo fail2ban-client status sshd
                sudo fail2ban-client set sshd unbanip YOUR.CLIENT.IP

                # Classic hosts-based bans
                grep -v '^#' /etc/hosts.deny
                grep -v '^#' /etc/hosts.allow

                # Cloud "ops lock" or DDoS mitigation
                # → check provider console for security alerts or temporary IP blocks

Sich selbst zu bannen ist üblich: Skript-Fehler, Dutzende Failed Logins in Sekunden, fail2ban wirft die Büro-Egress-IP ins Jail. Nach Unban Admin-IPs in ignoreip oder Passwort-Auth abschalten und auf Keys setzen, um False Positives zu reduzieren.

Laufen Jenkins, GitLab Runner oder ähnliche Agents mit SSH-Rückverbindung zum VPS, können Registrierungsfehler wie SSH-Komischkeiten wirken. In Hybrid-Topologien verdient der Netzwerkpfad Controller–Agent ein eigenes Diagramm – siehe Jenkins-Hybrid-Topologie: VPS-Controller + Cloud-Mac-JNLP-Enterprise-Pool.

Cloudflare und andere Proxies terminieren SSH auf Port 22 nicht wie HTTP. Wenn Sie den falschen Dienst vorgeschaltet haben oder Bastion-DNS mit App-DNS verwechselt haben: zurücktreten und klären, welcher Hostname SSH überhaupt exponieren soll.

Völlig ausgesperrt: Die Rettungsroute nutzen

Wenn alle fünf Methoden Sie draußen lassen, in dieser Reihenfolge versuchen:

• Cloud-VNC / Seriellkonsole – unabhängig von SSH; direkt einloggen und Config fixen
• Snapshot-Rollback – wenn vor der Änderung gesnappt, schlägt das eine Nachtschicht
• Single-User-Modus / Rescue-Image – Original-Disk mounten, chroot, sshd_config bearbeiten
• Support-Ticket – manche Provider öffnen vorübergehend einen Port oder heben eine Sperre auf

Die Lektion ist einfach: Nie „könnte mich trennen“-Änderungen in Ihrer einzigen SSH-Sitzung. Zweites Terminal offen lassen, tmux nutzen – Firewall- und sshd-Edits sind Hochrisiko.

Nach der Recovery ein Drei-Zeilen-Postmortem: was geändert, welches Signal übersehen, welcher Backup-Zugang geholfen hat. Der nächste On-Call dankt es Ihnen.

Präventions-Checkliste: Den nächsten Stress vermeiden

Zehn Minuten nach dem Incident – günstiger als Panik beim nächsten Mal:

• Key-Login, Passwörter aus; ~/.ssh/authorized_keys Modus 600
• Nicht-Standard-SSH-Port ok – Security Group und sshd_config gemeinsam ändern
• fail2ban-ignoreip für vertrauenswürdige Netze, damit Sie das Team nicht bannen
• sshd -t vor Reload; Snapshot vor riskanten Änderungen
• Monitoring nicht nur „SSH Port 22 up/down“ – Agent oder private Health-Checks

Erwägen Sie eine dedizierte Bastion mit stabiler Egress-IP und engen Security-Groups auf Produktionsknoten. Die Coffee-Shop-IP Ihres Laptops sollte nicht der einzige Schlüssel zum Königreich sein.