Authentification SSH par clés, sécuriser les accès sans se piéger

Une clé SSH n’est pas une astuce de confort pour éviter de taper un mot de passe. C’est un mécanisme d’authentification cryptographique qui peut sécuriser l’accès aux serveurs, aux dépôts Git, aux bastions et aux environnements de production. Mal géré, il devient pourtant un accès permanent oublié dans un fichier authorized_keys.

Le bon réflexe consiste à traiter chaque clé comme un compte d’accès : elle a un propriétaire, un usage, une machine d’origine, une date de création et un plan de révocation. C’est cette discipline qui transforme une paire de clés en contrôle d’accès fiable, pas la commande ssh-keygen à elle seule.

Voici une méthode pragmatique pour générer, installer, tester et maintenir des clés SSH sans se créer une dette de sécurité. Les exemples sont donnés pour des accès légitimes à vos propres machines ou comptes, jamais pour récupérer les accès d’un tiers.

Comment fonctionne l’authentification SSH par clés ?

L’authentification par clé repose sur une paire : la clé privée, conservée sur votre poste ou dans un agent sécurisé, et la clé publique, déposée sur le serveur dans la liste des accès autorisés. Lors de la connexion, le serveur vérifie que le client possède bien la clé privée correspondant à la clé publique, sans que la clé privée soit transmise.

La différence avec un mot de passe est importante. Un mot de passe peut être deviné, réutilisé, intercepté par hameçonnage ou saisi sur un faux service. Une clé privée correctement protégée ne se devine pas. Elle prouve la possession d’un secret cryptographique, ce qui réduit fortement les attaques par brute force sur l’accès SSH.

Cette protection ne dispense pas de tout le reste. Si votre poste est compromis, si la clé privée est copiée sans passphrase, ou si une clé ancienne reste autorisée sur dix serveurs, l’accès reste dangereux. SSH par clé protège la connexion ; il ne remplace pas l’hygiène des postes, la MFA des services, les bastions, les journaux et la revue des droits.

La règle de base tient en une phrase : la clé publique voyage, la clé privée reste chez vous.

Générer une clé propre selon votre contexte

Sur un poste moderne, la commande la plus simple consiste à générer une clé Ed25519 avec un commentaire explicite. Le commentaire n’est pas un secret ; il sert à reconnaître l’usage de la clé dans les inventaires et sur les plateformes.

ssh-keygen -t ed25519 -C "prenom.nom@entreprise-prod-2026"

Le choix du fichier mérite autant d’attention que l’algorithme. Évitez d’écraser une clé existante si elle sert déjà ailleurs. Donnez un nom qui indique le périmètre d’usage, par exemple id_ed25519_prod, id_ed25519_git ou id_ed25519_client-x. Cette séparation facilite la révocation d’un accès sans casser tous les autres.

Quand une plateforme ancienne ne supporte pas Ed25519, RSA reste possible avec une taille suffisante. OpenSSH indique que 3072 bits est généralement suffisant pour RSA ; dans les environnements prudents, beaucoup d’équipes choisissent 4096 bits pour garder une marge de compatibilité. Le vrai point faible reste souvent la protection de la clé privée, pas la longueur RSA.

Ne laissez pas une clé privée sans passphrase sur un poste utilisateur. Pour les automatisations, préférez une identité dédiée, limitée à une action précise, stockée dans un coffre ou un runner maîtrisé. Une clé d’intégration continue n’a pas à ouvrir une session administrateur interactive sur tous les serveurs.

Pour approfondir ce point, consultez Agents IA et cybermenaces : sécuriser l'autonomie, qui traite plus précisément de agents ia et cybermenaces : sécuriser l'autonomie avant l'incident.

La passphrase n’est pas un détail cosmétique : c’est le dernier verrou local si le fichier de clé est copié.

