Fehlerbehebung bei häufigen SSH-Fehlern wegen Berechtigungsverweigerung und Verbindungsproblemen

Secure Shell (SSH) ist das Fundament der Verwaltung entfernter Server und bietet eine verschlüsselte Kommunikation für den Zugriff auf und die Steuerung entfernter Systeme. Obwohl SSH zuverlässig ist, kann die Einrichtung, insbesondere bei schlüsselbasierter Authentifizierung, manchmal zu frustrierenden Verbindungsfehlern führen. Der häufigste Übeltäter ist die gefürchtete Fehlermeldung Permission denied (Zugriff verweigert).

Diese umfassende Anleitung führt Sie durch die Diagnose und Behebung der häufigsten SSH-Fehler. Wir konzentrieren uns speziell darauf, die Grundursachen von Permission denied (publickey) zu verstehen und häufige Fallstricke im Zusammenhang mit Dateiberechtigungen, fehlerhafter Konfiguration und Abweichungen bei der Client-/Server-Einrichtung zu behandeln. Die Beherrschung dieser Schritte zur Fehlerbehebung gewährleistet einen sicheren und zuverlässigen Zugriff auf Ihre entfernte Infrastruktur.

Verständnis des SSH-Authentifizierungsflusses

Bevor Sie Fehler beheben, ist es wichtig zu verstehen, wie SSH Benutzer authentifiziert. Wenn Sie versuchen, eine Verbindung herzustellen, prüft der Server die Anmeldeinformationen normalerweise in der folgenden Reihenfolge (abhängig von der Konfiguration):

Schlüsselbasierte Authentifizierung (Public Key): Der Client präsentiert einen öffentlichen Schlüssel, und der Server prüft, ob der entsprechende private Schlüssel gültig ist und mit einem autorisierten Schlüssel (authorized_keys-Datei) übereinstimmt.
Passwortauthentifizierung: Wenn die Schlüsselauthentifizierung fehlschlägt oder deaktiviert ist, fordert der Server zur Eingabe eines Passworts auf.

Wenn Sie Permission denied erhalten, bedeutet dies fast immer, dass der Server Ihre Anmeldeinformationen in Schritt 1 oder 2 abgelehnt hat.

Diagnose von Verbindungsproblemen: Die Macht des ausführlichen Modus

Das wirksamste Werkzeug zur Diagnose von SSH-Problemen ist die Ausführung des Clients im ausführlichen Modus (Verbose Mode). Durch das Hinzufügen der Flags -v, -vv oder -vvv gibt der Client detaillierte Debugging-Informationen über den Aushandlungsprozess aus.

Verwendung von ausführlichen Flags

Verwenden Sie die folgende Befehlsstruktur:

ssh -vvv user@remote_host

Worauf Sie in der Ausgabe achten sollten:

Schlüsselaustausch: Achten Sie auf Zeilen, die angeben, welche Authentifizierungsmethoden der Client versucht hat (z. B. Offering RSA key: /path/to/id_rsa).
Serverantwort: Achten Sie genau auf die Ablehnungsmeldungen des Servers. Wenn die Ausgabe zeigt, dass der Server Schlüssel überprüft, aber keine Übereinstimmung findet, liegt das Problem wahrscheinlich bei der Schlüsselkonfiguration oder den Berechtigungen auf der Serverseite.
Passwortabfrage: Wenn die Ausgabe die Schlüsselprüfung überspringt und sofort nach einem Passwort fragt, ist die Schlüsselauthentifizierung auf dem Server möglicherweise deaktiviert.

Behebung von `Permission denied (publickey)`

Dieser Fehler besagt ausdrücklich, dass der Server den bereitgestellten öffentlichen Schlüssel abgelehnt hat. Die Lösung liegt in der Regel bei den Berechtigungen oder der Schlüsselpaarung.

1. Überprüfen der Dateiberechtigungen des Schlüssels (Client-Seite)

Aus Sicherheitsgründen sind SSH-Clients sehr streng, was die Berechtigungen für Ihre private Schlüsseldatei (z. B. ~/.ssh/id_rsa) betrifft. Wenn diese Dateien zu offen sind, weigert sich der Client, sie zu verwenden.

Maßnahme (Client): Stellen Sie sicher, dass Ihr privater Schlüssel nur von Ihnen gelesen werden kann.

chmod 600 ~/.ssh/id_rsa

2. Überprüfung der Schlüsselexistenz und der korrekten Schlüsselverwendung

Stellen Sie sicher, dass Sie sich mit der richtigen Identitätsdatei verbinden, insbesondere wenn Sie nicht standardmäßige Schlüssel oder mehrere Schlüsselpaare verwenden.

Maßnahme (Client): Geben Sie den korrekten privaten Schlüssel mit dem Flag -i an.

ssh -i /path/to/your/specific_private_key user@remote_host

3. Berechtigungen und Eigentümerschaft auf der Serverseite

Dies ist die häufigste Fehlerquelle. SSH erzwingt strenge Verzeichnis- und Dateiberechtigungen auf dem Server für den Benutzer, mit dem Sie sich anmelden möchten.

Pfad auf dem Server	Erforderliche Berechtigungen	Eigentümer
`~/.ssh` Verzeichnis	`700` (rwx------)	Benutzer
`~/.ssh/authorized_keys` Datei	`600` (rw-------)	Benutzer

Maßnahme (Server): Melden Sie sich über die Konsole oder Passwortauthentifizierung (falls aktiviert) an und führen Sie diese Befehle aus:

