Niveau 🟡 intermédiaire
Durée estimée : 15 min · Prérequis : Modèle de menace
Cette page ne réintroduit pas la technique SSH — déjà vue en détail en
M1 — elle répond à une question différente : pourquoi,
précisément, ces réglages comptent-ils du point de vue de la sécurité ? Verrouiller sa porte
d'entrée est un geste technique ; comprendre contre quel genre de cambriolage ce verrou protège
en est un autre — c'est ce deuxième regard que cette page ajoute.
Rappel technique (détaillé en M1) : l'authentification
par clé remplace le mot de passe pour se connecter en SSH, et PermitRootLogin no interdit toute
connexion directe avec le compte root.
Ce que ces deux réglages éliminent, précisément, du modèle de menace vu en
page précédente :
PermitRootLogin no élimine un scénario précis : même si un attaquant devinait ou volaitsudo (vu en M1), une étapePourquoi les deux ensemble, et pas l'un sans l'autre. Une clé seule protège l'accès initial,
mais si elle protégeait un compte root, sa compromission donnerait un accès total immédiat. Un
PermitRootLogin no seul, sans clé, laisserait encore la porte ouverte à la force brute sur un
compte normal. Combinés, ils imposent qu'un attaquant franchisse deux obstacles distincts —
obtenir la clé d'un compte normal, puis élever ses privilèges via sudo — plutôt qu'un seul.
🧪 Concrètement, sur notre exemple : ces deux réglages sont en place depuis le premier
incrément de sécurité du projet (I3, sprint 06) — la méthode complète, les commandes de
vérification (sshd -T), et le piège des fichiers de configuration multiples sont détaillés
dans SSH et clés. Rien de technique à rajouter ici : cette
page relie ce qui a déjà été fait au modèle de menace de ce module.
Les deux réglages bloquent des chemins d'attaque différents — retirer l'un des deux laisse
l'autre chemin ouvert.
Les commandes de mise en œuvre et de vérification (sshd -t, sshd -T, systemctl reload ssh)
sont détaillées en SSH et clés — pas
réintroduites ici pour éviter la redite. Un seul ajout, du point de vue sécurité :
sudo journalctl -u ssh | grep "Failed password"
# Si des tentatives de mot de passe échouées apparaissent malgré
# PasswordAuthentication no, c'est le signe que la configuration
# effective (sshd -T) ne correspond pas à ce qui est attendu
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'
Doit afficher passwordauthentication no et permitrootlogin no — la vérification technique
complète est en M1.
| Symptôme | Cause probable | Solution |
|---|---|---|
Penser que la clé SSH seule suffit, sans traiter PermitRootLogin |
Vision incomplète du modèle de menace | Les deux réglages bloquent des scénarios distincts (voir schéma) — l'un ne remplace pas l'autre |
| Désactiver le mot de passe avant d'avoir confirmé que la clé fonctionne | Précipitation dans l'ordre des étapes | Toujours tester la connexion par clé dans une session séparée avant de couper le mot de passe (détaillé en M1) |
| Considérer ce durcissement comme suffisant à lui seul pour la sécurité du serveur | Confusion entre une mesure et une stratégie de sécurité complète | Ce n'est qu'une des pièces du modèle de menace de ce module — voir aussi le moindre privilège et la gestion des secrets |
PermitRootLogin no empêche qu'une clé ou un mot de passe root compromis donne un accès totalLa force brute (tester des mots de passe en boucle) et la réutilisation d'un mot de passe
compromis ailleurs — deux scénarios impossibles sans le mot de passe correspondant à une clé.
Parce qu'il empêche qu'une clé (ou un mot de passe) root compromis donne un accès total
immédiat — l'attaquant devrait d'abord obtenir un accès via un compte normal, puis passer par
sudo, une étape supplémentaire.
Parce qu'ils bloquent des chemins d'attaque différents — retirer l'un des deux laisse l'autre
chemin d'attaque entièrement ouvert.
Relis la section « Vérifier que ça marche » de SSH et clés,
exécute la vérification sur une machine à disposition, et explique, pour chacun des deux
réglages, quel scénario d'attaque précis il élimine — sans relire cette page.
Aucun terme technique nouveau — voir SSH,
clé privée et
root, déjà posés en M1.
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.