SSH-Verbindungsfehler "Connection Refused" schnell beheben

SSH (Secure Shell) ist das Rückgrat der Remote-Serververwaltung und ermöglicht eine sichere und verschlüsselte Kommunikation zwischen Ihrem lokalen Rechner und einem entfernten Server. Allerdings kann der Fehler ssh: connect to host <IP_ADRESSE> port 22: Connection refused ein frustrierendes Hindernis darstellen, das den Zugriff auf Ihre wichtigen Systeme verhindert.

Dieser Artikel bietet eine umfassende Schritt-für-Schritt-Anleitung zur Diagnose und Behebung des häufigen Fehlers "Connection Refused". Wir untersuchen die Hauptursachen, von inaktiven SSH-Daemons über falsch konfigurierte Firewalls bis hin zu falschen Servereinstellungen, und vermitteln Ihnen das Wissen und die Befehle, um schnell wieder Zugriff auf Ihre Server zu erhalten.

Den Fehler "Connection Refused" verstehen

Wenn Sie einen Fehler Connection refused erhalten, bedeutet dies, dass Ihr SSH-Client den entfernten Server erfolgreich erreicht hat, der Server die Verbindung auf dem angegebenen Port jedoch explizit verweigert hat. Dies unterscheidet sich von einem Fehler Connection timed out (bei dem der Client den Server überhaupt nicht erreichen konnte) oder einem Fehler No route to host (bei dem der Netzwerkpfad unterbrochen ist).

Der Status "refused" weist direkt auf ein Problem auf der Serverseite hin, das den SSH-Dienst aktiv daran hindert, Verbindungen anzunehmen. Dies betrifft typischerweise den nicht laufenden SSH-Daemon, eine Firewall, die die Verbindung blockiert, oder eine Fehlkonfiguration innerhalb des SSH-Dienstes selbst.

Häufige Ursachen für "Connection Refused"

Mehrere Faktoren können dazu führen, dass eine SSH-Verbindung verweigert wird. Das Verständnis dieser Faktoren hilft, den Fehlerbehebungsprozess einzugrenzen:

• SSH-Daemon (sshd) läuft nicht: Die häufigste Ursache. Der SSH-Serverprozess könnte abgestürzt, gestoppt oder beim Booten nicht gestartet sein.
• Firewall blockiert Port 22 (oder benutzerdefinierten Port): Die Firewall des Servers (z. B. UFW, firewalld, iptables) verhindert eingehende Verbindungen auf dem SSH-Port.
• Falsche Konfiguration des SSH-Daemons: Die Datei sshd_config könnte falsch konfiguriert sein, sodass der SSH-Daemon auf einem anderen Port, einer falschen Netzwerkschnittstelle lauscht oder Verbindungen für bestimmte Benutzer/Methoden verweigert.
• Netzwerkkonnektivitätsprobleme (weniger häufig bei "Refused"): Obwohl weniger wahrscheinlich für einen "refused"-Fehler, kann ein grundlegendes Netzwerkproblem manchmal unerwartet auftreten.
• SELinux- oder AppArmor-Einschränkungen: Sicherheitserweiterungen wie SELinux oder AppArmor könnten den ordnungsgemäßen Betrieb von sshd verhindern, insbesondere nach benutzerdefinierten Konfigurationen oder Systemänderungen.

Schritt-für-Schritt-Fehlerbehebungsanleitung

Lassen Sie uns in die praktischen Schritte zur Diagnose und Behebung des Fehlers "Connection Refused" eintauchen.

Schritt 1: Überprüfen des SSH-Daemon-Status auf dem Server

Als Erstes sollte überprüft werden, ob der SSH-Server-Daemon (sshd) auf Ihrem entfernten Rechner tatsächlich läuft. Normalerweise benötigen Sie Konsolenzugriff (z. B. über die Konsole eines Cloud-Anbieters oder eine physische Verbindung), um diese Überprüfungen durchzuführen, wenn SSH vollständig unzugänglich ist.

1. SSH-Daemon-Status überprüfen: Auf den meisten modernen Linux-Distributionen (die systemd verwenden, wie Ubuntu, CentOS 7+, Debian 8+):

   sudo systemctl status sshd
   

Auf Debian/Ubuntu kann der Dienst ssh heißen:

sudo systemctl status ssh ``` Wenn sshd nicht läuft, zeigt die Ausgabe inactive (dead) oder einen ähnlichen Status an.

1. SSH-Daemon starten: Wenn der Status inaktiv ist, versuchen Sie, den Dienst zu starten:

   sudo systemctl start sshd
   

Oder auf Debian/Ubuntu:

sudo systemctl start ssh ```

1. SSH-Daemon für automatischen Start beim Booten aktivieren: Um sicherzustellen, dass SSH nach einem Neustart automatisch startet, aktivieren Sie es:

   sudo systemctl enable sshd
   

Oder auf Debian/Ubuntu:

