Fehlerbehebung bei gängigen SSH-Problemen: Verbindung verweigert und Zugriffsverweigerung

Secure Shell (SSH) ist das Fundament der Fernverwaltung von Systemen und bietet eine verschlüsselte Kommunikation für den Zugriff auf Server. Das Auftreten von Verbindungsfehlern kann jedoch die Produktivität sofort unterbrechen. Die beiden häufigsten und frustrierendsten Fehler, denen Benutzer begegnen, sind "Connection Refused" (Verbindung verweigert) und "Permission Denied" (Zugriff verweigert).

Diese Anleitung führt Sie durch einen systematischen Ansatz zur Diagnose und Behebung dieser Probleme. Indem Sie die typischen Ursachen verstehen – von Netzwerkbehinderungen bis hin zu falschen Authentifizierungskonfigurationen – können Sie den sicheren Zugriff auf Ihre entfernten Maschinen schnell wiederherstellen. Wir behandeln wesentliche Prüfungen, von der Überprüfung des Serverstatus bis zur Fehlersuche bei Authentifizierungsmechanismen.

Verstehen der Fehler: Verweigert vs. Zugriff verweigert

Es ist entscheidend, zwischen den beiden primären Fehlermeldungen zu unterscheiden, da sie auf sehr unterschiedliche Grundursachen hinweisen:

Connection Refused (Verbindung verweigert): Dies bedeutet normalerweise, dass die Netzwerkverbindung den Server erreicht hat, aber nichts auf dem angegebenen Port hörte oder das Betriebssystem den Verbindungsversuch aktiv abgelehnt hat.
Permission Denied (Zugriff verweigert): Dies impliziert, dass der SSH-Dienst (sshd) die Verbindungsanfrage erfolgreich erhalten hat, aber der Authentifizierungsversuch (Passwort oder Schlüssel) basierend auf der Serverkonfiguration fehlgeschlagen ist.

Teil 1: Fehlerbehebung bei "Connection Refused"

"Connection Refused" (oft als ssh: connect to host <hostname> port 22: Connection refused gesehen) deutet typischerweise auf ein Problem auf der Serverseite hin, das den Daemon daran hindert, eingehende Verbindungen anzunehmen.

1. Status des SSH-Daemons (sshd) überprüfen

Die häufigste Ursache für die Verweigerung ist, dass der SSH-Serverprozess nicht läuft oder abgestürzt ist.

Maßnahmen (auf dem entfernten Server):

Überprüfen Sie den Dienststatus mit systemctl (üblich auf modernen Linux-Distributionen):

systemctl status sshd

Wenn der Status inactive oder failed anzeigt, starten Sie den Dienst:

sudo systemctl start sshd
# Aktivieren, damit er beim Booten automatisch startet
sudo systemctl enable sshd

2. Abgefragten Port und Konfiguration prüfen

Standardmäßig läuft SSH auf TCP-Port 22. Wenn der Port aus Sicherheitsgründen geändert wurde, müssen Sie den korrekten Port beim Verbinden angeben oder sicherstellen, dass der Server auf dem erwarteten Port lauscht.

A. `sshd_config` überprüfen

Untersuchen Sie die SSH-Konfigurationsdatei, die sich normalerweise unter /etc/ssh/sshd_config befindet. Suchen Sie nach der Port-Direktive:

# /etc/ssh/sshd_config Beispiel
Port 2222  # Wenn dies nicht 22 ist, müssen Sie es clientseitig angeben

Wenn Sie diese Datei ändern, müssen Sie den sshd-Dienst neu starten, damit die Änderungen wirksam werden.

B. Abhorchende Sockets überprüfen

Verwenden Sie ss oder netstat, um zu bestätigen, dass sshd auf der erwarteten Schnittstelle und dem erwarteten Port aktiv lauscht. Wir prüfen hier Port 22:

# Verwendung von ss (bevorzugt auf modernen Systemen)
sudo ss -tuln | grep 22

# Erwartete Ausgabe, die den Lauschen-Status anzeigt:
# LISTEN 0      128    0.0.0.0:22               0.0.0.0:*

Wenn für Port 22 nichts angezeigt wird, läuft der Daemon entweder nicht oder ist so konfiguriert, dass er auf einer anderen Adresse/einem anderen Port lauscht.

3. Firewall- und Netzwerkprüfungen

Eine Firewall, die den Datenverkehr blockiert, bevor er den sshd-Prozess erreicht, führt oft zu einem Timeout, kann sich aber manchmal als Verweigerung äußern. Es ist wichtig, serverseitige Firewall-Regeln zu überprüfen.

Gängige Firewall-Befehle (UFW unter Ubuntu/Debian):

Stellen Sie sicher, dass SSH-Verkehr zugelassen ist:

# Aktuellen Status prüfen
sudo ufw status

# Verkehr auf dem Standardport 22 zulassen
sudo ufw allow ssh
# ODER nach Portnummer
sudo ufw allow 22/tcp

# Firewall-Regeln neu laden
sudo ufw reload

⚠️ Warnung bezüglich externer Firewalls: Wenn Sie von einem entfernten Netzwerk aus eine Verbindung herstellen, stellen Sie sicher, dass alle zwischengeschalteten Netzwerkgeräte, Cloud-Sicherheitsgruppen (wie AWS Security Groups oder Azure NSGs) oder Hardware-Firewalls den Verkehr auf dem SSH-Port explizit zulassen.

