Fehlerbehebung bei SSH 'Permission Denied (publickey)' Problemen

Permission denied (publickey) bedeutet, dass der Server erreichbar war, aber keinen Public-Key-Authentifizierungsversuch für den von Ihnen verwendeten Benutzer akzeptiert hat. Das grenzt das Problem ein. Sie debuggen nicht mehr Routing, DNS oder ob der SSH-Port offen ist. Sie debuggen die Identität: den Benutzernamen, den privaten Schlüssel, den Ihr Client angeboten hat, den auf dem Server gespeicherten öffentlichen Schlüssel und die Serverregeln, die entscheiden, ob diese Anmeldung erlaubt ist.

Der schnellste nützliche Befehl ist:

ssh -vvv benutzer@ihre_server_ip

Suchen Sie nach Authenticating to ... as 'benutzer', dann nach Offering public key. Wenn der erwartete Schlüssel nicht angeboten wird, beheben Sie das Problem auf dem Client. Wenn der erwartete Schlüssel angeboten und abgelehnt wird, beheben Sie die serverseitige authorized_keys, die Eigentümerschaft, die Berechtigungen oder die SSH-Daemon-Richtlinie.

Häufige Ursachen für 'Permission Denied (publickey)'

Der Fehler "Permission Denied (publickey)" kann durch mehrere Konfigurationsprobleme verursacht werden. Die Identifizierung der Grundursache erfordert oft die systematische Überprüfung der folgenden Komponenten:

• Falsche Dateiberechtigungen: SSH reagiert aus Sicherheitsgründen sehr empfindlich auf Datei- und Verzeichnisberechtigungen. Falsche Berechtigungen für Ihr lokales ~/.ssh-Verzeichnis, Ihre private Schlüsseldatei oder auf der Serverseite für das ~/.ssh-Verzeichnis und die authorized_keys-Datei können die Authentifizierung verhindern.
• Fehlender oder falscher authorized_keys-Eintrag: Die authorized_keys-Datei des Servers muss den korrekten öffentlichen Schlüssel für den Benutzer enthalten, als der Sie sich anmelden möchten. Wenn der Schlüssel fehlt, fehlerhaft ist oder dem falschen Benutzer zugeordnet ist, schlägt die Authentifizierung fehl.
• Falsche Schlüsselpaarzuordnung: Ihr SSH-Client bietet möglicherweise den falschen privaten Schlüssel an, oder der Server hat den entsprechenden öffentlichen Schlüssel nicht in der authorized_keys-Datei aufgeführt.
• SSH-Agent-Probleme: Wenn Sie einen SSH-Agenten verwenden, ist dieser möglicherweise nicht richtig mit Ihrem privaten Schlüssel geladen oder falsch konfiguriert.
• Serverseitige SSH-Konfiguration: Obwohl weniger häufig für diesen speziellen Fehler, kann die SSH-Daemon-Konfiguration des Servers (sshd_config) spezifische Einschränkungen für die Public-Key-Authentifizierung haben.

Schritt-für-Schritt-Anleitung zur Fehlerbehebung

Lassen Sie uns in die praktischen Schritte eintauchen, um diese Probleme zu diagnostizieren und zu beheben.

1. Überprüfen Sie den lokalen privaten Schlüssel und die Berechtigungen

Ihre lokale SSH-Konfiguration ist der erste Ort, den Sie überprüfen sollten. Stellen Sie sicher, dass Ihr privater Schlüssel zugänglich ist und die korrekten Berechtigungen hat.

Überprüfen der Existenz des privaten Schlüssels

Ihr privater Schlüssel befindet sich oft in ~/.ssh/id_ed25519 oder ~/.ssh/id_rsa, aber viele Teams verwenden projektspezifische Namen. Listen Sie Ihre Schlüssel auf:

ls -la ~/.ssh

Laden Sie keinen privaten Schlüssel hoch oder fügen Sie ihn nicht in authorized_keys ein. Der Server benötigt den Inhalt der .pub-Datei, nicht den privaten Schlüssel.

Überprüfen der lokalen Dateiberechtigungen

Das ~/.ssh-Verzeichnis und Ihre private Schlüsseldatei sollten restriktive Berechtigungen haben, um unbefugten Zugriff zu verhindern.

• ~/.ssh-Verzeichnis: Sollte 700 (drwx------) sein.
• Private Schlüsseldatei (z.B. id_rsa): Sollte 600 (-rw-------) sein.

Verwenden Sie den Befehl chmod, um die korrekten Berechtigungen zu setzen:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa

Tipp: Wenn Sie einen anderen Schlüsselnamen verwenden, ersetzen Sie id_rsa durch den tatsächlichen Namen Ihrer privaten Schlüsseldatei.

Wenn Sie einen bestimmten Schlüssel testen, erzwingen Sie ihn:

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