sudo systemctl enable ssh ```

1. SSH-Daemon-Logs überprüfen: Wenn sshd nicht startet, können seine Logs entscheidende Hinweise liefern. Für systemd-Systeme:

   sudo journalctl -u sshd --since "10 minutes ago"
   

Oder, wenn Ihre Distribution die ssh-Einheit verwendet:

sudo journalctl -u ssh --since "10 minutes ago" Alternativ können Sie die allgemeinen Authentifizierungslogs überprüfen: bash sudo tail -f /var/log/auth.log # Oder für RHEL/CentOS: sudo tail -f /var/log/secure ```

Schritt 2: Firewall-Regeln überprüfen

Eine serverseitige Firewall ist oft der Übeltäter für Verbindungsverweigerungen. Sie blockiert möglicherweise den Standard-SSH-Port (22) oder einen benutzerdefinierten Port, den Sie verwenden möchten. Sie müssen sicherstellen, dass die Firewall eingehende Verbindungen auf dem SSH-Port zulässt.

1. Ihre Firewall identifizieren: Häufige Firewalls sind:

   • UFW (Uncomplicated Firewall): Üblich auf Ubuntu/Debian.
   • firewalld: Üblich auf CentOS/RHEL 7+.
   • iptables: Die zugrunde liegende Firewall für Linux, die direkt oder über Frontends konfiguriert wird.

2. Firewall-Status und -Regeln überprüfen:

   • UFW:

     sudo ufw status verbose
     

     Suchen Sie nach Regeln, die Datenverkehr auf port 22 (oder Ihrem benutzerdefinierten SSH-Port) zulassen. Wenn SSH aufgeführt ist, stellen Sie sicher, dass es ALLOWed ist.
   • firewalld:

     sudo firewall-cmd --list-all
     

     Überprüfen Sie die Abschnitte services und ports auf ssh oder port 22/tcp.
   • iptables:

     sudo iptables -L -v -n
     

     Diese Ausgabe kann komplex sein. Suchen Sie nach DROP- oder REJECT-Regeln in Bezug auf tcp dpt:22 (oder Ihren benutzerdefinierten Port) in der INPUT-Kette.

3. SSH-Port in der Firewall zulassen:

   • UFW:

     sudo ufw allow ssh        # Erlaubt Port 22
     # Oder für einen benutzerdefinierten Port (z. B. 2222):
     sudo ufw allow 2222/tcp
     sudo ufw enable           # Wenn UFW inaktiv ist
     

   • firewalld:

     sudo firewall-cmd --permanent --add-service=ssh
     # Oder für einen benutzerdefinierten Port (z. B. 2222):
     sudo firewall-cmd --permanent --add-port=2222/tcp
     sudo firewall-cmd --reload
     

   • iptables: Das direkte Hinzufügen von iptables-Regeln ist komplexer und vorübergehend, sofern nicht gespeichert. Es wird generell empfohlen, firewalld oder ufw zu verwenden, falls verfügbar. Für einen schnellen Test (nicht dauerhaft):

     sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
     sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
     # Sie müssen diese Regeln speichern, wenn sie nach einem Neustart bestehen bleiben sollen.
     

   Warnung: Seien Sie vorsichtig beim Ändern von Firewall-Regeln, insbesondere wenn Sie sich per SSH in einen entfernten Server einloggen. Falsche Regeln können Sie dauerhaft aussperren. Überprüfen Sie immer, ob Ihre Änderungen funktionieren, bevor Sie Ihre aktuelle SSH-Sitzung schließen, falls Sie eine offen haben.

Schritt 3: SSH-Konfiguration überprüfen (sshd_config)

Die Konfigurationsdatei des SSH-Daemons (/etc/ssh/sshd_config) legt fest, wie der Dienst arbeitet. Fehlkonfigurationen hier können dazu führen, dass Verbindungen verweigert werden.

1. sshd_config finden: Die primäre Konfigurationsdatei befindet sich normalerweise unter /etc/ssh/sshd_config.

