Der Fehler Permission denied (publickey). ist eines der frustrierendsten SSH-Probleme bei der Fehlerbehebung, da er mehrere Ursachen haben kann und die Fehlermeldung selbst sehr wenig Information darüber gibt, was schiefgelaufen ist. Dieser Artikel konzentriert sich auf eine besonders knifflige Ursache — verschlüsselte Home-Verzeichnisse — und behandelt auch die anderen häufigen Ursachen und ihre Lösungen.

Das Problem

Sie haben die SSH-Schlüsselauthentifizierung korrekt auf Ihrem Ubuntu-Server eingerichtet. Alles funktioniert einwandfrei — bis Sie den Server neustarten. Nach dem Neustart erhalten Sie:

Permission denied (publickey).

Sie greifen per Konsole auf den Server zu, und alles sieht in Ordnung aus — die Schlüssel sind am richtigen Ort, die Berechtigungen sind korrekt. Sie versuchen SSH erneut und es funktioniert. Starten Sie den Server oder den SSH-Dienst neu, und der Fehler kehrt zurück.

Dieses intermittierende Verhalten ist das Schlüsselsymptom, das auf ein verschlüsseltes Home-Verzeichnis als Grundursache hinweist.

Warum verschlüsselte Home-Verzeichnisse die SSH-Schlüsselauthentifizierung brechen

Wenn Sie Ubuntu installieren und sich für die Verschlüsselung Ihres Home-Verzeichnisses entscheiden, verwendet das System eCryptfs, um ~/.Private zu verschlüsseln und es beim Login in Ihr Home-Verzeichnis einzuhängen. Folgendes passiert:

  1. Vor dem Login: Der Inhalt Ihres Home-Verzeichnisses ist verschlüsselt. Der SSH-Daemon versucht ~/.ssh/authorized_keys zu lesen, kann es aber nicht, da das Verzeichnis verschlüsselt ist.
  2. Beim Konsolen-Login: Sie geben Ihr Passwort ein, was die Entschlüsselung und das Einhängen Ihres Home-Verzeichnisses auslöst.
  3. Nach dem Login: ~/.ssh/authorized_keys ist nun lesbar, sodass die SSH-Schlüsselauthentifizierung funktioniert.

Dies erzeugt das verwirrende Muster, bei dem SSH-Schlüssel nach manuellem Login funktionieren, aber nach einem Neustart fehlschlagen.

Wichtiger Hinweis: Cloud-Server (AWS, Azure, DigitalOcean, etc.) verschlüsseln Home-Verzeichnisse standardmäßig nicht, weshalb dieses Problem typischerweise nur Server betrifft, die Sie selbst installiert haben, bei denen Sie die Verschlüsselungsoption gewählt haben.

Diagnose des Problems

Schritt 1: Ausführliche SSH-Ausgabe aktivieren

Verbinden Sie sich mit maximaler Ausführlichkeit, um genau zu sehen, wo die Authentifizierung fehlschlägt:

ssh -vvv benutzer@ihr-server

Suchen Sie nach Zeilen wie:

debug1: Offering public key: /home/ihrbenutzer/.ssh/id_ed25519
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Die type 51-Antwort bedeutet, dass der Server den Schlüssel abgelehnt hat.

Schritt 2: Server-Logs überprüfen

Auf dem Server (per Konsole zugegriffen), untersuchen Sie das Authentifizierungsprotokoll:

sudo tail -50 /var/log/auth.log

Bei Problemen mit verschlüsselten Home-Verzeichnissen könnten Sie sehen:

sshd[1234]: Could not open authorized keys '/home/benutzer/.ssh/authorized_keys': No such file or directory

Diese Meldung erscheint, weil das verschlüsselte Verzeichnis für den SSH-Daemon leer aussieht.

Schritt 3: Home-Verzeichnis-Verschlüsselung überprüfen

Prüfen Sie, ob Ihr Home-Verzeichnis verschlüsselt ist:

ls -la /home/

Wenn Sie ein .ecryptfs- oder .Private-Verzeichnis sehen, verwendet Ihr Home-Verzeichnis Verschlüsselung:

ls -la /home/benutzer/
# Wenn verschlüsselt und nicht eingehängt, sehen Sie möglicherweise:
# .ecryptfs  .Private  Access-Your-Private-Data.desktop  README.txt

Sie können auch prüfen:

mount | grep ecryptfs

Lösung 1: SSH-Schlüssel außerhalb des verschlüsselten Home-Verzeichnisses speichern (Empfohlen)

Der beste Ansatz ist, SSH so zu konfigurieren, dass autorisierte Schlüssel von einem Speicherort außerhalb des verschlüsselten Home-Verzeichnisses gelesen werden.

Alternatives Schlüsselverzeichnis erstellen

sudo mkdir -p /etc/ssh/authorized_keys

Autorisierte Schlüssel kopieren

sudo cp ~/.ssh/authorized_keys /etc/ssh/authorized_keys/$USER
sudo chown root:root /etc/ssh/authorized_keys/$USER
sudo chmod 644 /etc/ssh/authorized_keys/$USER

SSH-Konfiguration aktualisieren

Bearbeiten Sie die SSH-Daemon-Konfiguration:

sudo nano /etc/ssh/sshd_config

Finden Sie die AuthorizedKeysFile-Direktive und ändern Sie sie zu:

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Das %u wird während der Authentifizierung durch den Benutzernamen ersetzt.

