SSH : corriger l’erreur “Permissions are too open”

Lors d’une connexion SSH, il arrive de tomber sur ce message assez brutal :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/matt/.ssh/id_ed25519.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/Users/matt/.ssh/id_ed25519.pub": bad permissionsCode language: PHP (php)

Le message semble dire que les permissions de la clé publique sont trop ouvertes. En réalité, le problème le plus probable est encore plus simple : vous avez demandé à SSH d’utiliser une clé publique comme si c’était une clé privée.

Autrement dit, vous avez probablement utilisé un fichier qui se termine par .pub avec l’option -i. Et SSH n’a pas apprécié. Franchement, il a raison.

La cause la plus fréquente : utiliser id_rsa.pub ou id_ed25519.pub avec -i

L’option -i de la commande ssh sert à indiquer le fichier d’identité, c’est-à-dire la clé privée à utiliser pour se connecter.

Voici l’erreur classique :

ssh -i ~/.ssh/id_ed25519.pub user@example.comCode language: JavaScript (javascript)

Ici, le fichier indiqué est id_ed25519.pub. C’est la clé publique. Elle sert à être copiée sur le serveur, généralement dans ~/.ssh/authorized_keys. Elle ne sert pas à s’authentifier côté client avec -i.

La bonne commande utilise la clé privée, sans l’extension .pub :

ssh -i ~/.ssh/id_ed25519 user@example.comCode language: JavaScript (javascript)

Pour une clé RSA ancienne, le principe est identique :

ssh -i ~/.ssh/id_rsa user@example.comCode language: JavaScript (javascript)

Et non :

ssh -i ~/.ssh/id_rsa.pub user@example.comCode language: JavaScript (javascript)

Clé privée et clé publique : la différence à retenir

Une paire de clés SSH contient deux fichiers.

Fichier	Rôle	Où l’utiliser ?	Permissions typiques
id_ed25519	Clé privée	Sur votre machine, avec ssh -i	600
id_ed25519.pub	Clé publique	Sur le serveur, dans authorized_keys	644 acceptable
id_rsa	Clé privée RSA	Sur votre machine, avec ssh -i	600
id_rsa.pub	Clé publique RSA	Sur le serveur, dans authorized_keys	644 acceptable

La clé privée doit rester privée. Elle ne doit jamais être partagée, envoyée par email, copiée dans un ticket support ou déposée sur un serveur tiers.

La clé publique, elle, est faite pour être partagée. Vous pouvez la copier sur GitHub, GitLab, WPEngine, un serveur dédié ou dans le fichier authorized_keys d’un compte distant.

Correction rapide

Si votre commande contient .pub, retirez-le.

Mauvaise commande :

ssh -i ~/.ssh/id_ed25519.pub -o IdentitiesOnly=yes user@example.comCode language: JavaScript (javascript)

Bonne commande :

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes user@example.comCode language: JavaScript (javascript)

Dans la plupart des cas, cela suffit. Le fichier .pub n’était pas trop ouvert pour son rôle. Il était simplement utilisé au mauvais endroit.

Vérifier les permissions de vos clés SSH

Si l’erreur concerne vraiment une clé privée, corrigez ses permissions.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Pour une clé RSA :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

La règle simple :

• ~/.ssh doit être accessible uniquement par votre utilisateur.
• La clé privée doit être lisible uniquement par votre utilisateur.
• La clé publique peut être lisible par d’autres.
• Le fichier authorized_keys côté serveur doit généralement être en 600.

Vérifier les droits avec ls

Pour voir les permissions actuelles, utilisez :

ls -la ~/.ssh

Un résultat propre ressemble à ceci :

drwx------  10 matt  staff   320 May 19 09:30 .
-rw-------   1 matt  staff   411 May 19 09:30 id_ed25519
-rw-r--r--   1 matt  staff    99 May 19 09:30 id_ed25519.pub
-rw-------   1 matt  staff  1200 May 19 09:30 known_hostsCode language: CSS (css)

Le détail important est ici :

• id_ed25519 en -rw-------, soit 600 ;
• id_ed25519.pub en -rw-r--r--, soit 644 ;
• ~/.ssh en drwx------, soit 700.

Cas serveur : authorized_keys et StrictModes

Si la connexion échoue encore, le problème peut se trouver côté serveur. OpenSSH vérifie aussi les permissions du dossier personnel, du dossier .ssh et du fichier authorized_keys.

Sur le serveur distant, connectez-vous avec un autre accès disponible, puis vérifiez :

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Vérifiez aussi le propriétaire des fichiers :

chown -R "$USER:$USER" ~/.sshCode language: JavaScript (javascript)

Sur certains systèmes, notamment selon la distribution, le groupe principal peut avoir un nom différent du nom utilisateur. Dans ce cas, adaptez la commande chown au contexte.

Ne désactivez pas StrictModes

Vous trouverez parfois des conseils indiquant de passer StrictModes no dans sshd_config. Mauvaise idée dans la plupart des cas.

StrictModes demande à SSH de vérifier les permissions et propriétaires des fichiers utilisateur avant d’accepter une authentification. Si SSH refuse une clé à cause de droits trop ouverts, il vous rend service. Il ne fait pas son intéressant. Enfin, pas seulement.

Corrigez les permissions. Ne baissez pas le niveau de sécurité du serveur pour masquer un mauvais chmod.

