Fehlerbehebung bei häufigen SSH-Fehlern 'Permission Denied' und Verbindungsproblemen

Ein SSH-Fehler Permission denied bedeutet normalerweise, dass der Server erreichbar war, aber die Authentifizierung verweigert hat. Dies unterscheidet sich von Connection timed out, Connection refused oder No route to host. Wenn Sie alle diese Fehler als "SSH ist defekt" behandeln, verschwenden Sie Zeit. Beginnen Sie daher damit, Authentifizierungsfehler von Netzwerkfehlern zu trennen.

Führen Sie den fehlschlagenden Befehl mit ausführlicher Protokollierung aus:

ssh -vvv benutzer@remote_host

Sie suchen nach klaren Hinweisen: welchen Benutzernamen der Client verwendet hat, welche Schlüsseldateien angeboten wurden, ob der Server einen Schlüssel akzeptiert hat und welche Authentifizierungsmethoden übrig bleiben. Die meisten der folgenden Korrekturen ergeben sich aus dem Abgleich dieser Hinweise mit dem serverseitigen Zustand.

Verstehen des SSH-Authentifizierungsablaufs

Wenn Sie versuchen, eine Verbindung herzustellen, erlaubt der Server nur die in seiner Konfiguration aktivierten Authentifizierungsmethoden. Ein typischer Server versucht zuerst die Public-Key-Authentifizierung und kann danach die Passwort-Authentifizierung erlauben, abhängig von der Richtlinie:

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

Wenn Sie Permission denied erhalten, hat die TCP-Verbindung funktioniert. Der Server hat lediglich die von Ihnen für diesen Benutzer vorgelegten Anmeldeinformationen nicht akzeptiert.

Diagnose von Verbindungsproblemen: Die Macht des ausführlichen Modus

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

Verwendung ausführlicher Flags

Verwenden Sie die folgende Befehlssyntax:

ssh -vvv benutzer@remote_host

Worauf Sie in der Ausgabe achten sollten:

Benutzername: Suchen Sie nach Authenticating to ... as 'user'. Ein falscher Linux-Benutzername ist einer der am leichtesten zu übersehenden Fehler.
Angebotene Schlüssel: Suchen Sie nach Offering public key. Wenn der erwartete Schlüssel nie erscheint, korrigieren Sie die Client-Konfiguration.
Serverantwort: Wenn jedem angebotenen Schlüssel Authentications that can continue folgt, hat der Server diese Schlüssel abgelehnt.
Authentifizierungsmethoden: Wenn publickey nicht aufgeführt ist, erlaubt der Server möglicherweise keine Schlüsselauthentifizierung für dieses Konto oder diesen Host-Block.

Behebung von `Permission denied (publickey)`

Dieser Fehler gibt explizit an, dass der Server den bereitgestellten öffentlichen Schlüssel abgelehnt hat. Die Lösung liegt normalerweise in den Berechtigungen oder der Schlüsselpaarung.

1. Überprüfen der Schlüsseldateiberechtigungen (Client-Seite)

Aus Sicherheitsgründen sind SSH-Clients sehr streng in Bezug auf die Berechtigungen Ihrer privaten Schlüsseldatei (z. B. ~/.ssh/id_rsa). Wenn diese Dateien zu offen sind, weigert sich der Client, sie zu verwenden.

Stellen Sie sicher, dass Ihr privater Schlüssel nur von Ihnen lesbar ist:

chmod 600 ~/.ssh/id_rsa

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

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

Geben Sie den richtigen privaten Schlüssel mit dem Flag -i an:

ssh -i /pfad/zu/ihrem/spezifischen_privaten_schluessel benutzer@remote_host

Wenn Ihr Agent viele Schlüssel geladen hat, fügen Sie für diesen Test IdentitiesOnly=yes hinzu:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod benutzer@remote_host

3. Serverseitige Berechtigungen und Eigentümerschaft

Dies ist die häufigste Ursache für Fehler bei der Schlüsselauthentifizierung. 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

Melden Sie sich über die Konsole, die Cloud-Serienkonsole, die Passwortauthentifizierung oder ein anderes Administratorkonto an und führen Sie diese Befehle als Zielbenutzer oder mit dem richtigen Pfad aus:

# Verzeichnisberechtigungen setzen
chmod 700 ~/.ssh

# Berechtigungen für authorized_keys setzen
chmod 600 ~/.ssh/authorized_keys

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

Wenn das Home-Verzeichnis des Benutzers für die Gruppe oder andere schreibbar ist, kann OpenSSH den Schlüssel auch ablehnen, wenn StrictModes aktiviert ist. Überprüfen Sie mit:

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Für die meisten normalen Benutzer-Home-Verzeichnisse ist 755 oder strenger in Ordnung.

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

Stellen Sie sicher, dass der öffentliche Schlüssel auf dem Client mit dem übereinstimmt, was in die ~/.ssh/authorized_keys-Datei des Servers eingefügt wurde. Ein fehlendes Zeichen, eine umgebrochene Zeile oder ein kopierter privater Schlüssel führt zu einem Authentifizierungsfehler.

Verwenden Sie beim Hinzufügen eines Schlüssels ssh-copy-id, wenn der Passwortzugriff noch verfügbar ist:

ssh-copy-id benutzer@remote_host

Fehlerbehebung bei Konfigurationsdateiproblemen (`sshd_config`)

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

1. Überprüfen der Authentifizierungsmethoden

Stellen Sie sicher, dass die Public-Key-Authentifizierung explizit erlaubt ist.

Konfigurationsüberprüfung: Suchen Sie nach den folgenden Zeilen und stellen Sie sicher, dass sie nicht auskommentiert (#) und korrekt gesetzt sind:

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

Überprüfen Sie auch auf Match-Blöcke in der Nähe des Dateiendes. Eine globale Einstellung erlaubt möglicherweise öffentliche Schlüssel, während ein späterer Match User-, Match Group- oder Match Address-Block sie für den genauen von Ihnen getesteten Login deaktiviert.

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. Best Practice ist es, sich als normaler Benutzer anzumelden und sudo zu verwenden, aber zur Fehlerbehebung können Sie diese Einstellung überprüfen:

PermitRootLogin prohibit-password

Für die Root-Anmeldung standardmäßig viele Systeme auf schlüsselbasierten Root-Zugriff oder deaktivieren die Root-Anmeldung vollständig. Bevorzugen Sie einen normalen Benutzer mit sudo. Wenn Sie SSH-Daemon-Einstellungen ändern müssen, validieren Sie die Syntax vor dem Neuladen:

sudo sshd -t
sudo systemctl reload sshd  # Einige Systeme verwenden: sudo systemctl reload ssh

Andere häufige Verbindungsfehler

Während Schlüsselprobleme primär sind, können andere Fehler den Zugriff blockieren:

A. Connection Timed Out

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

Mögliche Ursachen:

Der Server ist ausgefallen oder nicht erreichbar.
Eine Firewall (lokal oder im Netzwerk) blockiert die Verbindung auf Port 22 (oder einem benutzerdefinierten SSH-Port).
Falsche IP-Adresse oder falscher Hostname.

Verwenden Sie ping für einen grundlegenden Erreichbarkeitshinweis und nc, um den SSH-Port zu überprüfen:

nc -vz remote_host 22

B. No Route to Host

Ähnlich wie Timeout ist dies ein Problem der Netzwerkinfrastruktur. Der Client kann keinen Pfad zur IP-Adresse des Servers finden. Überprüfen Sie Routing-Tabellen, VPN-Status oder stellen Sie sicher, dass der entfernte Server über eine aktive Netzwerkschnittstelle verfügt.

C. Server Refused Our Key

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

Eine praktische Reihenfolge, die normalerweise funktioniert

Überprüfen Sie zuerst den Benutzernamen. Erzwingen Sie dann den erwarteten Schlüssel mit ssh -o IdentitiesOnly=yes -i .... Wenn der Client den richtigen Schlüssel anbietet und der Server ihn ablehnt, überprüfen Sie authorized_keys, die Eigentümerschaft und die Berechtigungen auf dem Server. Wenn der Schlüssel nie angeboten wird, korrigieren Sie Ihre lokale ~/.ssh/config, den Agenten oder den Schlüsselpfad. Wenn die Verbindung nie die Authentifizierung erreicht, wechseln Sie zur Netzwerk-Fehlerbehebung, anstatt Schlüsseldateien zu ändern.