SSH neustarten

sudo systemctl restart sshd

Konfiguration testen

Von Ihrem lokalen Rechner:

ssh benutzer@ihr-server

Dies sollte jetzt auch nach einem Neustart funktionieren, da /etc/ssh/authorized_keys/ nicht im verschlüsselten Home-Verzeichnis liegt.

Wichtig: Wenn Sie zukünftig neue SSH-Schlüssel hinzufügen, müssen Sie diese zu /etc/ssh/authorized_keys/benutzername statt zu ~/.ssh/authorized_keys hinzufügen.

Für eine detaillierte Anleitung dieses Ansatzes siehe: So speichern Sie Ihren öffentlichen SSH-Schlüssel in einem anderen Verzeichnis.

Lösung 2: Home-Verzeichnis entschlüsseln

Wenn Sie entscheiden, dass Sie die Home-Verzeichnis-Verschlüsselung nicht mehr benötigen:

# Stellen Sie sicher, dass Sie als der Benutzer angemeldet sind
ecryptfs-migrate-home -u $USER

Warnung: Sichern Sie Ihre Daten, bevor Sie dies versuchen. Die Entschlüsselung des Home-Verzeichnisses kann fehlschlagen, wenn nicht genügend Speicherplatz vorhanden ist (Sie benötigen vorübergehend ungefähr den doppelten Speicherplatz Ihres Home-Verzeichnisses).

Andere häufige Ursachen von ‘Permission denied (publickey)’

Wenn Ihr Home-Verzeichnis nicht verschlüsselt ist, stammt der Fehler wahrscheinlich von einer dieser Ursachen:

Falsche Dateiberechtigungen

SSH ist sehr streng bei Berechtigungen. Folgendes muss korrekt eingestellt sein:

# Home-Verzeichnis: kein Schreibzugriff für Gruppe/Andere
chmod 755 ~
# oder
chmod 700 ~

# .ssh-Verzeichnis: nur Eigentümer
chmod 700 ~/.ssh

# authorized_keys: nur Lesen/Schreiben des Eigentümers
chmod 600 ~/.ssh/authorized_keys

# Privater Schlüssel (auf Ihrem Client): nur Lesen des Eigentümers
chmod 600 ~/.ssh/id_ed25519

Schlüssel nicht in authorized_keys hinzugefügt

Überprüfen Sie, ob Ihr öffentlicher Schlüssel in der authorized_keys-Datei des Servers ist:

cat ~/.ssh/authorized_keys

Vergleichen Sie ihn mit Ihrem lokalen öffentlichen Schlüssel:

# Auf Ihrem lokalen Rechner
cat ~/.ssh/id_ed25519.pub

SSH-Agent nicht geladen

Wenn Ihr Schlüssel eine Passphrase verwendet und der SSH-Agent nicht läuft:

# Agent starten
eval "$(ssh-agent -s)"

# Schlüssel hinzufügen
ssh-add ~/.ssh/id_ed25519

Falscher Schlüsseltyp

Ältere Server unterstützen möglicherweise keine neueren Schlüsseltypen wie Ed25519. Versuchen Sie, einen RSA-Schlüssel zu generieren:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_legacy
ssh-copy-id -i ~/.ssh/id_rsa_legacy.pub benutzer@server

Serverkonfiguration blockiert Public-Key-Authentifizierung

Überprüfen Sie, ob der Server Public-Key-Authentifizierung erlaubt:

sudo grep -E "PubkeyAuthentication|AuthorizedKeysFile" /etc/ssh/sshd_config

Stellen Sie sicher:

PubkeyAuthentication yes

SELinux oder AppArmor blockiert den Zugriff

Auf Systemen mit obligatorischer Zugriffskontrolle:

# SELinux überprüfen
sudo restorecon -R ~/.ssh/

# AppArmor überprüfen
sudo aa-status

Schnelle Checkliste zur Fehlerbehebung

PrüfungBefehl
Ausführliche SSH-Ausgabessh -vvv benutzer@server
Authentifizierungsprotokollsudo tail -50 /var/log/auth.log
Home verschlüsselt?mount | grep ecryptfs
.ssh-Berechtigungenls -la ~/.ssh/
authorized_keys-Inhaltcat ~/.ssh/authorized_keys
SSH-Konfigurationsudo sshd -T | grep -i pubkey
SSH-Agent-Schlüsselssh-add -l

Zusammenfassung

Der Fehler Permission denied (publickey), verursacht durch verschlüsselte Home-Verzeichnisse, ist besonders heimtückisch, weil er intermittierend auftritt — die SSH-Schlüsselauthentifizierung gelingt nach manuellem Login, schlägt aber nach einem Neustart fehl. Die empfohlene Lösung ist, autorisierte Schlüssel außerhalb des verschlüsselten Home-Verzeichnisses zu speichern, indem AuthorizedKeysFile in sshd_config aktualisiert wird.

Für andere Ursachen dieses Fehlers überprüfen Sie systematisch Dateiberechtigungen, bestätigen Sie, dass der Schlüssel in authorized_keys ist, stellen Sie sicher, dass der SSH-Agent läuft, und überprüfen Sie die sshd_config des Servers. Die Verwendung von ssh -vvv und die Überprüfung von /var/log/auth.log werden fast immer die Grundursache aufdecken.

Verwandte Artikel