Utiliser un fichier de configuration SSH

Si vous utilisez souvent la même clé pour un serveur, évitez de retaper une longue commande. Déclarez l’hôte dans ~/.ssh/config.

Host monserveur
	HostName example.com
	User deploy
	IdentityFile ~/.ssh/id_ed25519
	IdentitiesOnly yesCode language: JavaScript (javascript)

Ensuite, connectez-vous simplement avec :

ssh monserveur

Là encore, indiquez bien la clé privée dans IdentityFile, pas le fichier .pub.

Diagnostiquer avec ssh -v

Pour comprendre ce que fait SSH, ajoutez l’option verbose :

ssh -v -i ~/.ssh/id_ed25519 user@example.comCode language: JavaScript (javascript)

Pour plus de détails :

ssh -vvv -i ~/.ssh/id_ed25519 user@example.comCode language: JavaScript (javascript)

Cherchez notamment les lignes qui mentionnent :

• Offering public key
• Authentications that can continue
• bad permissions
• Permission denied (publickey)
• identity file

Si vous voyez que SSH charge un fichier .pub comme identité, vous avez trouvé le coupable. Il est dans le salon avec l’extension .pub.

Permissions recommandées pour SSH

Chemin	Permission recommandée	Commande
~	Non accessible en écriture par groupe/autres	chmod go-w ~
~/.ssh	700	chmod 700 ~/.ssh
~/.ssh/id_ed25519	600	chmod 600 ~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub	644	chmod 644 ~/.ssh/id_ed25519.pub
~/.ssh/authorized_keys	600	chmod 600 ~/.ssh/authorized_keys
~/.ssh/config	600	chmod 600 ~/.ssh/config
~/.ssh/known_hosts	600 ou 644	chmod 600 ~/.ssh/known_hosts

Exemple avec WPEngine

Dans mon cas, l’erreur est apparue lors d’une connexion SSH à un environnement WPEngine. La commande ressemblait à ceci :

ssh -i ~/.ssh/id_ed25519.pub -o IdentitiesOnly=yes user@environment.ssh.wpengine.netCode language: JavaScript (javascript)

La correction consiste simplement à utiliser la clé privée :

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes user@environment.ssh.wpengine.netCode language: JavaScript (javascript)

Le fichier id_ed25519.pub doit être ajouté dans l’interface d’hébergement ou dans les clés autorisées du serveur. Le fichier id_ed25519, lui, reste sur votre machine.

Dès lors, plus de problème de connexion et la connexion sur le serveur WPEngine se fait sans souci:

  ____  _____  _____
 ╱   ▕ ▕    ▕ ▕    ▕
▕    ▕ ▕    ▕ ▕    ▕
▕____▕  ╲___╱  ╲___▕                                      ▫
 ____           ____     ▃  ▃  ▃  ▃▃▃    ___   __    __      __   ___
▕    ▕    _    ╱   ▕     █  █  █ ▕█▀▀▙  ▕___) |  ▕  ╱  ▕ ▕  |  ▕ ▕___)
▕    ▕   ( )  ▕    ▕      ██ ██  ▕███▛  ▕     |  ▕ ▕   ▕ ▕  |  ▕ ▕
▕____╱    ‾    ╲___▕       █ █   ▕█      ╲__╱ |  ▕  ╲__▕ ▕  |  ▕  ╲__╱
 ____    ___   ___                                  ___╱
▕    ╲  ╱   ╲ ▕    ╲
▕    ▕ ▕    ▕ ▕    ▕
▕____╱ ▕____▕ ▕____▕

WP Engine Shell - PHP 8.5

Si vous utilisez encore id_rsa

Les anciennes clés RSA existent encore sur beaucoup de machines. Elles peuvent fonctionner, mais pour une nouvelle clé, préférez généralement Ed25519, plus moderne et plus courte.

Pour créer une nouvelle clé Ed25519 :

ssh-keygen -t ed25519 -a 100 -C "matt@example.com"Code language: JavaScript (javascript)

Ensuite, utilisez la clé privée générée, par exemple :

ssh -i ~/.ssh/id_ed25519 user@example.comCode language: JavaScript (javascript)

Et copiez uniquement la clé publique sur le serveur :

cat ~/.ssh/id_ed25519.pubCode language: JavaScript (javascript)

À retenir

• L’option ssh -i attend une clé privée.
• Une clé publique se termine généralement par .pub.
• Ne passez pas id_rsa.pub ou id_ed25519.pub à ssh -i.
• La clé privée doit être en 600.
• Le dossier ~/.ssh doit être en 700.
• Le fichier authorized_keys côté serveur doit généralement être en 600.
• Ne désactivez pas StrictModes pour contourner une mauvaise configuration.
• Utilisez ssh -v ou ssh -vvv pour diagnostiquer précisément.

En résumé, si SSH vous dit que les permissions de id_rsa.pub ou id_ed25519.pub sont trop ouvertes, commencez par vérifier votre commande. Dans beaucoup de cas, la solution n’est pas de durcir la clé publique. La solution est d’utiliser la clé privée correspondante.

Sources

• OpenBSD manual — ssh_config
• OpenBSD manual — sshd_config
• OpenBSD manual — sshd
• OpenSSH — Manual Pages

Report a typo