Permission denied (publickey). — ce message, sans autre détail, apparaît au pire moment : au milieu d’un déploiement automatisé qui fonctionnait la veille encore. Aucune information sur la cause précise, juste un refus sec de la connexion SSH. Ce message revient si souvent dans nos pipelines qu’il mérite une méthode de diagnostic systématique plutôt qu’un tâtonnement à chaque fois.
Symptôme
Le job de déploiement de la pipeline échoue à l’étape de connexion SSH vers le serveur de production, avec cette sortie :
$ ssh -o BatchMode=yes deploiement@serveur.exemple.fr
Permission denied (publickey).
Aucune invite de mot de passe ne s’affiche, ce qui est normal : le mode BatchMode utilisé en CI désactive toute authentification interactive et n’accepte que l’authentification par clé.
Diagnostic : trois causes couvrent la quasi-totalité des cas
Avant de suspecter un problème réseau complexe, il faut vérifier ces trois causes, dans cet ordre, car elles sont les plus fréquentes :
1. La clé privée n’est pas celle attendue par le serveur
Le secret enregistré dans la pipeline (SSH_PRIVATE_KEY) ne correspond peut-être plus à la clé publique installée sur le serveur, souvent après une rotation de clés effectuée d’un côté sans répercussion de l’autre. Une commande simple confirme quelle clé publique correspond à une clé privée donnée :
ssh-keygen -y -f cle_privee.pem
# Compare la sortie avec le contenu de ~/.ssh/authorized_keys sur le serveur
2. La clé est bien acceptée mais restreinte dans authorized_keys
Une clé peut être présente dans authorized_keys mais assortie de restrictions qui bloquent l’usage attendu par la pipeline, par exemple une restriction de commande :
command="rsync --server *",no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... deploiement@ci
Cette ligne n’autorise que l’exécution de rsync côté serveur. Si le script de déploiement tente d’exécuter une autre commande via cette même clé (un wp cache flush distant, par exemple), la connexion elle-même réussit parfois, mais la commande échoue silencieusement ou la connexion est refusée selon la configuration exacte du serveur.
3. Les permissions du fichier ou du dossier sont trop permissives
OpenSSH refuse d’utiliser un fichier authorized_keys ou un dossier .ssh dont les permissions sont trop ouvertes, un contrôle de sécurité qui ne prévient pas toujours clairement dans les journaux :
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Sur un serveur récemment reprovisionné par un script d’installation, ces permissions sont une cause fréquente et rapide à corriger.
Correctif : reconstruire la chaîne de confiance proprement
- Générer une nouvelle paire de clés dédiée exclusivement au déploiement automatisé, jamais réutilisée pour un accès humain :
ssh-keygen -t ed25519 -f cle_deploiement -C "ci-client-a". - Installer la clé publique dans
authorized_keysavec les restrictions strictement nécessaires, sans plus. - Enregistrer la clé privée comme secret chiffré dans la pipeline, jamais dans un fichier versionné.
- Tester la connexion depuis un environnement identique à celui de la CI avant de relancer le job réel, pour éliminer les variables d’environnement locales qui masqueraient le vrai comportement.
Prévention
- Documenter, pour chaque serveur du parc, la liste des clés autorisées et leur usage exact, dans un registre partagé plutôt que dans la mémoire d’une seule personne.
- Séparer systématiquement les clés utilisées par les humains de celles utilisées par les pipelines, pour qu’une rotation de l’une n’affecte jamais l’autre.
- Ajouter une étape de vérification de connexion SSH isolée en tout début de pipeline, avant les étapes coûteuses, pour échouer vite et clairement en cas de problème de clé.
Un message d’erreur laconique cache presque toujours une cause banale : la discipline du diagnostic compte plus que l’intuition.
En résumé
« Permission denied (publickey) » n’est jamais un mystère indéchiffrable : clé incorrecte, clé restreinte ou permissions trop ouvertes couvrent la quasi-totalité des cas rencontrés sur nos pipelines. Vérifier ces trois causes dans l’ordre fait gagner un temps précieux par rapport à une investigation réseau qui partirait dans la mauvaise direction.
