Sécuriser un serveur SSH avec une clé sans perdre l’accès

Pour sécuriser un serveur SSH avec une clé, créez une paire de clés publique et privée, installez uniquement la clé publique sur le serveur, puis testez une nouvelle connexion avant de désactiver les mots de passe. Ajoutez ensuite PermitRootLogin no, limitez les comptes autorisés et gardez un accès de récupération hors SSH.

L’authentification SSH par clé remplace un secret mémorisable par une preuve cryptographique. Le mécanisme réduit l’exposition aux tentatives automatisées par mot de passe, mais une mauvaise séquence de configuration peut bloquer l’administrateur. Ce tutoriel montre les commandes à exécuter, les vérifications à faire et les options de retour arrière.

Pourquoi l’authentification SSH par clé renforce-t-elle la sécurité ?

L’authentification SSH par clé est une méthode où le client prouve qu’il possède une clé privée correspondant à une clé publique connue du serveur. Le serveur ne reçoit jamais la clé privée et ne vérifie pas un mot de passe transmis par l’utilisateur. Cette séparation protège mieux contre les essais massifs de mots de passe sur un serveur exposé à Internet.

Une clé publique peut être distribuée au serveur, alors qu’une clé privée ne doit jamais quitter le poste qui l’utilise. La clé privée doit être protégée par des droits de fichiers stricts et, de préférence, par une phrase secrète lors de sa création.

Élément	Emplacement normal	Rôle	Risque à éviter
Clé privée	Ordinateur client, par exemple ~/.ssh/id_ed25519	Prouver l’identité de l’administrateur	La copier sur le serveur ou la transmettre
Clé publique	Serveur, dans ~/.ssh/authorized_keys	Autoriser une clé privée correspondante	Modifier son contenu ou ses droits par erreur
Configuration OpenSSH	Souvent /etc/ssh/sshd_config	Définir les méthodes de connexion acceptées	Recharger le service sans validation préalable

La règle qui évite le verrouillage est simple : une connexion par clé doit fonctionner dans une nouvelle session avant la désactivation de PasswordAuthentication.

Préparer la sécurisation du serveur Linux

OpenSSH est le logiciel qui fournit couramment le service SSH sur les distributions Linux. Les emplacements de fichiers et le nom du service peuvent varier entre Debian, Ubuntu, Fedora, Rocky Linux, AlmaLinux ou Manjaro. La logique ne change pas : identifier le service actif, sauvegarder la configuration et prévoir un accès de récupération avant toute modification.

Une console fournie par l’hébergeur, une console KVM, une interface de secours ou un accès physique permet de corriger un fichier sshd_config même si SSH devient inaccessible. Un serveur sans accès hors bande ne doit pas recevoir une configuration restrictive non testée.

Étape 1 : vérifier les accès de récupération

Ouvrez le tableau de bord de votre hébergeur ou vérifiez l’accès à la console locale avant de modifier OpenSSH. Notez également l’adresse IP ou le nom DNS du serveur, le compte d’administration utilisé et le port SSH actuel. Le résultat attendu est un moyen de connexion alternatif qui ne dépend pas du service SSH en cours de modification.

Étape 2 : identifier le service SSH et sa configuration

Connectez-vous au serveur avec la session existante, puis vérifiez le statut du service. Sur de nombreuses distributions, l’une des deux commandes suivantes convient :

sudo systemctl status ssh
sudo systemctl status sshd

Repérez le service marqué comme actif. Vérifiez aussi les fichiers de configuration effectivement pris en compte avec la documentation de votre distribution : OpenSSH peut charger des fragments depuis un répertoire comme /etc/ssh/sshd_config.d/. Le résultat attendu est de savoir quel service recharger et où placer les directives.

Étape 3 : sauvegarder la configuration existante

Créez une copie datée du fichier principal avant toute édition. La commande suivante conserve un point de retour local :

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Si votre distribution utilise des fichiers inclus, sauvegardez aussi le fragment que vous modifierez. Une sauvegarde n’aide que si elle est accessible depuis la console de récupération ; le résultat attendu est donc un fichier restaurable sans dépendre d’une session SSH fonctionnelle.

• Conservez la session SSH actuelle ouverte jusqu’à la fin du tutoriel.
• Préparez une seconde fenêtre de terminal pour les essais.
• Ne publiez jamais le contenu d’une clé privée dans un ticket, un dépôt Git ou un échange de messagerie.

Comment créer et installer une clé SSH sur le serveur ?

Créez une paire de clés sur l’ordinateur client, copiez uniquement la clé publique vers le compte Linux ciblé, puis vérifiez les permissions du répertoire .ssh. La commande ssh-keygen -t ed25519 génère une paire moderne et couramment prise en charge par OpenSSH. La clé privée reste sur le client ; le serveur reçoit le fichier public.

