Behebung von SSH-Problemen: Zugriff verweigert (Publickey)

Fehlerbehebung bei SSH-Problemen: 'Permission Denied (publickey)'

Beim Versuch, über SSH eine Verbindung zu einem Remote-Server herzustellen, kann der Fehler "Permission Denied (publickey)" ein frustrierendes Hindernis darstellen. Dieser Fehler weist spezifisch darauf hin, dass der Server Ihre Verbindung abgelehnt hat, weil er Sie nicht mithilfe Ihres öffentlichen Schlüssels authentifizieren konnte. Im Gegensatz zur passwortbasierten Authentifizierung basiert die Public-Key-Kryptographie auf einem Schlüsselpaar: einem privaten Schlüssel, der geheim auf Ihrem lokalen Rechner aufbewahrt wird, und einem öffentlichen Schlüssel, der auf dem Server platziert wird. Dieser Leitfaden führt Sie durch die häufigsten Ursachen dieses Fehlers und bietet detaillierte Schritte zur Diagnose und Behebung, um einen sicheren und nahtlosen SSH-Zugriff zu gewährleisten.

Das Verständnis des SSH-Public-Key-Authentifizierungsprozesses ist entscheidend für eine effektive Fehlerbehebung. Wenn Sie versuchen, eine Verbindung herzustellen, präsentiert Ihr SSH-Client dem Server Ihren öffentlichen Schlüssel. Der Server prüft dann, ob dieser öffentliche Schlüssel für Ihr Benutzerkonto autorisiert ist. Wenn ja, verschlüsselt der Server eine Challenge mit Ihrem öffentlichen Schlüssel und sendet sie zurück. Ihr Client, der den entsprechenden privaten Schlüssel besitzt, entschlüsselt die Challenge und sendet die Antwort zurück an den Server. Ist die Antwort korrekt, ist die Authentifizierung erfolgreich. Ein Fehler "Permission Denied (publickey)" bedeutet, dass dieser Austausch an irgendeinem Punkt fehlgeschlagen ist.

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

Der Fehler "Permission Denied (publickey)" kann aus mehreren Konfigurationsproblemen resultieren. Die Identifizierung der Ursache erfordert oft eine systematische Überprüfung der folgenden Komponenten:

• Falsche Dateiberechtigungen: SSH ist aus Sicherheitsgründen sehr empfindlich gegenüber Datei- und Verzeichnisberechtigungen. Falsche Berechtigungen im lokalen ~/.ssh-Verzeichnis, der privaten Schlüsseldatei oder im serverseitigen ~/.ssh-Verzeichnis und der 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 formatiert 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-Agent verwenden, ist er möglicherweise nicht richtig mit Ihrem privaten Schlüssel geladen oder falsch konfiguriert.
• Serverseitige SSH-Konfiguration: Obwohl seltener für diesen spezifischen Fehler, kann die SSH-Daemon-Konfiguration des Servers (sshd_config) spezifische Einschränkungen für die Public-Key-Authentifizierung enthalten.

Schritt-für-Schritt-Fehlerbehebungsanleitung

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

1. Lokalen privaten Schlüssel und Berechtigungen überprüfen

Ihre lokale SSH-Konfiguration ist die erste Stelle, die überprüft werden sollte. Stellen Sie sicher, dass Ihr privater Schlüssel zugänglich ist und die korrekten Berechtigungen besitzt.

Überprüfung der Existenz des privaten Schlüssels

Ihr privater Schlüssel befindet sich typischerweise in ~/.ssh/id_rsa (oder id_ed25519, id_dsa usw.).

Überprüfung 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 Dateinamen Ihres privaten Schlüssels.

2. Serverseitige authorized_keys-Konfiguration überprüfen

Dies ist oft der häufigste Übeltäter. Der Server muss Ihren öffentlichen Schlüssel korrekt für den Benutzer auflisten, als der Sie sich authentifizieren möchten.

Zugriff auf den Server (falls möglich)

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

Überprüfung des Speicherorts der authorized_keys-Datei

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

Überprüfung der serverseitigen Dateiberechtigungen

