Si le Terminal de macOS affiche « UNPROTECTED PRIVATE KEY FILE » ou indique que votre clé SSH est trop accessible, restreignez l'accès à la clé privée et vérifiez le répertoire .ssh. Ouvrez le Terminal et exécutez chmod 600 sur le fichier de clé que vous utilisez réellement. Cela le rend lisible et modifiable uniquement par votre compte ; SSH ignore les fichiers de clés privées auxquels d'autres utilisateurs peuvent accéder. Manuel OpenBSD ssh(1)

Corriger les permissions de la clé privée

Identifiez d'abord le fichier de clé. Les noms par défaut courants des clés privées pour SSH incluent id_ed25519 et id_rsa, mais vous pouvez avoir un nom ou un emplacement différent. Le suffixe .pub identifie une clé publique ; n'appliquez pas ce correctif à ce fichier à la place de la clé privée.

Pour une clé Ed25519 par défaut, entrez :

chmod 600 "$HOME/.ssh/id_ed25519"

Pour une autre clé, remplacez id_ed25519 par son véritable nom de fichier. Mettre le chemin entre guillemets évite que les espaces et autres caractères shell dans le nom de fichier ne soient interprétés comme de la syntaxe. Si la clé se trouve ailleurs, utilisez son chemin d'accès complet à l'intérieur des guillemets. 600 accorde l'accès en lecture et en écriture au propriétaire et supprime les accès pour le groupe et les autres utilisateurs. Manuel OpenBSD chmod(1)

Vous pouvez inspecter le mode résultant avec ls -l "$HOME/.ssh/id_ed25519". Un affichage typique commence par -rw------- ; les trois premiers caractères de permission après le type de fichier indiquent les accès du propriétaire, et les groupes suivants indiquent qu'aucun accès n'est accordé au groupe ou aux autres. Le propriétaire du fichier doit également être votre compte. S'il appartient à un autre utilisateur, chmod peut échouer ou le client SSH peut toujours être incapable de l'utiliser. Vérifiez le propriétaire avec ls -l ; évitez de changer la propriété à l'aveugle, surtout avec sudo, car la solution appropriée dépend de la raison pour laquelle le fichier appartient à quelqu'un d'autre.

Vérifier le répertoire .ssh

Le manuel de SSH recommande que ~/.ssh/ soit lisible, modifiable et explorable par son propriétaire, et inaccessible aux autres. Si SSH signale un problème de permissions pour le répertoire lui-même, exécutez :

chmod 700 "$HOME/.ssh"

Cela supprime les accès au groupe et aux autres tout en accordant à votre compte un accès complet au répertoire. Si la clé est stockée dans un autre dossier, vérifiez chaque répertoire de son arborescence : le compte a besoin de la permission d'accès (exécution) pour atteindre le fichier. N'exécutez pas chmod de manière récursive sur tout votre répertoire personnel ou sur le dossier .ssh comme première solution ; cela peut modifier les permissions de fichiers sans rapport ayant des besoins différents. Manuel OpenBSD ssh(1)

Confirmer que SSH utilise cette clé

Une clé corrigée peut toujours sembler ne pas fonctionner si SSH cherche ailleurs ou propose une identité différente. Utilisez -i pour spécifier une clé pour une connexion donnée. Remplacez le compte et l'hôte de l'exemple par les vôtres :

ssh -i "$HOME/.ssh/id_ed25519" user@example.com

L'option -i sélectionne le fichier d'identité utilisé pour l'authentification par clé publique. Manuel OpenBSD ssh(1) Pour un journal de connexion plus détaillé, ajoutez -v :

ssh -v -i "$HOME/.ssh/id_ed25519" user@example.com

Si vous gérez plusieurs hôtes, vous pouvez définir IdentityFile dans ~/.ssh/config ; le bloc Host détermine quels paramètres de connexion s'appliquent. Le client peut également essayer les clés fournies par ssh-agent. IdentitiesOnly yes permet de limiter les identités proposées aux seuls fichiers d'identité configurés lorsqu'un agent a de nombreuses clés chargées. Manuel OpenBSD ssh_config(5)

Savoir identifier si l'erreur se situe ailleurs

Un avertissement local concernant les permissions d'une clé privée est différent de Permission denied (publickey). Cette dernière erreur peut signifier que le serveur ne reconnaît pas la clé publique correspondante, que le nom d'utilisateur est incorrect ou que SSH tente une autre identité. La clé publique correspondant à votre clé privée doit être autorisée pour le compte sur l'hôte distant ; modifier les permissions locales n'installe pas cette clé publique sur le serveur. Manuel OpenBSD ssh(1)

Si chmod renvoie « Operation not permitted », vérifiez si vous êtes le propriétaire du fichier et si le chemin pointe bien vers la clé voulue. Évitez de rendre une clé privée lisible par tous pour faire taire l'avertissement : la restriction de SSH protège l'identifiant, et la lever peut amener le client à rejeter la clé. Une fois que la clé privée et son répertoire ont des permissions appropriées, réessayez avec -v et suivez la sortie de diagnostic pour distinguer un problème de fichier local d'un problème d'authentification ou côté serveur.

Sources