Cette étape doit être exécutée depuis l’ordinateur avec lequel vous administrerez le serveur, pas depuis le serveur distant. Une installation réussie crée ou complète le fichier ~/.ssh/authorized_keys pour le compte choisi.

Étape 4 : générer une paire ed25519 sur le poste client

Dans un terminal local, lancez la commande suivante. Acceptez l’emplacement proposé seulement si vous n’utilisez pas déjà un fichier portant ce nom.

ssh-keygen -t ed25519

Ajoutez une phrase secrète lorsque l’outil la demande. La phrase secrète protège la clé privée en cas de copie non autorisée du fichier. Le résultat attendu est la création de deux fichiers : ~/.ssh/id_ed25519 pour la clé privée et ~/.ssh/id_ed25519.pub pour la clé publique.

Étape 5 : protéger la clé privée SSH

Réduisez les droits de la clé privée afin qu’elle ne soit lisible que par votre compte local. Exécutez la commande suivante sur l’ordinateur client :

chmod 600 ~/.ssh/id_ed25519

Les clients SSH refusent parfois une clé dont les permissions sont trop ouvertes, car cela indiquerait que d’autres comptes locaux pourraient la lire. Le résultat attendu est une clé privée utilisable uniquement par son propriétaire.

Étape 6 : copier la clé publique avec ssh-copy-id

Remplacez admin par le compte Linux autorisé sur le serveur et adresse_du_serveur par son adresse IP ou son nom DNS. Cette commande demande encore le mot de passe actuel : c’est normal, car la bascule n’a pas encore eu lieu.

ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@adresse_du_serveur

La commande ajoute la clé publique au fichier ~/.ssh/authorized_keys du compte distant. Le résultat attendu est un message indiquant qu’une clé a été ajoutée, sans exposition de la clé privée.

Étape 7 : installer la clé publique manuellement si nécessaire

Lorsque ssh-copy-id n’est pas installé, affichez la clé publique locale avec cat ~/.ssh/id_ed25519.pub, puis copiez sa ligne complète. Sur le serveur, créez le répertoire et le fichier avec des permissions adaptées :

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Collez une seule clé publique par ligne dans authorized_keys. Le résultat attendu est un fichier détenu par le compte distant, non accessible en écriture par d’autres utilisateurs.

Comment tester la connexion SSH par clé avant de désactiver les mots de passe ?

Ouvrez une nouvelle session de terminal et forcez l’utilisation de la clé avec ssh -i ~/.ssh/id_ed25519 admin@adresse_du_serveur. La session SSH d’origine doit rester ouverte pendant le test. Une connexion réussie sans demande du mot de passe du compte distant prouve que la clé publique, les permissions et le chemin de la clé sont cohérents.

Un mot de passe demandé pendant ce test est un signal d’arrêt. La connexion par clé n’est pas prête ou le client bascule encore vers une autre méthode. Corrigez le problème avant de toucher à PasswordAuthentication.

Étape 8 : ouvrir une seconde session et observer l’authentification

Utilisez une seconde fenêtre de terminal et lancez une connexion détaillée. L’option -v affiche les étapes de négociation sans révéler la clé privée :

ssh -v -i ~/.ssh/id_ed25519 admin@adresse_du_serveur

Recherchez une ligne indiquant qu’une clé publique est proposée puis acceptée. Le test est validé seulement si le serveur accepte la clé et ouvre une session sans exiger le mot de passe du compte Linux. Le résultat attendu est une méthode d’accès indépendante des mots de passe.

Étape 9 : diagnostiquer une clé SSH refusée

Une erreur « Permission denied (publickey) » provient souvent d’une clé publique absente, d’un mauvais utilisateur, de permissions incorrectes ou d’une directive OpenSSH restrictive. Vérifiez le compte distant, puis comparez la clé publique locale avec la ligne présente dans authorized_keys.

• Vérifiez que ~/.ssh appartient bien au compte distant et possède le mode 700.
• Vérifiez que authorized_keys appartient au même compte et possède le mode 600.
• Vérifiez que la connexion cible le bon utilisateur, par exemple admin@adresse_du_serveur.
• Consultez les journaux système depuis la console si le serveur refuse toujours la clé.

Les commandes de journalisation dépendent de la distribution. Sur un système utilisant systemd, la commande suivante peut aider à observer le service SSH pendant un nouvel essai :

sudo journalctl -u sshd -f

Comment désactiver le mot de passe SSH sans se verrouiller ?