Dans la pratique, elle doit rester compatible avec l’usage quotidien. Un administrateur peut charger sa clé dans un agent SSH pour la durée de sa session, avec verrouillage du poste et délai d’expiration si le contexte le permet. Une équipe plus exposée peut imposer une clé matérielle ou un coffre local approuvé. L’objectif n’est pas de ralentir chaque connexion, mais d’éviter qu’un simple fichier récupéré dans un profil utilisateur ouvre directement un accès serveur durable.

Évitez aussi la clé “universelle” gardée depuis des années. Elle simplifie le quotidien, puis complique chaque incident.

Installer la clé publique sans casser l’accès serveur

Commencez par préserver l’accès existant. La copie de clé vient avant la coupure des mots de passe.

L’installation consiste à ajouter la clé publique, pas la clé privée, au compte distant. Sur Linux, la destination classique est ~/.ssh/authorized_keys. Sur Windows OpenSSH, le chemin et les permissions varient selon le type de compte ; c’est précisément le point à vérifier dans la documentation Microsoft avant de généraliser. Dans les deux cas, documentez le compte cible, le chemin exact et la méthode de retour arrière avant de toucher à la configuration serveur.

Si vous utilisez ssh-copy-id, gardez une session déjà ouverte pendant le test. Si vous copiez manuellement la clé, contrôlez le répertoire .ssh, le propriétaire du fichier et les permissions. Beaucoup de pannes viennent d’un fichier lisible par trop de monde ou placé dans le mauvais profil utilisateur.

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat id_ed25519_prod.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Après ajout, testez une connexion explicite avec la bonne identité. Cette commande évite de croire qu’une clé fonctionne alors que votre client en utilise une autre déjà chargée dans l’agent.

ssh -i ~/.ssh/id_ed25519_prod utilisateur@serveur

Le durcissement serveur vient seulement après. Avant de définir PasswordAuthentication no, ouvrez une nouvelle session et vérifiez que la clé fonctionne pour le bon compte. Gardez une console de secours ou un accès fournisseur tant que la configuration n’a pas été validée. Se verrouiller hors du serveur est l’erreur classique.

Durcir la configuration sans perdre l’exploitation

Le bon durcissement est celui que vous pouvez tester, expliquer et annuler pendant la fenêtre de changement.

Une fois la connexion testée, vous pouvez réduire l’exposition. Les directives serveur les plus courantes concernent l’authentification par clé publique, les mots de passe, l’accès root et parfois le forwarding. Le but n’est pas d’empiler des options au hasard, mais de protéger le chemin d’administration réel. Une règle trop dure, appliquée sans test, crée parfois plus de risque opérationnel qu’elle n’en retire, surtout sur un serveur isolé sans console fournisseur fiable.

Sur un serveur accessible depuis Internet, désactiver les mots de passe après validation des clés limite fortement les tentatives automatisées. Interdire l’accès direct de root pousse aussi à passer par un compte nommé puis une élévation contrôlée. En revanche, si votre supervision, votre sauvegarde ou votre procédure d’urgence dépend encore d’un accès mot de passe, corrigez ce processus avant de couper brutalement.

La configuration peut ressembler à ceci, à adapter à votre système et à valider avec la commande de test du service avant redémarrage.

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no

Ajoutez ensuite les contrôles d’exploitation : journalisation des connexions, alertes sur les échecs, inventaire des comptes autorisés, bastion pour les environnements sensibles et procédure de révocation. Une clé SSH n’est pas seulement un fichier ; c’est une autorisation de production.

Le durcissement doit rester réversible pendant l’intervention. Notez le plan de retour arrière avant de modifier le service SSH.

1. Gardez une session ouverte pendant chaque modification SSH.
2. Testez la syntaxe du service avant de redémarrer.
3. Documentez le propriétaire et l’usage de chaque clé publique.
4. Évitez les clés partagées entre plusieurs administrateurs.
5. Réservez les clés sans passphrase aux automates strictement limités.
6. Surveillez les connexions depuis des IP ou horaires inhabituels.

Organiser les clés dans une équipe

Ici, le risque principal tient rarement à l’algorithme. Il tient à l’accès oublié.

