SSH verweigert den Schlüssel, weil die Rechte zu offen seien? Ein privater Schlüssel darf nur dir gehören — mit einem chmod ist es in Sekunden behoben.
Aufwand:
ca. 10 Min.
Voraussetzung:
sudo-Rechte, Terminal
Gilt für:
OpenSSH unter Linux/macOS
Das Symptom
Beim Verbinden per SSH mit einem Schlüssel bricht die Anmeldung ab, noch bevor es
zum Server geht. SSH warnt in Großbuchstaben vor einer ungeschützten
Schlüsseldatei, nennt „Permissions 0644 for … are too open“ und verlangt, dass die
Datei nicht für andere zugänglich ist. Der Schlüssel wird ignoriert.
Die „Layer 8“-Wahrheit
Ein privater SSH-Schlüssel ist das digitale Gegenstück zu einem Haustürschlüssel —
und SSH nimmt dessen Schutz kompromisslos ernst. Liegt die Schlüsseldatei so, dass
auch andere Benutzer desselben Systems sie lesen könnten, betrachtet SSH sie als
gefährdet und weigert sich schlicht, sie zu verwenden. Das ist keine Schikane,
sondern gelebte Sicherheit: Ein Schlüssel, den mehr als eine Person lesen kann, ist
kein Geheimnis mehr, und ein kompromittierter Schlüssel öffnet jedem die Tür, der ihn
in die Hände bekommt.
Die Lösung ist entsprechend banal und in Sekunden erledigt: dem Schlüssel enge Rechte
geben, sodass nur der eigene Benutzer ihn lesen darf, und sicherstellen, dass er auch
diesem Benutzer gehört und nicht versehentlich root. Der häufigste Auslöser ist ein
Schlüssel, der von einem anderen System kopiert, per sudo angelegt oder aus einem
Archiv entpackt wurde und dabei zu großzügige Rechte mitbrachte. Wer die Warnung
versteht, klickt sie nicht weg, sondern nimmt sie als das, was sie ist — eine
berechtigte Erinnerung daran, dass ein Schlüssel privat zu bleiben hat.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Die Warnung verstehen
SSH weigert sich, einen privaten Schlüssel zu benutzen, wenn andere Nutzer des Systems ihn lesen könnten. Die Meldung „Permissions are too open“ oder „UNPROTECTED PRIVATE KEY FILE“ ist kein Defekt, sondern ein Schutz: Ein privater Schlüssel, den auch andere lesen dürfen, ist so gut wie kompromittiert.
2.
Die Rechte des Schlüssels setzen
Der private Schlüssel darf nur dem eigenen Benutzer gehören und nur von ihm lesbar sein. Die Rechte entsprechend eng setzen:
chmod 600 ~/.ssh/id_ed25519
3.
Den Besitzer prüfen
Neben den Rechten muss auch der Besitzer stimmen — der Schlüssel gehört dem eigenen Benutzer, nicht root. Wurde die Datei etwa mit sudo kopiert, den Besitz zurückgeben:
chown $USER ~/.ssh/id_ed25519
4.
Das ganze .ssh-Verzeichnis absichern
Auch das Verzeichnis selbst sollte geschützt sein. Dem .ssh-Ordner enge Rechte geben, damit niemand sonst hineinschauen kann:
chmod 700 ~/.ssh
5.
Windows und Netzlaufwerke bedenken
Unter Windows greift ein anderes Rechtesystem; hier müssen in den Dateieigenschaften die Berechtigungen so gesetzt werden, dass nur der eigene Benutzer Zugriff hat. Ein Schlüssel auf einem Netzlaufwerk oder in einem freigegebenen Ordner ist ohnehin ungeeignet — private Schlüssel gehören lokal und geschützt.
Häufige Fragen (FAQ)
?Warum verweigert SSH den Schlüssel wegen der Dateirechte?
Weil ein privater Schlüssel, den andere Benutzer lesen können, faktisch kompromittiert ist. SSH weigert sich deshalb kategorisch, ihn zu verwenden – und das ist die richtige Entscheidung, nicht eine Schikane. Der Schlüssel gehört auf 600, das Verzeichnis .ssh auf 700.
?Der Schlüssel liegt auf einem Netzlaufwerk oder unter Windows. Was jetzt?
Dateisysteme wie FAT32 oder exFAT kennen keine Unix-Rechte – SSH sieht dort immer zu offene Berechtigungen und verweigert den Dienst. Kopieren Sie den Schlüssel auf ein lokales Dateisystem mit ordentlicher Rechteverwaltung. Unter Windows setzt man die Rechte über die Sicherheitseinstellungen der Datei und entfernt alle Benutzer außer dem eigenen.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
SSH warnt 'REMOTE HOST IDENTIFICATION HAS CHANGED' und 'Host key verification failed'? So prüfst du die Ursache und entfernst den alten Schlüssel sicher.
git commit bricht mit „gpg failed to sign the data“ ab? Meist fehlt der passende Schlüssel, oder GPG kann im Terminal nicht nach der Passphrase fragen.