# Verzeichnisberechtigungen festlegen
chmod 700 ~/.ssh

# authorized_keys Berechtigungen festlegen
chmod 600 ~/.ssh/authorized_keys

# Eigentümerschaft überprüfen (ersetzen Sie 'myuser' durch den tatsächlichen Benutzernamen)
chown -R myuser:myuser ~/.ssh

Warnung: Wenn die Berechtigungen des Home-Verzeichnisses des Benutzers (~/) zu offen sind (z. B. für Gruppe oder andere beschreibbar), kann SSH auch aus Sicherheitsgründen fehlschlagen. Streben Sie 755 oder strenger für ~/ an, wenn Probleme weiterhin bestehen.

4. Bestätigen, dass der Schlüssel tatsächlich hinzugefügt wurde

Stellen Sie sicher, dass die öffentliche Schlüsselzeichenfolge auf dem Client exakt mit dem übereinstimmt, was in die ~/.ssh/authorized_keys-Datei des Servers eingefügt wurde. Ein fehlendes Zeichen oder ein nachgestelltes Leerzeichen führt zu einem Authentifizierungsfehler.

Tipp: Wenn Sie einen Schlüssel hinzufügen, verwenden Sie ssh-copy-id, falls verfügbar, da dieser Berechtigungen und Formatierung automatisch handhabt:

ssh-copy-id user@remote_host

Fehlerbehebung bei Problemen mit Konfigurationsdateien (`sshd_config`)

Wenn Schlüssel und Berechtigungen korrekt sind, liegt das Problem häufig in der SSH-Daemon-Konfigurationsdatei, die sich normalerweise auf dem Server unter /etc/ssh/sshd_config befindet.

1. Authentifizierungsmethoden überprüfen

Stellen Sie sicher, dass die schlüsselbasierte Authentifizierung explizit erlaubt ist.

Konfigurationsprüfung: Suchen Sie nach den folgenden Zeilen und stellen Sie sicher, dass sie auskommentiert (#) und korrekt eingestellt sind:

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

2. Status der Passwortauthentifizierung

Wenn Sie sich vorübergehend auf die Passwortanmeldung verlassen, überprüfen Sie, ob diese aktiviert ist. Wenn sie auf no gesetzt ist, müssen Sie Schlüssel verwenden.

PasswordAuthentication yes

3. PermitRootLogin

Wenn Sie versuchen, sich als root anzumelden, stellen Sie sicher, dass dies erlaubt ist. Beste Vorgehensweise ist in der Regel die Anmeldung als Standardbenutzer und die Verwendung von sudo, aber zur Fehlerbehebung können Sie diese Einstellung überprüfen:

PermitRootLogin yes

Wichtiger Schritt: Nach allen Änderungen an /etc/ssh/sshd_config müssen Sie den SSH-Dienst neu starten, damit die Änderungen wirksam werden:
bash sudo systemctl restart sshd # Oder service ssh restart

Weitere häufige Verbindungsfehler

Obwohl Schlüsselprobleme im Vordergrund stehen, können andere Fehler den Zugriff blockieren:

A. Verbindung zeitüberschritten (Connection Timed Out)

Dies bedeutet normalerweise, dass der Client den Server überhaupt nicht erreichen konnte, was auf ein Netzwerkproblem und nicht auf ein Authentifizierungsproblem hindeutet.

Mögliche Ursachen:
* Der Server ist nicht aktiv oder nicht erreichbar.
* Eine Firewall (lokal oder im Netzwerk) blockiert die Verbindung über Port 22 (oder den benutzerdefinierten SSH-Port).
* Falsche IP-Adresse oder Hostname.

Fehlerbehebung: Verwenden Sie ping, um die grundlegende Konnektivität zu überprüfen, und telnet oder nc (netcat), um zu prüfen, ob der Port offen ist:

# Prüfen, ob Port 22 erreichbar ist
telnet remote_host 22

B. Kein Pfad zum Host (No Route to Host)

Ähnlich wie beim Timeout handelt es sich hierbei um ein Problem der Netzwerkinfrastruktur. Der Client kann keinen Pfad zur IP-Adresse des Servers finden. Überprüfen Sie Routing-Tabellen, den VPN-Status oder stellen Sie sicher, dass der Remote-Server über eine gültige aktive Netzwerkschnittstelle verfügt.

C. Server hat unseren Schlüssel abgelehnt (Server Refused Our Key)

Wenn die ausführliche Ausgabe zeigt, dass der Server aktiv Schlüssel ablehnt, Sie aber die Datei authorized_keys überprüft haben, überprüfen Sie die SELinux- oder AppArmor-Sicherheitskontexte auf dem Server. Diese Sicherheitsmodule können Dateiberechtigungen außer Kraft setzen und den SSH-Zugriff blockieren, wenn die Kontexte falsch sind.

Zusammenfassung der besten Vorgehensweisen

Immer den ausführlichen Modus (-vvv) zur Diagnose verwenden.
Sicherheit der Client-Schlüssel: Stellen Sie sicher, dass private Schlüssel auf 600 (chmod 600) eingestellt sind.
Integrität der Serverdateien: Überprüfen Sie, ob ~/.ssh 700 und authorized_keys 600 ist.
Daemon neu starten: Starten Sie sshd immer neu, nachdem Sie /etc/ssh/sshd_config geändert haben.
ssh-copy-id verwenden, wann immer möglich, um die Schlüsselbereitstellung zu automatisieren.