DevOps Wissensdatenbank
DevOps Wissensdatenbank

SSH-Verbindungsverweigerungsfehler schnell beheben

Ein SSH-"Verbindung verweigert"-Fehler kann Ihre Remote-Serververwaltung stoppen. Dieser umfassende Leitfaden beschreibt Schritt für Schritt die Fehlerbehebung, wobei der Schwerpunkt auf kritischen serverseitigen Diagnosen liegt. Lernen Sie, den Status Ihres SSH-Daemons zu überprüfen, Firewall-Regeln (UFW, firewalld) zu überprüfen und zu konfigurieren, `sshd_config`-Einstellungen zu inspizieren und grundlegende Netzwerkverbindungstests durchzuführen. Praktische Befehle und umsetzbare Ratschläge werden bereitgestellt, um das Problem schnell zu lösen und den sicheren Zugriff auf Ihre Systeme wiederherzustellen, damit Sie schnell wieder die Kontrolle haben.

52 Aufrufe

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 Remote-Server. Die Meldung ssh: connect to host <IP_ADDRESS> port 22: Connection refused kann jedoch ein frustrierendes Hindernis darstellen, das Sie daran hindert, auf Ihre wichtigen Systeme zuzugreifen.

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

Den Fehler 'Connection Refused' verstehen

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

Der Status „refused“ weist direkt auf ein serverseitiges Problem hin, das den SSH-Dienst aktiv daran hindert, Verbindungen anzunehmen. Dies beinhaltet typischerweise, dass der SSH-Daemon nicht läuft, eine Firewall die Verbindung blockiert oder eine Fehlkonfiguration innerhalb des SSH-Dienstes selbst vorliegt.

Häufige Ursachen für 'Connection Refused'

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

  • SSH-Daemon (sshd) läuft nicht: Die häufigste Ursache. Der SSH-Serverprozess ist möglicherweise abgestürzt, wurde gestoppt oder konnte beim Start nicht gestartet werden.
  • Firewall blockiert Port 22 (oder benutzerdefinierten Port): Die Firewall des Servers (z.B. UFW, firewalld, iptables) verhindert eingehende Verbindungen auf dem SSH-Port.
  • Falsche SSH-Daemon-Konfiguration: Die Datei sshd_config ist möglicherweise falsch konfiguriert, was dazu führt, dass der SSH-Daemon auf einem anderen Port, einer falschen Netzwerkschnittstelle lauscht oder Verbindungen für bestimmte Benutzer/Methoden ablehnt.
  • Netzwerkverbindungsprobleme (seltener bei 'Refused'): Obwohl bei einem „refused“-Fehler weniger wahrscheinlich, könnte ein grundlegendes Netzwerkproblem manchmal unerwartet auftreten.
  • SELinux- oder AppArmor-Beschränkungen: Sicherheitsverbesserungen wie SELinux oder AppArmor könnten sshd daran hindern, korrekt zu funktionieren, insbesondere nach benutzerdefinierten Konfigurationen oder Systemänderungen.

Schritt-für-Schritt-Anleitung zur Fehlerbehebung

Tauchen wir ein in die praktischen Schritte zur Diagnose und Behebung des Fehlers 'Connection Refused'.

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