Dans une PME, le problème n’est pas toujours la cryptographie. C’est l’accumulation : stagiaires, freelances, prestataires, anciens postes, serveurs oubliés, clés de CI et scripts de sauvegarde. Sans inventaire, personne ne sait qui peut encore entrer sur quoi.

La meilleure pratique est de créer une clé par personne et par contexte sensible. Une clé pour Git personnel, une clé pour production, une clé pour un client, une clé pour une automatisation. Cette séparation paraît contraignante au départ, mais elle évite de devoir couper tous les accès quand une seule machine est perdue.

Les commentaires dans les clés publiques, les fichiers d’inventaire et les revues périodiques font gagner du temps. Une entrée authorized_keys sans propriétaire identifiable doit être traitée comme un accès suspect jusqu’à preuve du contraire. Pour les environnements plus avancés, les certificats SSH ou un bastion centralisé peuvent réduire le nombre de clés à copier partout.

La révocation doit être aussi simple que l’ajout. Si une clé de prestataire sert à la fois au dépôt Git, au serveur de recette et à la production, chaque retrait devient une mini-enquête. Avec des clés séparées par périmètre, vous retirez uniquement l’accès concerné et vous gardez une trace claire dans le journal de changement. C’est ce qui permet de répondre vite après une perte de poste, une fin de mission ou une suspicion de compromission, sans casser les accès légitimes encore nécessaires.

Un inventaire incomplet n’est pas neutre : il transforme chaque urgence en recherche manuelle.

Trois routines qui évitent les clés fantômes

La sécurité SSH se joue surtout après la première installation.

Revue des accès

Relisez régulièrement les clés autorisées par serveur, compte et usage réel.

Dépannage contrôlé

Avant de changer partout, vérifiez identité utilisée, permissions et logs serveur.

Inventaire exploitable

Associez chaque clé à un propriétaire, un périmètre, une date de revue et une révocation possible.

Dépanner une clé SSH qui refuse de passer

Ne commencez pas par régénérer une clé. Un refus de connexion ne signifie pas forcément que la clé est mauvaise : vérifiez d’abord quelle identité SSH est réellement présentée avec ssh -v. Si l’agent SSH contient plusieurs clés, le serveur peut refuser avant d’arriver à la bonne, ou le client peut ne pas utiliser le fichier que vous pensez.

Contrôlez ensuite les permissions. Côté client, la clé privée ne doit pas être lisible par d’autres utilisateurs. Côté serveur, ~/.ssh et authorized_keys doivent appartenir au bon compte et ne pas être trop ouverts. Sur Windows, les ACL remplacent la logique Unix classique, d’où l’intérêt de suivre la documentation OpenSSH adaptée.

Regardez enfin les journaux serveur. Ils indiquent souvent si la clé est ignorée pour permission incorrecte, si le compte est bloqué, si la directive PubkeyAuthentication n’est pas active ou si le fichier autorisé n’est pas celui attendu. Ne corrigez pas en rendant tout permissif : ce serait déplacer le problème vers une faille d’accès.

La règle simple pour ne pas se piéger

SSH par clé est une très bonne base, mais pas une solution magique. La sécurité vient du trio clé protégée, serveur durci et accès gouvernés. Si l’un des trois manque, l’organisation garde une faiblesse : clé volée, mot de passe encore ouvert, compte partagé ou accès oublié.

Pour un poste individuel, commencez par une clé Ed25519 avec passphrase, un commentaire clair et un usage limité. Pour une équipe, ajoutez un inventaire, une revue trimestrielle, une procédure de retrait et des clés séparées par contexte. Pour une production sensible, envisagez bastion, MFA, clé matérielle ou certificats SSH.

La prochaine action utile est donc concrète : ouvrez un serveur critique, listez les entrées authorized_keys, et supprimez d’abord ce que personne ne sait expliquer.

Pour approfondir ce point, consultez RDP et Bureau à distance : comprendre,, qui traite plus précisément de rdp et bureau à distance : comprendre, utiliser et sécuriser l’accès distant.