Une clé SSH est un couple de fichiers cryptographiques qui authentifie un utilisateur auprès d’un serveur distant.
Ce mécanisme remplace le mot de passe et offre une méthode plus sûre pour établir une connexion sécurisée.
Le lecteur trouvera ici des explications pratiques, des exemples concrets et des gestes à éviter.
En bref
La clé SSH permet un accès SSH sécurisé sans transmettre de mot de passe sur le réseau.
- Génération simple : créez une paire publique/privée avec ssh-keygen.
- Transfert sécurisé : installez la clé publique sur le serveur via ssh-copy-id ou panneau d’hébergement.
- Gestion pratique : utilisez ssh-agent pour charger plusieurs clés sans répéter les phrases de passe.
- Bonne hygiène : stockez la clé privée à l’abri et remplacez-la en cas de compromission.
Lire la suite pour des instructions pas à pas et des exemples adaptés aux indépendants et TPE.
c’est quoi une clé SSH : définition simple pour indépendants
Pour répondre clairement à la question « c’est quoi une clé SSH », il faut commencer par la notion de paire.
Une clé SSH se compose de deux éléments liés mathématiquement : une clé privée et une clé publique.
La clé privée reste sur l’ordinateur de l’utilisateur et ne doit jamais être partagée.
La clé publique est copiée sur le serveur pour permettre l’authentification sans mot de passe.
Quand l’utilisateur tente une connexion, le serveur vérifie la correspondance entre la clé publique et la clé privée.
Cette vérification s’appuie sur la cryptographie asymétrique, qui évite d’envoyer la clé privée sur le réseau.
Pour un commerçant ou un artisan, la logique est simple : la clé remplace le mot de passe par un jeton sécurisé.
Elle limite les risques de capture de mot de passe lors d’un accès distant sur un réseau public.
Un exemple concret : Marie, photographe indépendante, utilise une clé SSH pour accéder à son VPS.
Elle installe seulement la clé publique sur le serveur et conserve la privée sur son ordinateur portable.
Ainsi, même si quelqu’un intercepte la session réseau, il ne pourra pas reproduire l’authentification.
La clé SSH se révèle particulièrement adaptée aux méthodes de travail avec Git, transfert de fichiers et administration serveur.
Pour résumer, c’est quoi une clé SSH : c’est un couple de clés qui sécurise l’authentification sans mot de passe.
À retenir : La clé réduit l’exposition aux attaques par mot de passe tout en simplifiant les connexions répétées.
Pourquoi la clé SSH sécurise mieux qu’un mot de passe
Comparer la clé SSH au mot de passe permet d’identifier les gains concrets en sécurité.
Un mot de passe peut être réutilisé, deviné ou volé via une attaque par force brute ou phishing.
La clé SSH repose sur une paire unique, où la clé privée n’est jamais transmise sur le réseau.
La présence d’une phrase de passe sur la clé privée renforce la protection en cas de vol du fichier.
Les algorithmes modernes comme Ed25519 offrent une sécurité élevée avec des clés compactes et rapides.
RSA reste compatible avec d’anciens systèmes, mais nécessite des tailles de clé plus importantes, comme 2048 ou 4096 bits.
Pour un dirigeant de TPE, le résultat est concret : la surface d’attaque diminue nettement.
L’authentification se base sur la preuve mathématique de possession de la clé privée, pas sur une information partagée.
On évite ainsi la vulnérabilité aux enregistreurs de frappes ou aux captures de sessions qui ciblent les mots de passe.
Un exemple : un prestataire déployant des mises à jour se connecte via clé SSH, évitant la transmission de mots de passe par email.
Si la clé privée est protégée par une phrase de passe, voler le fichier ne suffit pas pour se connecter au serveur.
Les bonnes pratiques incluent la désactivation de l’authentification par mot de passe côté serveur pour forcer l’usage des clés.
Ce mécanisme limite aussi la propagation : une clé compromise n’affecte pas les autres si des paires distinctes sont utilisées.
Tableau comparatif des options d’algorithmes et recommandations :
| Algorithme | Taille/format | Compatibilité | Usage recommandé |
|---|---|---|---|
| Ed25519 | 256 bits | Modernes | Connexion SSH quotidienne, Git |
| RSA | 2048 / 4096 bits | Très large | Compatibilité avec anciens serveurs |
| Ecdsa | 256-521 bits | Assez répandue | Usage sécurisé mais variable |
À retenir : L’adoption de Ed25519 est recommandée quand la compatibilité le permet, pour un meilleur ratio sécurité/performance.
Comment utiliser une clé SSH pour l’accès SSH et Git
Mettre en place une clé SSH se déroule en quelques étapes simples et reproductibles pour un indépendant.
Étape 1 : générer la paire avec la commande ssh-keygen -t ed25519 ou -t rsa.
Étape 2 : choisir l’emplacement de stockage et définir une phrase de passe robuste pour la clé privée.
Les utilisateurs Windows peuvent utiliser PowerShell, WSL, Git Bash ou PuTTY selon leurs préférences.
Git Bash facilite l’intégration avec les dépôts Git et la gestion des clés pour les développeurs non experts.
Pour installer la clé publique sur un serveur, la commande ssh-copy-id username@remote_server fonctionne sur Linux et macOS.
Alternativement, utiliser le panneau d’hébergement pour coller la clé publique évite toute commande en ligne.
Exemple concret : un artisan web transfère la clé publique via le tableau de bord de l’hébergeur pour autoriser le deploy.
Pour Git, il suffit d’ajouter la clé publique à la liste des clés SSH du service d’hébergement de code.
La connexion SSH devient alors possible sans mot de passe, rendant le push et les déploiements automatisés plus simples.
Utiliser ssh-agent permet de charger la clé privée en mémoire et d’éviter la saisie répétée de la phrase de passe.
Commandes utiles : eval « $(ssh-agent -s) » puis ssh-add ‘chemin_de_la_cle’ pour ajouter la clé à l’agent.
Un bon réflexe est d’ajouter un commentaire lors de la génération avec -C ‘nom_projet’ pour identifier la clé plus tard.
À retenir : La combinaison ssh-agent et une phrase de passe protège et simplifie l’usage quotidien.
Bonnes pratiques et erreurs à éviter avec les clés SSH
Une bonne gestion des clés SSH protège une entreprise contre des incidents évitables et coûteux.
Ne jamais partager la clé privée, même avec un prestataire non vérifié, et conserver des copies sécurisées.
Éviter d’utiliser la même paire de clés pour plusieurs serveurs ou services afin d’isoler les risques potentiels.
Attribuer des clés différentes par projet ou par prestataire facilite la révocation en cas d’incident.
Configurer le fichier ~/.ssh/config pour associer une clé spécifique à un hôte évite les erreurs de sélection.
Restreindre les permissions de fichiers avec chmod 600 pour la clé privée est une étape simple et efficace.
Ne pas négliger la phrase de passe : elle transforme un fichier compromis en ressource inutilisable sans la phrase.
Erreur classique : stocker la clé privée sur un disque non chiffré ou dans un dossier accessible à d’autres comptes.
Une autre erreur fréquente est d’oublier de retirer une clé publique d’un serveur lorsqu’un collaborateur quitte l’équipe.
Liste de contrôle rapide pour la sécurité des clés SSH :
- Utiliser une phrase de passe forte pour chaque clé privée.
- Stocker la clé privée sur un disque chiffré ou dans un gestionnaire sécurisé.
- Isoler les clés par projet ou par prestataire.
- Révoquer immédiatement les clés compromises sur tous les serveurs.
- Mettre à jour régulièrement les paires pour réduire la fenêtre d’exposition.
Exemple : une agence de communication a perdu l’accès à un serveur parce qu’une clé privée était sauvegardée sur un poste partagé.
La leçon pratique fut d’imposer des clés distinctes pour chaque collaborateur et des audits trimestriels.
À retenir : La discipline dans la gestion des clés vaut mieux que des solutions techniques compliquées et rares.
Gestion, rotation et récupération d’une clé SSH compromise
En cas de compromission d’une clé privée, agir vite réduit les dommages et restaure la sécurité du service.
Première étape : supprimer la clé publique compromise de tous les serveurs concernés sans délai.
Sur un poste local, naviguer vers ~/.ssh et supprimer les fichiers de clés privatifs et publics compromis.
Ensuite, générer rapidement une nouvelle paire avec ssh-keygen et installer la nouvelle clé publique sur les serveurs.
Informer le prestataire ou l’équipe technique de la rotation afin d’éviter toute interruption involontaire.
Utiliser la commande ls pour vérifier la suppression et ssh-add -l pour contrôler les clés chargées dans l’agent.
Dans des environnements critiques, documenter la rotation dans un registre de sécurité pour pouvoir tracer les actions.
Plan de récupération succinct pour une TPE :
- Identifier les serveurs où la clé est installée.
- Révoquer la clé compromise sur chaque serveur.
- Générer une nouvelle paire et déployer la clé publique.
- Changer les accès liés et vérifier les logs d’accès récents.
Exemple pratique : un site marchand détecte une clé compromise et la remplace en moins d’une heure, évitant ainsi toute fuite de données.
Conseil utile : maintenir une procédure écrite pour la rotation des clés et former les collaborateurs aux gestes de sécurité.
À retenir : La rotation planifiée réduit fortement la fenêtre d’exploitation d’une clé compromise et protège la continuité de service.
Comment générer une clé SSH sur Windows ?
Utilisez PowerShell, WSL, Git Bash ou PuTTY selon vos préférences. Exécutez ssh-keygen -t ed25519 dans Git Bash ou WSL, puis protégez la clé privée avec une phrase de passe.
Puis-je utiliser la même clé SSH pour plusieurs serveurs ?
Il est possible mais déconseillé. Utiliser des paires distinctes par serveur ou projet limite les risques en cas de compromission.
Que faire si ma clé privée est compromise ?
Supprimez la clé publique sur tous les serveurs, régénérez une paire, déployez la nouvelle clé et changez les accès concernés.