Skip to Content
Serveur LinuxPartie 4 — SSH : accès & durcissement4.4 — Durcir le serveur SSH

Chapitre 4.4 — Durcir le serveur SSH

⏱️ TL;DR — SSH est ta porte d’entrée ; ce chapitre en fait un coffre-fort. On édite la config du serveur — /etc/ssh/sshd_config ou, plus propre, un fichier dans /etc/ssh/sshd_config.d/ — pour : interdire root (PermitRootLogin no), couper le mot de passe une fois les clés en place (PasswordAuthentication no), n’accepter que les clés (PubkeyAuthentication yes), restreindre à un seul utilisateur (AllowUsers deploy), éventuellement déplacer le port, et limiter les essais (MaxAuthTries). Le danger mortel : te verrouiller dehors en coupant le mot de passe avant d’avoir une clé qui marche. La règle d’or : teste dans un NOUVEAU terminal, en gardant l’ancien ouvert, avant de fermer quoi que ce soit. Combiné à fail2ban (Partie 5), tu obtiens un SSH que les robots ne franchissent plus.

🎯 Objectifs

  • Localiser et éditer la config du serveur SSH (/etc/ssh/sshd_config et sshd_config.d/).
  • Appliquer les réglages de durcissement clés : root off, mot de passe off, clés only, AllowUsers, MaxAuthTries.
  • Comprendre le compromis d’un port SSH non standard (et pourquoi ce n’est pas une vraie sécurité).
  • Recharger sshd et tester sans risque, avec la méthode « nouveau terminal » qui évite le verrouillage.
  • Savoir que ce durcissement se complète avec un pare-feu et fail2ban (Partie 5).

Où se règle le serveur SSH

Côté serveur, tout se passe dans un fichier de config, lu par le daemon sshd :

/etc/ssh/sshd_config          # la config principale du serveur SSH
/etc/ssh/sshd_config.d/        # un dossier de fragments, charges en complement