Das Erste, was Sie überprüfen sollten, ist, ob der SSH-Server-Daemon (sshd) tatsächlich auf Ihrem Remote-Rechner läuft. Sie benötigen in der Regel 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+):
    bash sudo systemctl status sshd
    Wenn sshd nicht läuft, zeigt die Ausgabe inactive (dead) oder einen ähnlichen Status an.

  2. Den SSH-Daemon starten:
    Wenn der Status inaktiv ist, versuchen Sie, den Dienst zu starten:
    bash sudo systemctl start sshd

  3. SSH-Daemon beim Systemstart aktivieren:
    Um sicherzustellen, dass SSH nach einem Neustart automatisch startet, aktivieren Sie es:
    bash sudo systemctl enable sshd

  4. SSH-Daemon-Protokolle überprüfen:
    Wenn sshd nicht startet, können seine Protokolle entscheidende Hinweise liefern. Für systemd-Systeme:
    bash sudo journalctl -u sshd --since "10 minutes ago"
    Alternativ können Sie die allgemeinen Authentifizierungsprotokolle ü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 Verbindungsablehnungen. Sie könnte den Standard-SSH-Port (22) oder einen benutzerdefinierten Port, den Sie verwenden möchten, blockieren. Sie müssen sicherstellen, dass die Firewall eingehende Verbindungen auf dem SSH-Port zulässt.

  1. Ihre Firewall identifizieren:
    Gängige Firewalls sind:

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

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

    • UFW:
      bash sudo ufw status verbose
      Suchen Sie nach Regeln, die den Datenverkehr auf Port 22 (oder Ihrem benutzerdefinierten SSH-Port) zulassen. Wenn SSH aufgeführt ist, stellen Sie sicher, dass es ALLOWed ist.
    • firewalld:
      bash sudo firewall-cmd --list-all
      Überprüfen Sie die Abschnitte services und ports auf ssh oder port 22/tcp.
    • iptables:
      bash sudo iptables -L -v -n
      Diese Ausgabe kann komplex sein. Suchen Sie nach DROP- oder REJECT-Regeln, die sich auf tcp dpt:22 (oder Ihren benutzerdefinierten Port) in der INPUT-Kette beziehen.

  3. SSH-Port durch die Firewall zulassen:

    • UFW:
      bash 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:
      bash 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 nur temporär, wenn sie nicht gespeichert werden. Es wird generell empfohlen, firewalld oder ufw zu verwenden, falls verfügbar. Für einen schnellen Test (nicht persistent):
      bash 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 bei Neustarts bestehen bleiben sollen.

    Warnung: Seien Sie vorsichtig beim Ändern von Firewall-Regeln, insbesondere wenn Sie sich per SSH mit einem Remote-Server verbinden. Falsche Regeln können Sie dauerhaft aussperren. Verifizieren Sie immer, dass Ihre Änderungen funktionieren, bevor Sie Ihre aktuelle SSH-Sitzung schließen, falls Sie eine offen haben.

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

