Vous gérez des serveurs, un dépôt Git, ou un VPS en production et vous craignez la compromission d’un mot de passe faible ? La multiplication des accès à distance et des outils DevOps met votre sécurité réseau sous pression, surtout quand l’équipe s’agrandit et que les accès s’accumulent sans suivi clair.
La réponse tient en trois actions concrètes : générer une clé SSH moderne (ED25519), installer la clé publique sur le serveur SSH, puis tester la connexion sécurisée avant d’ajuster la configuration. En moins de dix minutes, vous passez d’un risque de vol de mot de passe à une authentification par clé robuste, fondée sur une cryptographie éprouvée.
Nous allons d’abord montrer la méthode la plus sûre en pratique, puis détailler les commandes pour Linux, macOS et Windows, renforcer la configuration SSH côté serveur, intégrer GitHub/GitLab et terminer par une trousse de gestion des clés et de dépannage avancé. À la fin, vous aurez un parcours complet, prêt à l’emploi.
En bref
Pour sécuriser vos connexions, créez une clé ED25519, installez la clé publique sur vos hôtes, puis validez l’accès avant tout durcissement.
- Générez une clé ED25519 avec passphrase et chargez-la dans ssh-agent.
- Installez la clé publique dans ~/.ssh/authorized_keys sur chaque serveur SSH.
- Testez la connexion avant de désactiver les mots de passe côté serveur.
- Activez des réglages sûrs (Port, PubkeyAuthentication, PasswordAuthentication no après test).
- Utilisez les agents (Keychain macOS, OpenSSH Agent Windows) pour la gestion quotidienne.
Une fois ces étapes validées, vous bénéficiez d’une authentification par clé fiable et d’un transfert sécurisé sur tout votre parc.
Configurer une clé SSH pour une connexion sécurisée : les étapes essentielles
Allons droit au but : la manière la plus sûre en 2026 consiste à créer une clé SSH ED25519, protégée par une passphrase, puis à placer la clé publique sur chaque hôte cible. Ce choix repose sur une cryptographie rapide et solide, mieux adaptée que RSA pour la majorité des usages courants.
La séquence gagne en fiabilité si vous chargez votre clé dans un ssh-agent (ou le trousseau macOS) pour éviter de retaper la passphrase à chaque commande. Ensuite, vous copiez la clé publique dans le fichier authorized_keys du compte utilisateur sur le serveur SSH afin d’autoriser la machine cliente.
Point critique : n’activez pas immédiatement la désactivation des mots de passe côté serveur. Il faut d’abord vérifier la connexion par clé au moins une fois, idéalement depuis deux postes, afin d’éviter un verrouillage accidentel. C’est la garde-fou numéro un des guides professionnels.
Pour illustrer, Nadia, responsable IT d’une PME multi-sites, a d’abord généré une clé ED25519 unique par administrateur, testé l’accès à ses VPS, puis appliqué les durcissements. Résultat : une connexion sécurisée et une traçabilité par clé, tout en réduisant la surface d’attaque. Retenez cette logique : clé, test, durcissement.
Générer et installer votre clé SSH sur Linux, macOS et Windows
Sur Linux et macOS, ouvrez un terminal et exécutez : ssh-keygen -t ed25519 -C “votre_email”. Choisissez un emplacement par défaut (~/.ssh/id_ed25519) et définissez une passphrase forte. La clé publique (~/.ssh/id_ed25519.pub) est celle à partager, jamais la clé privée.
Chargez ensuite la clé dans l’agent : sur Linux/macOS, lancez eval “$(ssh-agent -s)” puis ssh-add ~/.ssh/id_ed25519. Sur macOS, vous pouvez intégrer le trousseau avec ssh-add –apple-use-keychain pour mémoriser la passphrase de façon sûre. L’objectif : fluidifier l’usage quotidien sans sacrifier la protection.
Pour installer la clé publique sur un hôte Linux, utilisez ssh-copy-id user@serveur si disponible. Sinon, copiez manuellement le contenu de id_ed25519.pub dans ~/.ssh/authorized_keys sur le serveur, en veillant aux permissions (~/.ssh à 700 et authorized_keys à 600). Un simple ssh user@serveur doit ensuite s’authentifier par clé.
Sous Windows, privilégiez l’OpenSSH natif (Windows 10+). Générez via PowerShell : ssh-keygen -t ed25519 -C “[email protected]”, puis lancez l’agent avec Start-Service ssh-agent et ssh-add. Copiez la clé publique dans authorized_keys côté serveur. Testez, puis conservez la clé dans l’agent Windows pour un confort similaire à macOS. Le message clé : une procédure identique sur les trois OS, avec un agent pour la gestion des clés.
Après ce premier test réussi, vous pouvez planifier le durcissement côté serveur. En cas d’échec, vérifiez l’empreinte de la clé, les permissions et l’agent. Une méthode simple, reproductible, et adaptée aux équipes hybrides.
Durcir la configuration du serveur SSH sans se couper l’accès
Le durcissement se fait dans /etc/ssh/sshd_config et doit être progressif. Commencez par confirmer PubkeyAuthentication yes et restreignez l’accès avec AllowUsers ou AllowGroups. Déplacez éventuellement le port avec Port 22→2222 pour réduire le bruit des scans, même si ce n’est pas une défense suffisante en soi.
Une bonne pratique est d’interdire l’accès direct à root : PermitRootLogin prohibit-password ou no, puis usage de sudo après connexion avec un compte nominatif. Une fois les tests par clé validés, basculez sur PasswordAuthentication no et, si possible, ChallengeResponseAuthentication no pour bloquer les mots de passe et OTP non nécessaires.
Ajoutez des garde-fous contre la force brute : MaxAuthTries 3, LoginGraceTime 30 et ClientAliveInterval/ClientAliveCountMax pour gérer les sessions inactives. Complétez avec Fail2ban ou un pare-feu réseau, et, pour les environnements sensibles, limitez à des adresses IP sources connues via firewall ou AllowUsers user@host.
Checklist rapide pour un serveur robuste :
- Clé ED25519 testée depuis au moins deux clients.
- Root désactivé en SSH direct, usage de sudo.
- Mots de passe coupés (PasswordAuthentication no) après validation.
- Port déplacé et pare-feu en place.
- Journaux surveillés et détections d’anomalies actives.
Avant de redémarrer le service (systemctl restart sshd), gardez une session ouverte pour revenir en arrière en cas d’erreur. Le principe cardinal : un durcissement mesuré, jamais au détriment de la disponibilité.
Utiliser sa clé SSH avec GitHub, GitLab et les automatisations
Pour les plateformes de code, ajoutez votre clé publique dans les paramètres SSH de GitHub/GitLab, puis testez avec ssh -T [email protected] ou l’équivalent GitLab. Configurez l’URL distante en SSH (git@…) pour un transfert sécurisé et moins d’incidents liés aux tokens expirés.
Au quotidien, facilitez-vous la vie avec un ssh-agent qui garde la clé en mémoire chiffrée. Sur macOS, le Keychain s’intègre nativement ; sous Windows, l’agent OpenSSH joue ce rôle. Sur Linux, systemd gère très bien l’agent utilisateur. Cette gestion des clés évite la saisie répétée de la passphrase et encourage de meilleures pratiques.
En CI/CD, préférez des clé de déploiement en lecture seule pour chaque dépôt, ou des clés dédiées par environnement. Une authentification par clé scindée par projet minimise l’impact d’une compromission. Si vous utilisez Ansible/Terraform, centralisez vos clés et limitez leur durée de vie, par exemple via des agents éphémères.
Ne négligez pas scp et sftp pour le transfert sécurisé de fichiers. Un simple scp fichier user@serveur:/chemin réutilise votre clé existante et respecte le protocole SSH. En pratique, Nadia a standardisé les flux de déploiement avec des clés par environnement, réduisant les accès superflus et clarifiant l’audit. Le mot d’ordre : segmentation et automatismes.
Une fois vos plateformes alignées, la cohérence des accès devient votre meilleure défense. Tout est traçable, renouvelable et compatible avec l’outillage moderne.
Dépannage, rotation et choix des algorithmes : garder une longueur d’avance
Quand un accès échoue, lancez ssh -v (ou -vvv) pour analyser la négociation. Les causes typiques : permissions incorrectes (~/.ssh/600, authorized_keys/600), clé non chargée dans l’agent, ou mismatch d’utilisateur/host. Vérifiez aussi la présence de votre bloc de clé dans authorized_keys et les logs du serveur.
La rotation des clés est un réflexe d’hygiène : générez une nouvelle clé, installez-la, testez, puis retirez l’ancienne. Pour des équipes, tenez un registre des empreintes et propriétaires. Les clés personnelles doivent être protégées par passphrase, et stockées sur un disque chiffré, avec sauvegarde hors ligne.
Concernant les algorithmes, ED25519 reste un excellent choix en 2026 pour sa robustesse et sa vitesse. RSA demeure présent pour la compatibilité avec d’anciens systèmes, mais privilégiez une taille de 4096 bits au minimum. ECDSA est plus rare en production neuve, et les clés matérielles FIDO2/U2F offrent une résistance au phishing irréprochable.
Comparatif rapide pour choisir sereinement :
| Algorithme | Taille conseillée | Performance | Compatibilité | Usage recommandé |
|---|---|---|---|---|
| ED25519 | Fixe (255 bits) | Très rapide | Large (systèmes récents) | Par défaut en 2026 |
| RSA | 4096 bits | Plus lent | Excellente (legacy) | Compatibilité héritée |
| ECDSA | 256/384/521 | Rapide | Variable | Environnements contrôlés |
| FIDO2/U2F | N/A (clé matérielle) | Très rapide | Clients/serveurs compatibles | Haut niveau avec 2FA |
Pensez enfin à la sécurité réseau globale : filtrage IP, journalisation centralisée, alertes sur tentatives anormales, et sauvegardes chiffrées transférées via protocole SSH. Un dispositif cohérent protège la clé, mais aussi le chemin qu’elle emprunte.
Dois-je désactiver l’authentification par mot de passe immédiatement ?
Non. Testez d’abord l’accès par clé depuis au moins un deuxième poste. Une fois confirmé, désactivez PasswordAuthentication pour éviter un verrouillage accidentel.
Quelle est la meilleure clé en 2026 ?
ED25519 offre un excellent compromis robustesse/vitesse. RSA 4096 reste utile pour la compatibilité avec des systèmes anciens. Les clés matérielles FIDO2 sont un plus pour des besoins très sensibles.
Comment gérer mes passphrases au quotidien ?
Utilisez ssh-agent : macOS peut les stocker dans le Keychain, Windows avec l’agent OpenSSH, Linux via systemd. Vous tapez la passphrase une fois, l’agent s’occupe du reste.
Puis-je utiliser ma clé SSH pour transférer des fichiers ?
Oui. scp et sftp réemploient votre clé pour un transfert sécurisé, sans mot de passe. Exemple : scp fichier user@serveur:/chemin.
Que faire si ma clé a fuité ?
Révoquez-la immédiatement (retirez-la des authorized_keys), générez une nouvelle clé, inspectez les journaux, et changez toutes les clés ou secrets pouvant avoir été exposés.