Sur Ubuntu récent, sshd_config contient souvent une ligne du type Include /etc/ssh/sshd_config.d/*.conf : tout fichier .conf déposé dans ce dossier est lu en plus (et peut surcharger) la config principale.

💡 Réflexe — Plutôt que d’éditer le gros sshd_config (souvent versionné par le paquet et écrasé aux mises à jour), crée ton propre fragment : /etc/ssh/sshd_config.d/99-durcissement.conf. Tes réglages sont regroupés, survivent aux updates du paquet, et se retirent en supprimant un seul fichier. Le préfixe 99- le fait charger en dernier, donc il gagne.

🐚 Au terminal — Édition du fragment de durcissement (nécessite sudo, car /etc/ssh appartient à root) :

sudo nano /etc/ssh/sshd_config.d/99-durcissement.conf
# on y met UNIQUEMENT nos directives de durcissement (voir plus bas)

Les réglages de durcissement

Voici le fragment de référence, directive par directive :

# /etc/ssh/sshd_config.d/99-durcissement.conf

PermitRootLogin no          # INTERDIT toute connexion SSH directe en root
PubkeyAuthentication yes    # AUTORISE l'authentification par cle
PasswordAuthentication no   # REFUSE le mot de passe (cle obligatoire)
AllowUsers deploy           # SEUL l'utilisateur deploy peut se connecter en SSH
MaxAuthTries 3              # au plus 3 tentatives d'auth par connexion

PermitRootLogin no — root n’entre plus

On ne se connecte jamais en root en SSH. Root est le compte le plus puissant (il peut tout casser) et son nom est connu de tous : c’est la cible n°1 des robots. En l’interdisant, tu supprimes d’emblée toutes les tentatives ciblant root. Tu passeras par deploy puis sudo pour les tâches admin.

PasswordAuthentication no — le mot de passe, terminé

C’est le réglage qui élimine l’essentiel des attaques : sans mot de passe accepté, un robot qui en essaie des millions frappe dans le vide. Seules les clés entrent. Mais c’est aussi le réglage le plus dangereux à activer : si tu le coupes avant d’avoir une clé qui fonctionne, tu te retrouves dehors, sans moyen de rentrer (voir le piège plus bas).

PubkeyAuthentication yes — les clés, oui

Explicite l’acceptation des clés (souvent déjà par défaut, mais on l’écrit pour être clair). C’est la seule méthode qui restera après avoir coupé le mot de passe.

AllowUsers deploy — une liste blanche d’utilisateurs

Restreint la connexion SSH aux utilisateurs listés. Même si un autre compte existe sur la machine (un service, un ancien compte), il ne peut pas se connecter par SSH. Tu peux en lister plusieurs, séparés par des espaces : AllowUsers deploy alex.

MaxAuthTries 3 — coupe court aux essais

Limite le nombre de tentatives d’authentification par connexion. Après 3 échecs, sshd raccroche. Ça réduit le coût des attaques et, côté client, ça t’incite à présenter la bonne clé du premier coup (revoir IdentitiesOnly au 4.3).

🔒 Sécurité — Ces réglages forment un empilement : root fermé (plus de cible évidente), mot de passe coupé (plus de bruteforce possible), liste blanche d’utilisateurs (surface réduite), essais limités (attaques plus coûteuses). Aucun n’est magique seul ; ensemble, ils font passer ton SSH de « constamment attaqué » à « pratiquement inviolable à distance ». C’est le socle sur lequel la Partie 5 ajoutera pare-feu et fail2ban.

Le port non standard : nuance importante

On lit souvent « déplace SSH du port 22 vers un autre port ». Exemple :

Port 2222   # ecoute sur 2222 au lieu du port 22 standard

Ce que ça fait : les robots qui scannent en masse le port 22 ne trouvent plus rien à frapper. Tes logs SSH deviennent beaucoup plus calmes, ce qui est agréable et rend les vraies alertes plus visibles.

Ce que ça ne fait pas : te protéger réellement. Un attaquant ciblé scanne tous les ports en quelques secondes et trouve ton SSH, port 2222 ou pas. C’est de la sécurité par l’obscurité (security by obscurity) : ça réduit le bruit, ça n’ajoute aucune barrière solide.

⚠️ Piège — Croire qu’un port SSH non standard te « sécurise ». Il cache l’entrée, il ne la verrouille pas. La vraie sécurité vient des clés (mot de passe coupé) et du pare-feu — pas du numéro de port. Déplacer le port est un confort (moins de bruit dans les logs), pas une protection. Ne relâche jamais les vrais réglages sous prétexte que « de toute façon je ne suis pas sur le 22 ».

La règle d’or : ne te verrouille pas dehors

Voici l’accident classique et irréversible (si tu n’as pas d’autre accès) :

  1. Tu édites sshd_config, tu mets PasswordAuthentication no.
  2. Tu recharges sshd.
  3. Tu fermes ton terminal.
  4. Tu essaies de te reconnecter… et ta clé ne marchait pas (permissions, mauvaise clé, clé pas encore déposée).
  5. Le mot de passe est refusé (tu viens de le couper), la clé aussi : tu es dehors, définitivement, sans moyen de rentrer par SSH.

La parade tient en une discipline simple :

⚠️ Piège — NE FERME JAMAIS ta session SSH en cours après avoir modifié sshd_config. La séquence sûre : (1) garde ton terminal actuel ouvert (il reste connecté même après le reload). (2) Ouvre un NOUVEAU terminal et tente une nouvelle connexion. (3) Si elle réussit par clé, tout va bien — tu peux fermer l’ancien. (4) Si elle échoue, tu as toujours ta session d’origine ouverte pour corriger (rétablir le mot de passe, réparer la clé). Ta session ouverte est ton filet de sécurité. Ne coupe jamais le filet avant d’être sûr d’avoir touché le sol.

💡 Réflexe — Avant de couper PasswordAuthentication no, prouve d’abord que ta clé fonctionne en te connectant par clé avec le mot de passe encore actif. Une fois que ssh deploy@… t’ouvre une session sans te demander de mot de passe, alors seulement tu coupes le mot de passe — tu sais que la clé prend le relais.

Appliquer les changements

Modifier le fichier ne suffit pas : sshd doit relire sa config. Deux bonnes pratiques d’abord, vérifier puis recharger.

sudo sshd -t
# -t -> teste la syntaxe de la config SANS l'appliquer
# aucune sortie = tout est bon ; une erreur = corrige AVANT de recharger

Puis on applique. Selon les distributions, le service s’appelle ssh ou sshd :

sudo systemctl restart ssh    # sur Ubuntu/Debian, le service se nomme souvent "ssh"
# sur d'autres systemes : sudo systemctl restart sshd

Un point rassurant : relancer sshd ne coupe PAS ta session en cours. Les connexions déjà établies survivent au restart ; seules les nouvelles connexions utilisent la config fraîche. C’est exactement ce qui rend la méthode « nouveau terminal » sûre.

🐚 Au terminal — La séquence complète et sûre, de bout en bout :

sudo sshd -t                          # 1. valider la syntaxe
sudo systemctl restart ssh            # 2. appliquer (ta session actuelle survit)
# 3. SANS fermer ce terminal, en ouvrir un NOUVEAU et tester :
#    ssh deploy@203.0.113.10
# 4. si le nouveau terminal entre par cle -> OK, on peut fermer l'ancien

📚 La doc — La liste exhaustive des directives de sshd_config, avec leurs valeurs et défauts pour ta version d’OpenSSH, est dans man sshd_config. N’invente jamais une directive : si tu hésites sur un nom ou une valeur (algorithmes, AllowGroups, Match…), c’est là qu’il faut la vérifier.

Ça se complète : pare-feu et fail2ban

Le durcissement de sshd ferme les portes côté SSH. Deux compléments, traités en Partie 5, referment le reste :

  • Un pare-feu (UFW) qui n’ouvre que les ports nécessaires (SSH + 80/443) et bloque tout le reste — pour que même un service mal configuré ne soit pas joignable de l’extérieur.
  • fail2ban, qui surveille les logs SSH et bannit temporairement (au pare-feu) les IP qui accumulent des échecs. Même avec le mot de passe coupé, ça assèche le bruit des robots et bloque les scanners insistants.

🧭 Sur FormaCampus — Après avoir déposé les clés de l’équipe sur deploy (chapitre 4.2), FormaCampus verrouille le serveur : PermitRootLogin no, PasswordAuthentication no, AllowUsers deploy, port SSH déplacé pour calmer les logs. La manip se fait prudemment — un terminal deploy reste ouvert pendant qu’on teste la reconnexion par clé dans un second terminal. Une fois validé, le mot de passe root de l’email d’origine devient inutilisable : plus personne n’entre en root ni par mot de passe. En Partie 5, UFW ne laissera passer que SSH + HTTPS, et fail2ban bannira les IP trop insistantes. La porte d’entrée est bouclée.

✏️ Exercices

Exercice 1 — Durcis ce serveur. Un VPS neuf accepte encore : connexion root, mot de passe, tous les utilisateurs. Écris le fragment sshd_config.d/99-durcissement.conf qui : interdit root, coupe le mot de passe, force les clés, n’autorise que deploy, et limite à 3 essais.

✅ Solution

# /etc/ssh/sshd_config.d/99-durcissement.conf
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
AllowUsers deploy
MaxAuthTries 3

Et avant d’appliquer : s’assurer que la clé de deploy fonctionne (connexion par clé réussie pendant que le mot de passe est encore actif). Puis sudo sshd -t, sudo systemctl restart ssh, et test dans un nouveau terminal en gardant l’ancien ouvert.

Exercice 2 — Le piège du verrouillage. Ton collègue édite sshd_config, met PasswordAuthentication no, recharge sshd, ferme son terminal… et ne peut plus se reconnecter : « Permission denied ». Qu’a-t-il oublié, et comment s’y prendre correctement ?

✅ Solution

Il a coupé le mot de passe sans vérifier que sa clé fonctionnait, puis fermé sa seule session — supprimant son filet de sécurité. Sa clé n’était probablement pas correctement déposée (ou permissions ~/.ssh mauvaises), donc ni clé ni mot de passe n’entrent : il est verrouillé dehors. La bonne méthode : (1) prouver que la clé marche avant de couper le mot de passe ; (2) garder la session en cours ouverte ; (3) tester dans un nouveau terminal ; (4) ne fermer l’ancien qu’une fois la reconnexion par clé confirmée. (Récupération : passer par la console de secours de l’hébergeur pour rétablir l’accès.)

Exercice 3 — Vrai ou faux : le port. « J’ai mis SSH sur le port 51234, donc mon serveur est sécurisé, je peux garder le mot de passe. » Commente.

✅ Solution

Faux. Déplacer le port est de la sécurité par l’obscurité : ça réduit le bruit des scanners de masse (logs plus calmes), mais un attaquant ciblé trouve le port en scannant. Ça n’ajoute aucune barrière réelle. Garder le mot de passe actif laisse la porte bruteforçable : le vrai durcissement, c’est couper le mot de passe (clés obligatoires) et fermer root, plus un pare-feu. Le port non standard est un confort, jamais un substitut.

🧠 Quiz de révision

1. Où mettre ses réglages de durcissement, et pourquoi pas directement dans sshd_config ?

Dans un fragment sous /etc/ssh/sshd_config.d/ (ex. 99-durcissement.conf), chargé via l’Include. Avantages : réglages regroupés, qui survivent aux mises à jour du paquet (lequel peut écraser le sshd_config principal), et faciles à retirer (un seul fichier). Le préfixe 99- le fait charger en dernier, donc il l’emporte.

2. Que font PermitRootLogin no et PasswordAuthentication no ?

PermitRootLogin no interdit toute connexion SSH directe en root (supprime la cible n°1 des robots). PasswordAuthentication no refuse l’authentification par mot de passe, ne laissant entrer que les clés — ce qui rend le bruteforce inutile.

3. Pourquoi la méthode « nouveau terminal » est-elle indispensable ?

Parce que relancer sshd ne coupe pas ta session en cours : elle reste ton filet de sécurité. En testant la reconnexion dans un nouveau terminal sans fermer l’ancien, tu vérifies que la nouvelle config marche ; si elle échoue, tu as toujours ta session ouverte pour corriger, au lieu d’être verrouillé dehors.

4. Un port SSH non standard est-il une vraie mesure de sécurité ?

Non. C’est de la sécurité par l’obscurité : ça réduit le bruit des scanners de masse (logs plus propres), mais un attaquant ciblé retrouve le port en scannant. La sécurité réelle vient des clés (mot de passe coupé), de la liste blanche d’utilisateurs et du pare-feu.

5. Comment appliquer un changement de config sshd proprement ?

D’abord valider la syntaxe avec sudo sshd -t (aucune sortie = OK). Puis recharger le service : sudo systemctl restart ssh (ou sshd selon la distribution). Les connexions en cours survivent ; seules les nouvelles utilisent la config fraîche — d’où la sûreté du test en nouveau terminal.

Chapitre suivant : Transferts & tunnels — copier des fichiers avec scp et rsync, et ouvrir des tunnels pour atteindre un service distant sans jamais l’exposer.

Last updated on
4.3 — Config client & alias4.5 — Transferts & tunnels