Dies verhindert, dass Ihr Agent zuerst eine lange Liste nicht zusammenhängender Schlüssel anbietet.

2. Überprüfen Sie die serverseitige authorized_keys-Konfiguration

Dies ist oft der häufigste Übeltäter. Der Server muss Ihren öffentlichen Schlüssel korrekt für den Benutzer aufgeführt haben, als den Sie sich zu authentifizieren versuchen.

Zugriff auf den Server (falls möglich)

Wenn Sie noch über eine andere Methode auf den Server zugreifen können (z.B. Passwort-Authentifizierung, ein anderes Benutzerkonto oder eine Konsole), melden Sie sich an, um die authorized_keys-Datei zu überprüfen.

Überprüfen des Speicherorts der authorized_keys-Datei

Die authorized_keys-Datei befindet sich normalerweise unter ~/.ssh/authorized_keys im Home-Verzeichnis des Benutzers, als den Sie sich anmelden möchten.

Überprüfen der serverseitigen Dateiberechtigungen

Ähnlich wie auf der Client-Seite sind die serverseitigen Berechtigungen entscheidend:

• ~/.ssh-Verzeichnis auf dem Server: Sollte 700 (drwx------) sein.
• authorized_keys-Datei auf dem Server: Sollte 600 (-rw-------) sein.

Stellen Sie sicher, dass diese Berechtigungen auf dem Server korrekt gesetzt sind:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Überprüfen Sie auch die Eigentümerschaft. Das .ssh-Verzeichnis und die authorized_keys-Datei sollten normalerweise dem Konto gehören, mit dem Sie sich anmelden:

chown -R ihrbenutzer:ihrbenutzer ~/.ssh
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Wenn StrictModes in sshd_config aktiviert ist, kann OpenSSH Schlüssel ablehnen, wenn das Home-Verzeichnis oder der .ssh-Pfad von falschen Benutzern beschreibbar ist.

Überprüfen des Inhalts von authorized_keys

Öffnen Sie die Datei ~/.ssh/authorized_keys mit einem Texteditor (z.B. nano, vim). Jeder öffentliche Schlüssel sollte in einer einzigen Zeile stehen. Stellen Sie sicher, dass der öffentliche Schlüssel, den Sie verwenden möchten, vorhanden und korrekt formatiert ist. Er sollte mit ssh-rsa, ssh-ed25519 oder ähnlich beginnen, gefolgt von einer langen Zeichenfolge und optional einem Kommentar.

Beispiel für einen authorized_keys-Eintrag:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD... ihr_public_key_string benutzer@hostname

Fügen Sie Ihren privaten Schlüssel nicht zu authorized_keys hinzu. Nur der öffentliche Schlüssel sollte hier sein.

3. Stellen Sie sicher, dass der richtige öffentliche Schlüssel hinzugefügt wurde

Es ist möglich, dass der falsche öffentliche Schlüssel kopiert wurde oder dass der öffentliche Schlüssel auf dem Server nicht mit Ihrem lokalen privaten Schlüssel übereinstimmt.

Abrufen Ihres lokalen öffentlichen Schlüssels

Ihr öffentlicher Schlüssel ist das Gegenstück zu Ihrem privaten Schlüssel. Sie können ihn mit dem Befehl ssh-keygen anzeigen:

cat ~/.ssh/id_rsa.pub

Dieser Befehl gibt Ihren öffentlichen Schlüssel aus. Vergleichen Sie diese Ausgabe sorgfältig mit dem Eintrag in der ~/.ssh/authorized_keys-Datei des Servers. Selbst ein einzelner Tippfehler oder ein fehlendes Zeichen führt dazu, dass die Authentifizierung fehlschlägt.

Für einen saubereren Vergleich drucken Sie den öffentlichen Schlüssel, der von dem privaten Schlüssel abgeleitet ist, den Sie verwenden möchten:

ssh-keygen -y -f ~/.ssh/id_ed25519_prod

Diese Ausgabe sollte mit einer Zeile in der authorized_keys des entfernten Benutzers übereinstimmen.

Tipp: Eine schnelle Möglichkeit, Ihren öffentlichen Schlüssel hinzuzufügen, wenn Sie Passwortzugriff auf den Server haben, ist die Verwendung von ssh-copy-id.

ssh-copy-id benutzer@ihre_server_ip

Dieser Befehl hängt automatisch Ihren standardmäßigen öffentlichen Schlüssel (~/.ssh/id_rsa.pub) an die Datei ~/.ssh/authorized_keys auf dem entfernten Server an und setzt die korrekten Berechtigungen.

4. Geben Sie den richtigen privaten Schlüssel an (falls nicht standardmäßig)

Wenn Sie einen nicht standardmäßigen privaten Schlüssel verwenden (z.B. ~/.ssh/mein_anderer_schluessel), müssen Sie Ihrem SSH-Client mitteilen, welchen Schlüssel er verwenden soll.