Modifiez la configuration du serveur seulement après le test concluant de la clé dans une nouvelle session. Activez explicitement l’authentification par clé, désactivez l’authentification par mot de passe et interdisez la connexion SSH directe de root. Validez ensuite la syntaxe avec sshd -t avant de recharger le service.

Une directive peut être définie dans le fichier principal ou dans un fragment chargé par OpenSSH. Vérifiez la politique de votre distribution avant de dupliquer des options contradictoires dans plusieurs fichiers.

Étape 10 : ajouter les directives essentielles dans sshd_config

Éditez le fichier de configuration applicable avec les privilèges administrateur. Sur de nombreux systèmes, le fichier principal est /etc/ssh/sshd_config :

sudo nano /etc/ssh/sshd_config

Ajoutez ou ajustez les lignes suivantes. Adaptez admin au compte réellement utilisé pour l’administration.

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
AllowUsers admin

PubkeyAuthentication yes autorise les clés publiques. PasswordAuthentication no refuse les mots de passe SSH. PermitRootLogin no interdit la connexion directe de root ; l’administration passe alors par un compte nominatif doté de droits sudo. AllowUsers limite l’accès SSH aux comptes explicitement listés.

Désactiver le mot de passe protège le service SSH contre les tentatives de devinette, mais ne remplace ni la protection de la clé privée ni le contrôle des comptes autorisés.

Étape 11 : valider la syntaxe avant le rechargement

Ne redémarrez pas OpenSSH à l’aveugle. Vérifiez la syntaxe du fichier avant toute application :

sudo sshd -t

Une commande silencieuse signifie généralement que la syntaxe est valide. Un message d’erreur indique la ligne ou le paramètre à corriger. Le résultat attendu est une configuration syntaxiquement acceptable, sans interruption du service existant.

Étape 12 : recharger OpenSSH puis tester à nouveau

Rechargez le service correspondant à votre distribution. Utilisez l’un des noms identifiés lors de l’étape 2 :

sudo systemctl reload ssh
sudo systemctl reload sshd

Gardez toujours la première session ouverte. Dans une troisième fenêtre, connectez-vous avec la clé puis tentez volontairement une connexion en interdisant les clés afin de vérifier que le mot de passe n’est plus accepté :

ssh -o PubkeyAuthentication=no admin@adresse_du_serveur

Le résultat attendu est un refus de connexion pour cette seconde commande, tandis que la connexion utilisant id_ed25519 continue de fonctionner.

Erreurs fréquentes lors de la sécurisation d’un serveur SSH

Les incidents les plus courants viennent moins du chiffrement que de la séquence d’exécution. Une configuration correcte sur le papier peut bloquer l’accès si elle est appliquée au mauvais compte, au mauvais service ou sans session de secours.

1. Désactiver PasswordAuthentication trop tôt. Le serveur refuse ensuite le seul moyen de connexion disponible. Testez d’abord une nouvelle session avec la clé.
2. Copier la clé privée au lieu de la clé publique. La clé privée ne doit jamais être installée sur le serveur. Utilisez le fichier se terminant par .pub.
3. Ajouter AllowUsers sans inclure le compte actif. OpenSSH refusera le compte oublié. Vérifiez l’orthographe exacte du nom Linux avant le rechargement.
4. Redémarrer le service sans sshd -t. Une erreur de syntaxe peut interrompre le service. Validez toujours la configuration avant un rechargement.
5. Fermer la session initiale trop vite. La session existante permet de corriger la configuration tant qu’elle reste ouverte.

Renforcer encore la configuration SSH

Une connexion SSH sans mot de passe n’est qu’une couche de protection. Un serveur Linux doit aussi limiter les comptes pouvant se connecter, réduire l’exposition réseau et recevoir les correctifs d’OpenSSH ainsi que ceux du système. Les recommandations exactes dépendent de l’environnement, de la distribution et de la politique d’accès de l’organisation.

La réduction de la surface d’exposition consiste à n’autoriser que les accès réellement nécessaires, depuis les réseaux réellement nécessaires. Un pare-feu peut, par exemple, limiter le port SSH aux adresses IP d’administration connues. Cette mesure doit être testée avec prudence pour ne pas exclure l’administrateur légitime.

Limiter les comptes et les réseaux autorisés

La directive AllowUsers restreint les comptes acceptés par OpenSSH. Une restriction au niveau du pare-feu complète ce filtrage en empêchant les réseaux non autorisés d’atteindre le service. Le changement de port, souvent proposé à partir du port SSH par défaut 22, peut réduire le bruit des scans automatisés mais ne remplace pas une authentification par clé ni un filtrage réseau.

Fermer les sessions inactives

