Fehlerbehebung bei häufigen SSH-Fehlern: Verbindung abgelehnt und verweigert

SSH-Fehler lassen sich leichter beheben, wenn Sie Transportprobleme von Authentifizierungsproblemen trennen. Connection refused bedeutet, dass Ihr SSH-Client einen Host erreicht hat, aber keine TCP-Verbindung auf diesem Port angenommen wurde. Permission denied bedeutet, dass der SSH-Server geantwortet, aber Ihre Anmeldung abgelehnt hat. Dies sind unterschiedliche Vorfälle, auch wenn sie sich beide wie "Ich komme nicht rein" anfühlen.

Behalten Sie eine aktive SSH-Sitzung offen, während Sie Servereinstellungen ändern. Die schmerzhaftesten SSH-Ausfälle treten auf, wenn jemand /etc/ssh/sshd_config bearbeitet, den Dienst neu startet, die Verbindung trennt und erst dann feststellt, dass die neue Konfiguration jeden Anmeldepfad blockiert.

Die Fehler verstehen: Abgelehnt vs. Verweigert

Lesen Sie die genaue Client-Nachricht, bevor Sie etwas ändern:

Connection refused: Der Host hat die TCP-Verbindung aktiv abgelehnt, normalerweise weil sshd nicht auf diesem Port lauscht oder eine Firewall sie ablehnt.
Connection timed out: Pakete werden verworfen oder der Netzwerkpfad ist unterbrochen. Dies ist wahrscheinlicher auf eine Firewall, Route, VPN, Sicherheitsgruppe oder falsche IP zurückzuführen.
Permission denied (publickey): Der Server ist erreichbar, hat aber Ihren Schlüssel nicht akzeptiert.
Permission denied (publickey,password): Der Server hat eine oder mehrere Authentifizierungsmethoden versucht und abgelehnt.
Host key verification failed: Ihr Client vertraut der Serveridentität nicht, die derzeit für diesen Hostnamen oder diese IP präsentiert wird.

Teil 1: Fehlerbehebung bei Verbindung abgelehnt

ssh: connect to host example port 22: Connection refused weist normalerweise auf den entfernten Host oder Port hin. Die Maschine hat geantwortet, aber SSH hat dort keine Verbindungen angenommen.

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

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

Umsetzbare Schritte (auf dem entfernten Server):

Auf vielen Linux-Distributionen heißt der Dienst sshd; auf Debian und Ubuntu heißt er oft ssh. Versuchen Sie den, den Ihr System verwendet:

systemctl status sshd
systemctl status ssh

Wenn der Dienst inaktiv ist oder fehlgeschlagen ist, starten Sie ihn:

sudo systemctl start sshd
sudo systemctl enable sshd

Wenn sshd nach einer Konfigurationsänderung nicht startet, validieren Sie die Konfiguration:

sudo sshd -t

Dieser Befehl ist eine der sichersten Überprüfungen, die Sie ausführen können, bevor Sie SSH neu starten.

2. Überprüfen Sie den Listening-Port und die Konfiguration

Standardmäßig verwendet SSH den TCP-Port 22, aber viele Server verwenden einen anderen Port. Wenn der Server auf 2222 lauscht, muss der Client-Befehl diesen enthalten:

ssh -p 2222 [email protected]

A. Überprüfen Sie `sshd_config`

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

Führen Sie nach dem Bearbeiten der Datei sudo sshd -t aus, bevor Sie neu laden. Wenn die Syntax gültig ist, laden Sie den Dienst neu oder starten Sie ihn neu. Neu laden ist in der Regel weniger störend:

sudo systemctl reload sshd

B. Überprüfen Sie die Listening-Sockets

Verwenden Sie ss, um zu bestätigen, dass sshd lauscht:

sudo ss -tuln | grep 22

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

Wenn SSH nur auf 127.0.0.1:22 lauscht, können sich entfernte Clients nicht verbinden. Wenn es auf 0.0.0.0:22 oder einer bestimmten privaten Schnittstellenadresse lauscht, ist ein Fernzugriff je nach Firewall-Regeln möglicherweise möglich.