Ähnlich wie auf der Client-Seite sind serverseitige 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üfung des Inhalts der authorized_keys-Datei

Ö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 ähnlichem beginnen, gefolgt von einer langen Zeichenfolge und optional einem Kommentar.

Beispiel für einen authorized_keys-Eintrag:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD... your_public_key_string user@hostname

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

3. Sicherstellen, dass der korrekte ö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 Datei ~/.ssh/authorized_keys des Servers. Schon ein einziger Tippfehler oder ein fehlendes Zeichen führt zum Fehlschlagen der Authentifizierung.

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 user@your_server_ip

Dieser Befehl fügt Ihren Standard-Public-Key (~/.ssh/id_rsa.pub) automatisch an die Datei ~/.ssh/authorized_keys auf dem Remote-Server an und setzt die korrekten Berechtigungen.

4. Den korrekten privaten Schlüssel angeben (wenn nicht Standard)

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

Verwendung des -i-Flags

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

ssh -i ~/.ssh/my_other_key user@your_server_ip

Konfiguration 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 your_server_alias
  HostName your_server_ip_or_domain
  User your_username
  IdentityFile ~/.ssh/my_other_key

Dann können Sie sich einfach mit:

ssh your_server_alias

verbinden.

5. SSH-Agent-Status überprüfen

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

Überprüfung, ob der Agent läuft

echo "$SSH_AUTH_SOCK"

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

Schlüssel zum Agenten hinzufügen

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 diese ein. Sie können überprüfen, welche Schlüssel hinzugefügt wurden, mit ssh-add -l.

6. Debugging mit Verbose-Modus

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

ssh -vvv user@your_server_ip

Untersuchen Sie die Ausgabe auf Meldungen bezüglich Schlüsselauthentifizierung, angebotener Schlüssel und Serverantworten. Dies weist oft direkt auf das Problem hin.

Beispielhafter Verbose-Output-Ausschnitt, 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 könnte darauf hindeuten, dass der Client versucht hat, id_rsa zu verwenden, aber fehlgeschlagen ist und dann zu anderen Methoden übergegangen ist.

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

Obwohl seltener für publickey-spezifische Fehler (normalerweise würden andere Fehler auftreten), lohnt sich ein Blick in die Konfigurationsdatei des SSH-Daemons auf dem Server (/etc/ssh/sshd_config). Stellen Sie sicher, dass PubkeyAuthentication yes nicht auskommentiert und auf yes gesetzt ist. Nach Änderungen muss der SSH-Dienst neu geladen oder neu gestartet werden (z. B. sudo systemctl reload sshd oder sudo systemctl restart sshd).

Zusammenfassung und Best Practices

Die Fehlerbehebung bei SSH-Fehlern vom Typ "Permission Denied (publickey)" erfordert eine methodische Überprüfung der Client- und Serverkonfigurationen. Die häufigsten Ursachen sind falsche Dateiberechtigungen für ~/.ssh- und authorized_keys-Dateien sowie Diskrepanzen zwischen dem öffentlichen Schlüssel auf dem Server und dem privaten Schlüssel auf dem Client.

Wichtige Erkenntnisse:

• Berechtigungen sind entscheidend: Stellen Sie immer sicher, dass ~/.ssh 700 und private Schlüssel/authorized_keys 600 auf Client und Server sind.
• Genauigkeit des öffentlichen Schlüssels: Überprüfen Sie sorgfältig, ob der exakte öffentliche Schlüssel in der authorized_keys-Datei des Servers vorhanden ist.
• Verwenden Sie ssh-copy-id: Wenn möglich, ist dies der sicherste und einfachste Weg, die Public-Key-Authentifizierung einzurichten.
• Verbose-Modus: Nutzen Sie ssh -vvv für detaillierte Diagnoseausgaben.

Indem Sie diese Schritte befolgen, sollten Sie in der Lage sein, die meisten "Permission Denied (publickey)"-Probleme zu diagnostizieren und zu beheben und einen sicheren Fernzugriff auf Ihre Server wiederherzustellen.