OpenSSH peut fermer les sessions qui ne répondent plus grâce à ClientAliveInterval et ClientAliveCountMax. Un exemple de délai de vérification de 600 secondes doit être adapté aux usages réels : une session d’administration longue ou une opération de maintenance peut nécessiter une politique différente.

ClientAliveInterval 600
ClientAliveCountMax 2

Mettre à jour et surveiller

Les mises à jour d’OpenSSH corrigent des vulnérabilités et des défauts connus. Consultez la documentation officielle de votre distribution et les avis de sécurité associés avant une mise à niveau importante. Une journalisation plus détaillée, par exemple avec LogLevel VERBOSE, peut faciliter l’analyse des connexions, mais elle doit être conciliée avec les règles de conservation des journaux.

Des outils de blocage comme Fail2ban ou CrowdSec peuvent compléter la protection contre les tentatives répétées. Leur configuration doit être testée sur un environnement maîtrisé, car une règle trop agressive peut bloquer une adresse d’administration légitime.

Quelle solution choisir : clé SSH seule, mot de passe ou authentification multifacteur ?

La clé SSH protégée par une phrase secrète convient à la plupart des accès d’administration individuels. Le mot de passe seul ne fournit pas le même niveau de résistance face aux essais automatisés. L’authentification multifacteur ajoute une vérification, mais son déploiement exige une procédure de récupération documentée et des essais avant généralisation.

Méthode	Usage adapté	Limite principale
Mot de passe SSH seul	Accès temporaire dans un environnement très contrôlé	Exposé aux tentatives de devinette et de réutilisation de mots de passe
Clé SSH avec phrase secrète	Administration courante d’un serveur Linux	La clé privée doit être sauvegardée et protégée
Clé SSH et MFA	Accès à enjeu élevé ou équipes avec politique renforcée	Configuration et récupération plus complexes

La rotation des clés constitue aussi une bonne pratique lorsque des personnes quittent une équipe, qu’un poste est perdu ou qu’une clé privée risque d’avoir été copiée. Retirez alors la ligne concernée de authorized_keys, vérifiez les autres comptes autorisés et générez une nouvelle paire. Pour revoir les bases d’une distribution Linux avant une intervention, consultez ce guide pour comprendre Manjaro Linux.

Que faire en cas de perte d’accès SSH ?

Une perte d’accès après modification doit être traitée depuis la console de récupération, pas par des essais répétés depuis Internet. Connectez-vous via la console de l’hébergeur ou l’accès physique, ouvrez le fichier de sauvegarde, puis rétablissez temporairement une configuration connue. Vérifiez ensuite la syntaxe avant de recharger le service.

Pour une récupération temporaire, remettez PasswordAuthentication yes uniquement si vous contrôlez le contexte et si une autre mesure de sécurité ne l’interdit pas. Corrigez la clé, les permissions ou le compte autorisé, retestez dans une nouvelle session, puis désactivez de nouveau les mots de passe. Un incident répété justifie une vérification par un administrateur système qualifié.

Sources utiles à consulter

La documentation officielle d’OpenSSH décrit les options de sshd_config, notamment PermitRootLogin, PasswordAuthentication, PubkeyAuthentication et AllowUsers. Les pages de manuel sshd_config(5), sshd(8) et ssh-keygen(1) permettent de vérifier le comportement de la version installée.

Les notes de sécurité et la documentation officielle de votre distribution Linux indiquent les correctifs OpenSSH disponibles, le nom exact du service et les éventuels fichiers de configuration inclus. Pour les environnements professionnels ou sensibles, les recommandations de l’ANSSI peuvent aussi servir de repère de durcissement général.

Questions fréquentes

Peut-on désactiver les mots de passe avant de tester la clé SSH ?

Non. Une clé SSH doit être testée dans une nouvelle session avant toute modification de PasswordAuthentication. Gardez la session initiale ouverte afin de pouvoir corriger la configuration si la seconde connexion échoue.

Quelle différence entre une clé publique et une clé privée SSH ?

La clé publique est installée sur le serveur dans authorized_keys. La clé privée reste sur le poste client et ne doit jamais être transmise. Les deux clés forment une paire cryptographique associée.

Pourquoi ma clé SSH est-elle refusée ?

Les causes courantes sont un mauvais compte Linux, une clé publique absente, des permissions incorrectes ou une directive OpenSSH restrictive. Utilisez ssh -v côté client et consultez les journaux du service SSH côté serveur pour identifier l’étape qui échoue.

Comment réactiver temporairement le mot de passe SSH ?

Utilisez une console de récupération, modifiez la directive PasswordAuthentication avec prudence, puis validez le fichier avec sshd -t. Rechargez le service et corrigez la configuration par clé avant de désactiver à nouveau les mots de passe.