Verwenden des -i-Flags

Sie können die Identitätsdatei (privaten Schlüssel) mit der Option -i angeben:

ssh -i ~/.ssh/mein_anderer_schluessel benutzer@ihre_server_ip

Konfigurieren von ~/.ssh/config

Der Einfachheit halber können Sie Ihren SSH-Client so konfigurieren, dass er für einen bestimmten Host immer einen bestimmten Schlüssel verwendet:

Erstellen oder bearbeiten Sie die Datei ~/.ssh/config auf Ihrem lokalen Rechner und fügen Sie einen Eintrag wie diesen hinzu:

Host ihr_server_alias
  HostName ihre_server_ip_oder_domain
  User ihr_benutzername
  IdentityFile ~/.ssh/mein_anderer_schluessel
  IdentitiesOnly yes

Dann können Sie sich einfach verbinden mit:

ssh ihr_server_alias

5. Überprüfen Sie den Status des SSH-Agenten

Wenn Sie sich auf einen SSH-Agenten verlassen, um Ihre Schlüssel zu verwalten, stellen Sie sicher, dass er läuft und Ihr Schlüssel geladen ist.

Überprüfen, ob der Agent läuft

echo "$SSH_AUTH_SOCK"

Wenn dies einen Pfad ausgibt, läuft der Agent wahrscheinlich. Wenn er leer ist, müssen Sie möglicherweise einen starten.

Hinzufügen des Schlüssels zum Agenten

Wenn Ihr Schlüssel nicht geladen ist, fügen Sie ihn hinzu:

ssh-add ~/.ssh/id_rsa

Wenn Sie nach einer Passphrase gefragt werden, geben Sie sie ein. Sie können überprüfen, welche Schlüssel mit ssh-add -l hinzugefügt wurden.

Wenn ssh-add -l viele nicht zusammenhängende Schlüssel anzeigt und der Server nach mehreren Versuchen die Verbindung trennt, entfernen Sie entweder alte Schlüssel aus dem Agenten oder verwenden Sie IdentitiesOnly yes für diesen Host.

6. Debuggen mit dem ausführlichen Modus

SSH hat einen ausführlichen Modus (-v, -vv oder -vvv für zunehmende Detailstufen), der unschätzbare Hinweise darauf geben kann, wo der Authentifizierungsprozess fehlschlägt.

ssh -vvv benutzer@ihre_server_ip

Untersuchen Sie die Ausgabe auf Nachrichten zur Schlüsselauthentifizierung, zum Anbieten von Schlüsseln und zu Serverantworten. Dies weist oft direkt auf das Problem hin.

Beispiel für einen ausführlichen Ausgabeausschnitt, der einen Publickey-Fehler anzeigt:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: read PEM private key file /home/user/.ssh/id_rsa
debug1: failed to use sshkey: /home/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

Diese Ausgabe bedeutet, dass der Client id_rsa ausprobiert hat, der Server es nicht akzeptiert hat und der Client zur nächsten erlaubten Methode übergegangen ist.

7. Serverseitige Überprüfung der sshd_config (Fortgeschritten)

Überprüfen Sie /etc/ssh/sshd_config und alle Dateien in /etc/ssh/sshd_config.d/. Bestätigen Sie, dass die Public-Key-Authentifizierung aktiviert ist:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Suchen Sie dann nach Match-Blöcken in der Nähe des Endes der Datei. Ein späterer Match User-, Match Group- oder Match Address-Block kann frühere Einstellungen für das genaue Konto, das Sie testen, überschreiben.

Validieren Sie nach jeder Änderung die Syntax, bevor Sie neu laden:

sudo sshd -t
sudo systemctl reload sshd

Einige Systeme verwenden ssh als Dienstnamen anstelle von sshd.

Eine zuverlässige Reihenfolge bei der Fehlerbehebung

Verwenden Sie die ausführliche Ausgabe, um Rätselraten zu vermeiden. Bestätigen Sie zuerst den Benutzernamen. Bestätigen Sie dann, dass der Client den privaten Schlüssel anbietet, den Sie erwarten. Bestätigen Sie dann, dass der passende öffentliche Schlüssel in der authorized_keys des Zielbenutzers vorhanden ist. Überprüfen Sie dann die Eigentümerschaft und die Berechtigungen. Erst wenn diese sauber sind, sollten Sie Zeit mit sshd_config, Match-Blöcken, SELinux-Kontexten oder Kontobeschränkungen verbringen.

Diese Reihenfolge löst die meisten Fälle von Permission denied (publickey), ohne willkürliche Änderungen vorzunehmen, und verhindert, dass Sie die SSH-Sicherheit schwächen, nur um eine dringende Anmeldung zu ermöglichen.