3. Firewall- und Netzwerkprüfungen

Eine Firewall, die Pakete verwirft, verursacht normalerweise eine Zeitüberschreitung. Eine Firewall, die Pakete ablehnt, kann eine Ablehnung verursachen. Überprüfen Sie sowohl die Host-Firewall als auch alle Netzwerk-Firewalls außerhalb des Hosts.

Häufige Firewall-Befehle (UFW auf Ubuntu/Debian):

Stellen Sie sicher, dass SSH-Verkehr erlaubt ist:

# Aktuellen Status überprüfen
sudo ufw status

# Verkehr auf Standard-Port 22 erlauben
sudo ufw allow ssh
# ODER nach Portnummer
sudo ufw allow 22/tcp

# Firewall-Regeln neu laden
sudo ufw reload

Cloud-Sicherheitsgruppen, Netzwerk-ACLs, VPN-Routen und Büro-Firewalls können SSH blockieren, bevor der Verkehr den Server erreicht. Wenn sshd lauscht und die Host-Firewall geöffnet ist, testen Sie von einer Maschine im selben privaten Netzwerk. Das sagt Ihnen, ob das Problem lokal auf dem Server oder irgendwo auf dem externen Pfad liegt.

Teil 2: Fehlerbehebung bei Zugriff verweigert

Wenn der Server mit Permission denied antwortet, funktioniert der Netzwerkpfad. Konzentrieren Sie sich auf Benutzername, zulässige Authentifizierungsmethoden, Schlüssel, Kontostatus und Dateiberechtigungen.

1. Überprüfen Sie Benutzername und Passwort

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

Benutzername: Cloud-Images verwenden oft spezifische Benutzer wie ubuntu, ec2-user, admin, debian oder rocky. root ist möglicherweise deaktiviert.
Passwort: Wenn die Passwort-Authentifizierung aktiviert ist, überprüfen Sie Tippfehler, Kontosperrung, abgelaufene Passwörter und PAM-Regeln.
Port und Host: Eine überraschende Anzahl von Authentifizierungsfehlern wird dadurch verursacht, dass eine Verbindung zum falschen Server hergestellt wird, der zufällig SSH ausführt.

Clientseitige Überprüfung: Um eine detaillierte Debug-Ausgabe zu sehen, führen Sie Ihren Client mit ausführlichen Flags aus:

ssh -vvv user@hostname

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

2. Fehler bei der schlüsselbasierten Authentifizierung

Die Schlüsselauthentifizierung schlägt fehl, wenn der Client den falschen privaten Schlüssel anbietet, der Server nicht über den passenden öffentlichen Schlüssel verfügt, die Berechtigungen zu offen sind oder sshd_config die Anmeldung blockiert.

A. Falsche Berechtigungen im `.ssh`-Verzeichnis

SSH ist aus Sicherheitsgründen äußerst streng mit 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 Eigentümer beschreibbar sein
chmod 600 ~/.ssh/authorized_keys

Überprüfen Sie auch den Besitzer:

chown -R "$USER:$USER" ~/.ssh

Auf dem Server ist StrictModes häufig aktiviert. Wenn das Home-Verzeichnis, das .ssh-Verzeichnis oder die Datei authorized_keys von anderen Benutzern beschreibbar ist, ignoriert sshd möglicherweise den Schlüssel.

B. Schlüssel nicht vorhanden oder falsch formatiert

Stellen Sie sicher, dass sich der öffentliche Schlüssel in ~/.ssh/authorized_keys des Zielbenutzers befindet, ein Schlüssel pro Zeile. Der private Schlüssel bleibt auf Ihrem Client. Fügen Sie den privaten Schlüssel nicht in authorized_keys ein.

Erzwingen Sie vom Client aus einen bestimmten Schlüssel beim Debuggen:

ssh -i ~/.ssh/id_ed25519 -vvv [email protected]

