Le message
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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).Malgré le mot « warning », cela empêche la clé d'être utilisée. La vérification a lieu sur votre propre ordinateur, avant que la clé privée serve à signer quoi que ce soit. Le serveur ne vous a pas refusé.
La solution
chmod 600 ~/.ssh/id_ed25519Utilisez le chemin affiché dans le message. Le mode 600 signifie que vous seul pouvez lire et écrire. Le mode 400, en lecture seule, est aussi accepté. Toute permission pour le groupe ou les autres est refusée : nous avons essayé 640, 660, 644 et 440, et les quatre ont donné cette erreur.
Pour vérifier sans vous connecter, utilisez l'une de ces commandes :
ls -l ~/.ssh/id_ed25519
ssh-keygen -y -f ~/.ssh/id_ed25519La seconde commande affiche la clé publique si les permissions sont correctes, et le même avertissement sinon. Si la clé a une phrase secrète, elle la demande d'abord.
Pour remettre en ordre tout un dossier :
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_*
chmod 644 ~/.ssh/*.pubLes clés publiques peuvent rester lisibles, c'est pourquoi la dernière ligne les rétablit.
Comment une clé se retrouve avec ces permissions
- Elle a été copiée depuis une clé USB, un dossier partagé ou un fichier zip, ou téléchargée depuis un navigateur.
- Un script ou une restauration de sauvegarde l'a écrite avec le mode par défaut.
- Quelqu'un a lancé
chmod -R 755sur le dossier personnel.
Si vous ne savez pas par où une clé copiée est passée, le plus simple est de générer une nouvelle clé SSH Ed25519 et de remplacer l'ancienne sur vos serveurs.
Cas voisins sur votre ordinateur
La clé appartient à quelqu'un d'autre
Une clé créée avec sudo appartient à root. Avec le mode 600, vous ne pouvez pas du tout la lire, et le message est différent :
Load key "/home/user/.ssh/id_ed25519": Permission deniedReprenez-la avec sudo chown "$USER" ~/.ssh/id_ed25519.
Pas d'avertissement, seulement Permission denied
Si un fichier .pub se trouve à côté de la clé, ssh propose d'abord la moitié publique et ne lit le fichier privé que si le serveur l'accepte. Avec une mauvaise clé, vous ne voyez donc jamais cet avertissement, même avec de mauvaises permissions. ssh -v montre l'ordre :
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.Le fichier de configuration
Le même type de vérification s'applique à votre configuration cliente :
Bad owner or permissions on /home/user/.ssh/configCorrigez avec chmod 600 ~/.ssh/config.
Windows
OpenSSH sous Windows utilise des listes d'accès aux fichiers, pas chmod. Ces commandes PowerShell viennent de la documentation d'AWS, avec le chemin de votre clé dans $path :
icacls.exe $path /reset
icacls.exe $path /GRANT:R "$($env:USERNAME):(R)"
icacls.exe $path /inheritance:rDans WSL, une clé sous /mnt/c peut ne pas conserver les permissions Linux. Copiez-la dans ~/.ssh à l'intérieur du système de fichiers Linux et lancez-y chmod 600.
Le même problème côté serveur : StrictModes
Le serveur fait une vérification semblable, mais vous ne voyez pas d'avertissement. Le client n'affiche que Permission denied (publickey,password). et la raison est dans le journal du serveur, que vous devez lire par un autre accès, comme une console :
Authentication refused: bad ownership or modes for directory /home/user/.sshSur Debian et Ubuntu, utilisez sudo journalctl -u ssh, et sur la plupart des autres systèmes journalctl -u sshd. Voici ce que nous avons vu avec OpenSSH 10.0 de Debian 13, avec StrictModes yes, la valeur par défaut :
| Changement | Résultat |
|---|---|
Dossier personnel 777 | Refusé, bad ownership or modes for directory |
~/.ssh modifiable par le groupe, le groupe est root | Refusé, même message |
authorized_keys modifiable par le groupe, le groupe est root | Refusé, bad ownership or modes for file |
authorized_keys appartenant à root, mode 600 | Refusé, Could not open user 'user' authorized keys |
authorized_keys mode 644 | La connexion fonctionne |
~/.ssh mode 755 | La connexion fonctionne |
La version de Debian autorisait aussi l'écriture par le groupe quand le groupe était le groupe privé de l'utilisateur : ne vous attendez donc pas à la même chose sur tous les systèmes. Le réglage sûr est le même partout. Lancez ceci en tant qu'utilisateur sur le serveur :
chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER" ~/.sshSi vous lancez la dernière ligne via sudo, nommez l'utilisateur au lieu de $USER.
Ne définissez pas StrictModes no. La connexion fonctionne alors, comme nous l'avons confirmé, mais cela accepte aussi un fichier authorized_keys que d'autres utilisateurs ont pu modifier. Pour voir la valeur actuelle :
sudo sshd -T | grep -i strictmodesSi les modes sont corrects et que la clé est toujours refusée, voir Permission denied (publickey).
Questions
Quels droits doit avoir une clé privée SSH ?
600, pour que vous seul puissiez la lire et l'écrire. 400, lecture seule, convient aussi. Tout accès pour le groupe ou les autres fait ignorer la clé par ssh.
Quels droits pour ~/.ssh et authorized_keys ?
700 pour ~/.ssh et 600 pour authorized_keys. Les clés publiques en .pub peuvent rester en 644.
Peut-on désactiver la vérification des droits ?
Pas côté client. Côté serveur, StrictModes no saute sa propre vérification, mais accepte aussi un fichier authorized_keys que d'autres ont pu modifier : corrigez plutôt les droits.
Sources
- ssh(1), manuel OpenBSD
- sshd_config(5), StrictModes
- Troubleshoot connecting to an EC2 Linux instance, AWS