2. Wichtige Einstellungen überprüfen: Öffnen Sie die Datei mit einem Texteditor (z. B. nano, vi):

   sudo nano /etc/ssh/sshd_config
   

   Suchen Sie nach den folgenden Direktiven:

   • Port: Gibt den Port an, auf dem sshd lauscht. Stellen Sie sicher, dass er mit dem Port übereinstimmt, mit dem Sie von Ihrem Client aus eine Verbindung herstellen möchten. Wenn er auskommentiert ist (#), wird standardmäßig Port 22 verwendet.
   • ListenAddress: Wenn vorhanden, gibt dies an, auf welchen IP-Adressen sshd lauschen soll. Wenn es auf eine interne IP (z. B. 127.0.0.1) gesetzt ist und Sie von einem externen Netzwerk aus eine Verbindung herstellen, wird die Verbindung verweigert. Für das Lauschen auf allen Schnittstellen ist es oft auskommentiert oder auf 0.0.0.0 oder :: (für IPv6) gesetzt.
   • PermitRootLogin: Wenn auf no gesetzt, können Sie sich nicht als root anmelden. Obwohl dies streng genommen keine "connection refused" ist (es ist oft eine Berechtigungsverweigerung nach der Verbindung), kann es erfolgreiche Anmeldeversuche verhindern.
   • PasswordAuthentication: Wenn auf no gesetzt, ist die Passwortauthentifizierung deaktiviert, was eine schlüsselbasierte Authentifizierung erfordert.

   Tipp: Nachdem Sie Änderungen an sshd_config vorgenommen haben, müssen Sie den SSH-Dienst neu starten, damit sie wirksam werden:

   sudo systemctl restart sshd
   

Schritt 4: Netzwerkkonnektivität (grundlegende Überprüfung)

Obwohl eine "connection refused" normalerweise bedeutet, dass der Server erreicht wurde, ist es immer gut, die grundlegende Netzwerkerreichbarkeit von Ihrem Client-Rechner zur IP-Adresse des Servers schnell zu bestätigen.

1. Server anpingen: Versuchen Sie von Ihrem Client-Rechner aus, die IP-Adresse oder den Hostnamen des Servers anzupingen:

   ping <SERVER_IP_ADRESSE_ODER_HOSTNAME>
   

   Wenn Ping fehlschlägt (100% Paketverlust), haben Sie ein grundlegenderes Netzwerkproblem (z. B. falsche IP, Server offline, Netzwerkroutingproblem), das vor SSH behoben werden muss.

2. nc oder telnet verwenden (vom Client): Um zu testen, ob der Port aus Sicht des Clients geöffnet ist und lauscht:

   # Mit netcat (nc)
   nc -zv <SERVER_IP_ADRESSE> 22
   
   # Mit telnet
   telnet <SERVER_IP_ADRESSE> 22
   

   Wenn nc Connection refused anzeigt oder telnet sofort beendet wird, bestätigt dies, dass der Server auf diesem Port aktiv ablehnt, was auf den SSH-Daemon oder die Firewall hindeutet.

Schritt 5: SELinux oder AppArmor überprüfen (Fortgeschritten)

In einigen gehärteten Umgebungen oder nach benutzerdefinierten Konfigurationen kann SELinux (Security-Enhanced Linux) oder AppArmor den ordnungsgemäßen Betrieb von sshd verhindern, insbesondere wenn Sie einen nicht standardmäßigen SSH-Port verwenden.

1. SELinux-Status überprüfen:

   sestatus
   

   Wenn SELinux enforcing ist, müssen Sie möglicherweise seine Richtlinien anpassen, um sshd auf einem benutzerdefinierten Port zu erlauben. Um beispielsweise Port 2222 für SSH zuzulassen:

   sudo semanage port -a -t ssh_port_t -p tcp 2222
   sudo systemctl restart sshd
   

   (Installieren Sie semanage, falls nicht verfügbar: sudo apt install policycoreutils-python-utils auf Debian/Ubuntu, sudo yum install policycoreutils-python-utils oder das passende Paket für Ihre RHEL-Familienversion).

2. AppArmor-Status überprüfen:

   sudo aa status
   

   Wenn AppArmor enforcing ist, überprüfen Sie seine Logs (/var/log/syslog oder dmesg) auf Verweigerungen im Zusammenhang mit sshd.

Schritt 6: Server-Logs erneut überprüfen

Nachdem Sie die vorherigen Schritte versucht haben, überprüfen Sie immer erneut die Server-Logs auf neue Fehlermeldungen im Zusammenhang mit sshd. Dies ist Ihre ultimative Quelle der Wahrheit dafür, was der Server erlebt.

• sudo journalctl -u sshd
• sudo tail -f /var/log/auth.log (oder /var/log/secure)

Suchen Sie nach Nachrichten, die darauf hinweisen, warum der Dienst möglicherweise nicht startet, warum Verbindungen abgewiesen werden, oder andere relevante Informationen.

Best Practices zur Vermeidung zukünftiger Probleme

• Regelmäßiges Aktualisieren Ihres Betriebssystems: Halten Sie das Betriebssystem Ihres Servers und die Pakete, einschließlich openssh-server, auf dem neuesten Stand.
• Firewall-Regeln testen: Testen Sie Firewall-Regeln immer sofort nach der Implementierung oder Änderung.
• sshd_config sichern: Erstellen Sie vor Änderungen an /etc/ssh/sshd_config ein Backup (sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak).
• Verwaltungskonsole verwenden: Wissen Sie bei Cloud-Instanzen, wie Sie auf die Konsole des Servers zugreifen (z. B. AWS EC2 Serial Console, Google Cloud Console), um Netzwerkprobleme zu beheben, wenn SSH nicht verfügbar ist.
• Logs überwachen: Überprüfen Sie regelmäßig die Logs auth.log oder secure auf ungewöhnliche Aktivitäten oder anhaltende Fehler.

Abschließende Erkenntnis

Ein SSH-Verbindungsfehler "Connection refused" bedeutet normalerweise, dass der Server erreichbar ist, aber nichts Ihre Verbindung auf diesem Port akzeptiert. Überprüfen Sie den SSH-Dienstnamen für Ihre Distribution, bestätigen Sie, dass der Port lauscht, öffnen Sie die Firewall, validieren Sie sshd_config und lesen Sie die Logs, bevor Sie größere Änderungen vornehmen. Wenn Sie noch eine funktionierende Sitzung offen haben, halten Sie sie offen, bis eine neue Anmeldung erfolgreich ist.