WARNING: UNPROTECTED PRIVATE KEY FILE beheben

Die Meldung

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/user/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/user/.ssh/id_ed25519": bad permissions
user@server: Permission denied (publickey,password).

Trotz des Wortes "warning" verhindert das die Verwendung des Schlüssels. Die Prüfung läuft auf Ihrem eigenen Computer, bevor der private Schlüssel zum Signieren verwendet wird. Der Server hat Sie nicht abgewiesen.

Die Lösung

chmod 600 ~/.ssh/id_ed25519

Verwenden Sie den Pfad aus der Meldung. Der Modus 600 bedeutet, dass nur Sie lesen und schreiben können. Auch der Modus 400, nur lesend, wird akzeptiert. Jede Berechtigung für Gruppe oder andere wird abgelehnt: Wir haben 640, 660, 644 und 440 probiert, und alle vier ergaben diesen Fehler.

Um ohne Verbindung zu prüfen, nehmen Sie einen dieser Befehle:

ls -l ~/.ssh/id_ed25519
ssh-keygen -y -f ~/.ssh/id_ed25519

Der zweite Befehl gibt den öffentlichen Schlüssel aus, wenn die Berechtigungen stimmen, und sonst dieselbe Warnung. Hat der Schlüssel eine Passphrase, fragt er zuerst danach.

Um einen ganzen Ordner aufzuräumen:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_*
chmod 644 ~/.ssh/*.pub

Öffentliche Schlüssel dürfen lesbar bleiben, deshalb stellt die letzte Zeile sie wieder her.

Wie ein Schlüssel zu diesen Berechtigungen kommt

Er wurde von einem USB-Stick, aus einem freigegebenen Ordner oder einer Zip-Datei kopiert oder aus einem Browser heruntergeladen.
Ein Skript oder eine Wiederherstellung aus einem Backup hat ihn mit dem Standardmodus geschrieben.
Jemand hat chmod -R 755 auf das Home-Verzeichnis ausgeführt.

Wenn Sie nicht wissen, wo ein kopierter Schlüssel überall war, ist es einfacher, einen neuen Ed25519-SSH-Schlüssel zu erzeugen und den alten auf Ihren Servern zu ersetzen.

Verwandte Fälle auf Ihrem Computer

Der Schlüssel gehört jemand anderem

Ein mit sudo erzeugter Schlüssel gehört root. Mit Modus 600 können Sie ihn gar nicht lesen, und die Meldung ist eine andere:

Load key "/home/user/.ssh/id_ed25519": Permission denied

Holen Sie ihn sich mit sudo chown "$USER" ~/.ssh/id_ed25519 zurück.

Keine Warnung, nur Permission denied

Liegt neben dem Schlüssel eine .pub-Datei, bietet ssh zuerst die öffentliche Hälfte an und liest die private Datei nur, wenn der Server sie akzeptiert. Mit einem falschen Schlüssel sehen Sie diese Warnung also nie, auch bei falschen Berechtigungen. ssh -v zeigt die Reihenfolge:

debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:...
debug1: Server accepts key: /home/user/.ssh/id_ed25519 ED25519 SHA256:...
Permissions 0644 for '/home/user/.ssh/id_ed25519' are too open.

Die Konfigurationsdatei

Dieselbe Art Prüfung gilt für Ihre Client-Konfiguration:

Bad owner or permissions on /home/user/.ssh/config

Beheben Sie es mit chmod 600 ~/.ssh/config.

Windows

OpenSSH unter Windows verwendet Dateizugriffslisten, nicht chmod. Diese PowerShell-Befehle stammen aus der AWS-Dokumentation, mit Ihrem Schlüsselpfad in $path:

icacls.exe $path /reset
icacls.exe $path /GRANT:R "$($env:USERNAME):(R)"
icacls.exe $path /inheritance:r

In WSL behält ein Schlüssel unter /mnt/c möglicherweise keine Linux-Berechtigungen. Kopieren Sie ihn nach ~/.ssh im Linux-Dateisystem und führen Sie dort chmod 600 aus.

Dasselbe Problem auf dem Server: StrictModes

Der Server hat eine ähnliche Prüfung, aber Sie sehen keine Warnung. Der Client gibt nur Permission denied (publickey,password). aus, und der Grund steht im Server-Log, das Sie auf anderem Weg lesen müssen, etwa über eine Konsole:

Authentication refused: bad ownership or modes for directory /home/user/.ssh

Unter Debian und Ubuntu nutzen Sie sudo journalctl -u ssh, auf den meisten anderen Systemen journalctl -u sshd. Das sahen wir mit OpenSSH 10.0 aus Debian 13, mit StrictModes yes, dem Standard:

Änderung	Ergebnis
Home-Verzeichnis `777`	Abgelehnt, `bad ownership or modes for directory`
`~/.ssh` für die Gruppe beschreibbar, Gruppe ist `root`	Abgelehnt, dieselbe Meldung
`authorized_keys` für die Gruppe beschreibbar, Gruppe ist `root`	Abgelehnt, `bad ownership or modes for file`
`authorized_keys` gehört root, Modus `600`	Abgelehnt, `Could not open user 'user' authorized keys`
`authorized_keys` Modus `644`	Anmeldung funktioniert
`~/.ssh` Modus `755`	Anmeldung funktioniert

Der Debian-Build erlaubte auch Gruppenschreibrechte, wenn die Gruppe die private Gruppe des Benutzers war, erwarten Sie also nicht auf jedem System dasselbe. Die sichere Einstellung ist überall gleich. Führen Sie dies als der Benutzer auf dem Server aus:

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER" ~/.ssh

Wenn Sie die letzte Zeile über sudo ausführen, nennen Sie den Benutzer statt $USER.

Setzen Sie nicht StrictModes no. Damit funktioniert die Anmeldung zwar, wie wir bestätigt haben, aber es akzeptiert auch eine authorized_keys-Datei, die andere Benutzer möglicherweise ändern konnten. Den aktuellen Wert sehen Sie mit:

sudo sshd -T | grep -i strictmodes

Stimmen die Modi und der Schlüssel wird trotzdem abgelehnt, siehe Permission denied (publickey).

Fragen

Welche Rechte braucht ein privater SSH-Schlüssel?

600, damit nur Sie ihn lesen und schreiben können. 400, nur lesen, geht auch. Jeder Zugriff für Gruppe oder andere führt dazu, dass ssh den Schlüssel ignoriert.

Welche Rechte brauchen ~/.ssh und authorized_keys?

700 für ~/.ssh und 600 für authorized_keys. Öffentliche Schlüssel mit der Endung .pub dürfen bei 644 bleiben.

Kann man die Rechteprüfung abschalten?

Auf dem Client nicht. Auf dem Server überspringt StrictModes no die eigene Prüfung, akzeptiert dann aber auch eine authorized_keys, die andere verändert haben könnten. Korrigieren Sie deshalb die Rechte.

Quellen

Mehr zu Fehlermeldungen

Alle Anleitungen