Die Konfigurationsdatei des SSH-Daemons (/etc/ssh/sshd_config) diktiert, wie der Dienst arbeitet. Fehlkonfigurationen hier können dazu führen, dass Verbindungen abgelehnt 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):
    bash sudo nano /etc/ssh/sshd_config
    Suchen Sie nach den folgenden Direktiven:

    • Port: Dieser gibt den Port an, auf dem sshd lauscht. Stellen Sie sicher, dass er mit dem Port übereinstimmt, mit dem Sie sich von Ihrem Client aus verbinden möchten. Wenn er auskommentiert ist (#), ist der Standardwert Port 22.
    • ListenAddress: Falls vorhanden, gibt dies an, auf welchen IP-Adressen sshd lauschen soll. Wenn er auf eine interne IP (z.B. 127.0.0.1) eingestellt ist und Sie von einem externen Netzwerk aus verbinden, wird die Verbindung abgelehnt. Um auf allen Schnittstellen zu lauschen, ist er 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 im strengsten Sinne keine „Connection refused“ ist (es handelt sich oft um eine „permission denied“ nach der Verbindung), kann es erfolgreiche Anmeldeversuche verhindern.
    • PasswordAuthentication: Wenn auf no gesetzt, ist die Passwort-Authentifizierung deaktiviert und erfordert eine schlüsselbasierte Authentifizierung.

    Tipp: Nachdem Sie Änderungen an sshd_config vorgenommen haben, müssen Sie den SSH-Dienst neu starten, damit diese wirksam werden:
    bash sudo systemctl restart sshd

Schritt 4: Netzwerkverbindung (Grundprüfung)

Obwohl eine „Connection refused“ typischerweise 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. Den Server anpingen:
    Versuchen Sie von Ihrem Client-Rechner aus, die IP-Adresse oder den Hostnamen des Servers anzupingen:
    bash ping <SERVER_IP_ADDRESS_OR_HOSTNAME>
    Wenn der Ping fehlschlägt (100% Paketverlust), haben Sie ein grundlegenderes Netzwerkproblem (z.B. falsche IP, Server offline, Netzwerk-Routing-Problem), das vor SSH behoben werden muss.

  2. nc oder telnet verwenden (vom Client aus):
    Um zu testen, ob der Port aus Sicht des Clients offen ist und lauscht:
    ```bash
    # Mit netcat (nc)
    nc -zv 22

    Mit telnet

    telnet 22
    `` WennncConnection refusedanzeigt odertelnet` sofort beendet wird, bestätigt dies, dass der Server auf diesem Port aktiv ablehnt, was wieder 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 könnten SELinux (Security-Enhanced Linux) oder AppArmor sshd daran hindern, korrekt zu funktionieren, insbesondere wenn Sie einen nicht-standardmäßigen SSH-Port verwenden.

  1. SELinux-Status überprüfen:
    bash sestatus
    Wenn SELinux enforcing ist, müssen Sie möglicherweise seine Richtlinien anpassen, um sshd auf einem benutzerdefinierten Port zuzulassen.
    Um beispielsweise Port 2222 für SSH zuzulassen:
    bash 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 auf CentOS/RHEL).

  2. AppArmor-Status überprüfen:
    bash sudo aa status
    Wenn AppArmor enforcing ist, überprüfen Sie seine Protokolle (/var/log/syslog oder dmesg) auf Ablehnungen im Zusammenhang mit sshd.

Schritt 6: Server-Protokolle erneut überprüfen

Nachdem Sie die vorherigen Schritte versucht haben, überprüfen Sie immer die Server-Protokolle erneut auf neue Fehlermeldungen im Zusammenhang mit sshd. Dies ist Ihre ultimative Informationsquelle 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 hindeuten, warum der Dienst möglicherweise nicht startet, warum Verbindungen abgebrochen werden oder nach anderen relevanten Informationen.

Best Practices zur Vermeidung zukünftiger Probleme

  • Ihr Betriebssystem regelmäßig aktualisieren: Halten Sie das Betriebssystem und die Pakete Ihres Servers, einschließlich openssh-server, auf dem neuesten Stand.
  • Firewall-Regeln testen: Testen Sie Firewall-Regeln immer sofort, nachdem Sie sie implementiert oder geändert haben.
  • sshd_config sichern: Erstellen Sie eine Sicherungskopie (sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak), bevor Sie Änderungen an /etc/ssh/sshd_config vornehmen.
  • Eine Verwaltungskonsole verwenden: Für Cloud-Instanzen sollten Sie wissen, 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.
  • Protokolle überwachen: Überprüfen Sie regelmäßig auth.log- oder secure-Protokolle auf ungewöhnliche Aktivitäten oder hartnäckige Fehler.

Fazit

Der Fehler 'Connection Refused' ist, obwohl frustrierend, in der Regel unkompliziert zu beheben, indem der SSH-Daemon-Status, die Firewall-Regeln und die sshd_config-Datei systematisch überprüft werden. Indem Sie die in dieser Anleitung beschriebenen Schritte befolgen, können Sie die Grundursache effizient diagnostizieren und Ihren sicheren Fernzugriff wiederherstellen. Denken Sie daran, Änderungen immer mit Vorsicht anzuwenden und die Funktionalität zu überprüfen, um sich nicht von Ihrem Server auszusperren.

Mit diesen Fehlerbehebungstechniken sind Sie gut gerüstet, um SSH-Verbindungsprobleme zu bewältigen und die nahtlose Kontrolle über Ihre Remote-Systeme aufrechtzuerhalten. Viel Erfolg beim SSHen!