Suchen Sie in der ausführlichen Ausgabe nach Zeilen, die anzeigen, welche Schlüssel angeboten wurden und warum der Server sie akzeptiert oder abgelehnt hat.

C. Serverkonfiguration 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 Passwort-Authentifizierung nicht deaktiviert ist, wenn Sie sich auf Passwörter verlassen
PasswordAuthentication yes

Wenn AllowUsers, AllowGroups, DenyUsers oder DenyGroups vorhanden sind, können sie eine scheinbar gültige Schlüsseleinrichtung außer Kraft setzen. Ein Benutzer mit dem richtigen Schlüssel kann durch diese Direktiven dennoch blockiert werden.

3. Serverseitige Protokolluntersuchung

Serverprotokolle sagen Ihnen normalerweise den wahren Grund für eine Ablehnung. Halten Sie ein Terminal auf dem Server offen und beobachten Sie die Protokolle, während Sie versuchen, sich vom Client aus anzumelden.

Häufige Protokollspeicherorte:

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

Verwenden Sie grep, um nach aktuellen 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

Auf Systemen mit systemd-Journaling ist dies oft einfacher:

sudo journalctl -u sshd -f
sudo journalctl -u ssh -f

Protokollmeldungen können "bad ownership or modes", "user not allowed", "invalid user", "authentication refused" oder PAM-Kontofehler anzeigen. Diese Meldungen sind zuverlässiger als das Raten von der Client-Seite allein.

Fehler bei der Host-Key-Überprüfung

Host key verification failed ist nicht dasselbe wie ein falsches Passwort oder ein falscher Schlüssel. Es bedeutet, dass Ihr Client eine gespeicherte Serveridentität für diesen Hostnamen oder diese IP hat und der Server jetzt eine andere Identität präsentiert. Dies kann nach einem Neubuild, einer IP-Wiederverwendung, einer Lastverteileränderung oder einem echten Man-in-the-Middle-Risiko passieren.

Löschen Sie die Warnung in einer Produktionsumgebung nicht blind. Überprüfen Sie den Server-Fingerprint über Ihre Cloud-Konsole, das Konfigurationsmanagement oder einen vorhandenen vertrauenswürdigen Kanal. Sobald Sie wissen, dass die Änderung erwartet wird, entfernen Sie den alten Eintrag:

ssh-keygen -R example.com
ssh-keygen -R 192.0.2.10

Stellen Sie dann erneut eine Verbindung her und akzeptieren Sie den neuen Host-Key nur, wenn der Fingerprint Ihren Erwartungen entspricht.

Zusammenfassung der bewährten Methoden für zuverlässigen SSH-Zugriff

Verwenden Sie Schlüsselpaare: Deaktivieren Sie die Passwort-Authentifizierung erst, nachdem Sie den Schlüsselzugriff in einer zweiten Sitzung getestet haben.
Beschränken Sie, wer sich anmelden kann: Verwenden Sie AllowUsers oder AllowGroups, wenn angemessen, aber dokumentieren Sie es, damit zukünftige Betreiber nicht falschen Berechtigungsproblemen nachjagen.
Verwenden Sie PermitRootLogin no: Bevorzugen Sie normale Benutzer mit sudo.
Sichern Sie die Konfiguration: Kopieren Sie sie, bevor Sie /etc/ssh/sshd_config ändern:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F) ``` 5. Validieren Sie vor dem Neuladen: Führen Sie sudo sshd -t aus. 6. Halten Sie einen Notfallpfad bereit: Wissen Sie bei Cloud-Servern, wie Sie die serielle Konsole, den Rettungsmodus, die Instanzverbindungsfunktion oder das Konfigurationsmanagement verwenden, falls SSH ausfällt.

Der kürzeste Weg durch die SSH-Fehlerbehebung ist: Identifizieren Sie den genauen Fehler, beweisen Sie, ob der Server lauscht, beweisen Sie, ob der Netzwerkpfad diesen Port erreicht, und lesen Sie dann die Serverprotokolle auf Authentifizierungsfehler. Raten dauert in der Regel länger, als diese Prüfungen der Reihe nach durchzuführen.