Niveau 🟡 intermédiaire
Durée estimée : 25 min · Prérequis : Utilisateurs et permissions
Un mot de passe, c'est un code à composer sur un digicode — n'importe qui l'ayant vu ou deviné
peut l'utiliser. Une clé SSH, c'est une serrure à double came : tu gardes toujours la moitié
privée de la clé chez toi (elle ne quitte jamais ta machine), et tu ne donnes au serveur que
l'empreinte publique correspondante, gravée dans sa serrure. Le serveur peut vérifier que
tu possèdes la bonne clé sans jamais avoir vu la clé elle-même.
SSH (Secure Shell) est le protocole standard pour administrer une machine Linux à
distance, en ligne de commande, de façon chiffrée — tout ce qui transite (commandes, mots de
passe, fichiers) est illisible pour quiconque intercepterait la connexion.
Pourquoi une clé plutôt qu'un mot de passe. Une authentification par mot de passe est
vulnérable à trois attaques courantes qu'une clé rend inefficaces :
La paire de clés repose sur la cryptographie asymétrique : une clé privée (jamais
partagée, protégée par une passphrase optionnelle) et une clé publique (partageable sans
risque, c'est elle qu'on dépose sur le serveur). Le serveur, en connaissant la clé publique, peut
vérifier une preuve produite avec la clé privée correspondante — sans jamais avoir besoin de
connaître ou stocker la clé privée elle-même.
Le fichier ~/.ssh/authorized_keys, côté serveur, liste les clés publiques autorisées à se
connecter au compte concerné. C'est lui que la commande ssh-copy-id (ou une copie manuelle)
vient compléter lors de l'installation d'une nouvelle clé.
Durcir la configuration, une fois la clé en place et testée, consiste typiquement à :
PasswordAuthentication no) — une foisroot (PermitRootLogin no) — on se connecte avec unsudo au besoin (voir page précédente), jamais directement en root.Ces réglages vivent dans /etc/ssh/sshd_config, ou dans des fichiers dédiés sous
/etc/ssh/sshd_config.d/ — une pratique plus propre que de tout entasser dans le fichier
principal, en particulier quand un outil d'installation y a déjà déposé ses propres réglages.
En cas de fichiers multiples, le premier qui définit un paramètre l'emporte — un point de
vigilance si un fichier automatique (comme celui posé par un assistant d'installation) et un
fichier écrit à la main coexistent.
⚠️ Toujours tester avant de recharger, et recharger plutôt que redémarrer.
sudo sshd -tvérifie la syntaxe d'une configuration SSH sans l'appliquer — une faute de
frappe danssshd_configpeut sinon empêcher tout accès futur. Une fois validée,
sudo systemctl reload sshapplique le changement sans couper les connexions déjà
ouvertes — contrairement àrestart, qui fermerait la session en cours au pire moment
possible : pendant qu'on durcit justement l'accès SSH.
🧪 Concrètement, sur notre exemple : l'installeur d'Ubuntu Server a lui-même désactivé
l'authentification par mot de passe dès l'import de la clé publique au moment de
l'installation. La désactivation de la connexion root a été ajoutée ensuite, dans un fichier
séparé soussshd_config.d/. Chaque changement a été vérifié avecsudo sshd -T(qui
affiche la configuration effective, résultat combiné de tous les fichiers — la seule
source fiable, plutôt que de relire chaque fichier et déduire soi-même lequel gagne).
Le principe central : la clé privée ne transite jamais sur le réseau, à aucun moment — ni à
l'installation, ni à la connexion. Seule une preuve mathématique de sa possession circule.
ssh-keygen -t ed25519 -C "commentaire-identifiant"
# Génère une paire de clés. ed25519 : algorithme moderne, rapide et sûr,
# à préférer à l'ancien RSA pour une nouvelle clé.
# -C ajoute un commentaire (souvent un email ou un nom d'usage) pour
# identifier la clé plus tard parmi d'autres.
ssh-copy-id utilisateur@serveur
# Copie la clé PUBLIQUE (~/.ssh/id_ed25519.pub) vers le serveur,
# dans ~/.ssh/authorized_keys du compte visé.
ssh utilisateur@serveur
# Se connecte -- doit maintenant fonctionner sans mot de passe.
Une fois la connexion par clé confirmée, côté serveur :
sudo sshd -t
# Teste la syntaxe de la configuration SANS l'appliquer
sudo systemctl reload ssh
# Applique la configuration testée, sans couper les sessions en cours
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'
# Affiche la configuration EFFECTIVE (résultat combiné de tous les
# fichiers de config) -- la seule vérification fiable
Ouvre une nouvelle fenêtre de terminal (sans fermer la session actuelle) et tente une
connexion :
ssh utilisateur@serveur
Doit se connecter sans demander de mot de passe. Ne ferme jamais la session en cours avant
d'avoir confirmé qu'une nouvelle connexion fonctionne — c'est le filet de sécurité qui évite
de se retrouver bloqué dehors après un durcissement raté.
| Symptôme | Cause probable | Solution |
|---|---|---|
| Bloqué dehors après avoir désactivé le mot de passe | La clé n'a pas été testée avant la désactivation | Toujours vérifier une connexion par clé réussie, dans une session séparée, avant de couper le mot de passe |
sshd_config modifié mais rien ne change |
Un autre fichier sous sshd_config.d/ définit la même option et est lu avant |
Utiliser sudo sshd -T (config effective) plutôt que relire les fichiers un par un |
systemctl restart ssh coupe la session en cours pendant la manipulation |
restart interrompt les connexions existantes |
Préférer systemctl reload ssh, qui applique la config sans couper les sessions actives |
sshd -t teste, sshd -T affiche la config effective, reload applique sans couper lesPermitRootLogin no) complète la clé : administrationsudo, jamais en root direct.Parce que c'est elle qui prouve l'identité — si elle circulait sur le réseau ou était copiée
sur le serveur, elle perdrait sa valeur de preuve exclusive et pourrait être volée.
Elle vérifie la syntaxe de la configuration SSH sans l'appliquer. Une faute de frappe non
détectée avant application pourrait couper tout accès SSH à la machine, y compris pour la
corriger.
reload applique la nouvelle configuration sans fermer les connexions déjà ouvertes ; restart
les couperait, potentiellement en pleine manipulation de durcissement de l'accès lui-même.
Si tu as accès à une VM Linux : génère une paire de clés avec ssh-keygen -t ed25519, installe
la clé publique avec ssh-copy-id, confirme la connexion par clé dans une nouvelle session,
puis seulement à ce moment-là désactive PasswordAuthentication et vérifie avec sshd -T.
SSH ·
clé privée ·
clé publique ·
authorized_keys
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.