Teil 2: Fehlerbehebung bei "Permission Denied"

Wenn Sie erfolgreich eine Verbindung zum Server herstellen, aber sofort "Permission denied (publickey,password)" erhalten, liegt das Problem ausschließlich bei der Authentifizierung.

1. Benutzername und Passwort prüfen

Dies ist die einfachste Prüfung, wird aber oft übersehen:

Benutzername: Verwenden Sie den richtigen Benutzernamen für das Zielsystem? Die Root-Anmeldung ist möglicherweise deaktiviert.
Passwort: Wenn Sie die Passwortauthentifizierung verwenden, überprüfen Sie die Feststelltaste, Tippfehler und stellen Sie sicher, dass das Konto nicht gesperrt ist.

Clientseitige Prüfung: Um detaillierte Debugging-Ausgaben zu sehen, führen Sie Ihren Client mit ausführlichen Flags aus:

ssh -vvv user@hostname

Diese Ausgabe zeigt deutlich an, welche Authentifizierungsmethoden der Client versucht hat und welche der Server abgelehnt hat.

2. Fehler bei der schlüsselbasierten Authentifizierung

Die schlüsselbasierte Authentifizierung ist überlegen, aber Konfigurationsfehler sind häufige Ursachen für die Verweigerung.

A. Falsche Berechtigungen im `.ssh`-Verzeichnis

SSH ist aus Sicherheitsgründen extrem streng bezüglich der Dateiberechtigungen. Wenn die Berechtigungen zu offen sind, ignoriert der Server die Schlüsseldatei vollständig.

Auf dem entfernten Server (Berechtigungen korrigieren):

# Die Berechtigungen des Home-Verzeichnisses des Benutzers sind normalerweise in Ordnung, aber überprüfen Sie den .ssh-Ordner
chmod 700 ~/.ssh

# Die Datei authorized_keys darf nur vom Besitzer beschreibbar sein
chmod 600 ~/.ssh/authorized_keys

B. Schlüssel nicht vorhanden oder falsch formatiert

Stellen Sie sicher, dass Ihr öffentlicher Schlüssel (id_rsa.pub oder ähnlich) korrekt an die ~/.ssh/authorized_keys-Datei des Servers für den Zielbenutzer angehängt ist. Jeder Schlüssel muss auf einer eigenen Zeile stehen, ohne Zeilenumbrüche mitten in der Schlüsselzeichenkette.

C. Serverseitige Konfiguration deaktiviert Schlüssel

Überprüfen Sie /etc/ssh/sshd_config auf dem Server, um sicherzustellen, dass die Schlüsselauthentifizierung erlaubt ist:

PubkeyAuthentication yes

# Stellen Sie sicher, dass die Passwortauthentifizierung nicht deaktiviert ist, wenn Sie sich auf Passwörter verlassen
PasswordAuthentication yes

3. Untersuchung der serverseitigen Protokolle

Wenn die Authentifizierung fehlschlägt, sind die Serverprotokolle die ultimative Wahrheitsquelle. Suchen Sie nach Meldungen, die mit dem fehlgeschlagenen Anmeldeversuch zusammenhängen.

Gängige Protokollspeicherorte:

Debian/Ubuntu: /var/log/auth.log
RHEL/CentOS/Fedora: /var/log/secure

Verwenden Sie grep, um nach neueren Verbindungsversuchen zu filtern:

# Auf RHEL/CentOS-Systemen
sudo grep 'Failed password' /var/log/secure

# Oder suchen Sie nach allgemeiner SSH-Aktivität
sudo tail -f /var/log/secure

Protokollmeldungen geben oft explizit an, warum der Schlüssel abgelehnt wurde (z. B. ungültige Optionen, kein übereinstimmender Schlüssel gefunden oder falscher Benutzerkontext).

Zusammenfassung der Best Practices für zuverlässigen SSH-Zugriff

Verwenden Sie Schlüsselpaare: Deaktivieren Sie die Passwortauthentifizierung (PasswordAuthentication no) in sshd_config, sobald der Schlüsselzugriff verifiziert ist.
Standardport ändern: Verschieben Sie SSH weg von Port 22, um automatisiertes Scan-Rauschen zu reduzieren.
Verwenden Sie PermitRootLogin no: Erzwingen Sie den administrativen Zugriff über normale Benutzer, was die Verwendung von sudo erzwingt.
Konfiguration sichern: Sichern Sie immer die ursprüngliche Datei, bevor Sie wesentliche Änderungen an /etc/ssh/sshd_config vornehmen:
bash sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
Lokal testen: Testen Sie nach Konfigurationsänderungen die Konnektivität lokal auf dem Server (falls möglich), bevor Sie Ihre aktive Sitzung trennen, um sich nicht selbst auszusperren.

Durch systematisches Überprüfen des Dienststatus, des Netzwerkpfads und der Konfigurationsschichten für die Authentifizierung können Sie die frustrierenden Fehler Connection Refused und Permission Denied, die bei der Verwaltung des Fernzugriffs auftreten, schnell beheben.