On a tous déjà vu le scénario.
Tu veux « juste » sécuriser SSH vite fait. Tu touches deux ou trois réglages. Tu redémarres. Et là… plus rien. Session coupée, accès perdu, petit moment de solitude. Surtout quand la machine est à distance, sur un VPS, ou pire dans une salle serveur où tu n’as pas la main.
Ici, on va faire simple et pragmatique : durcir SSH en environ 10 minutes, en gardant une porte de sortie pour ne pas se verrouiller. Ce n’est pas un guide « compliance ISO 27001 » complet, c’est le pack de base propre, celui qui tient la route dans la vraie vie.
Et si tu aimes ce genre de lab, pense à passer sur le blog BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/) : on y regroupe des tutos et TP orientés systèmes et réseaux, comme on les fait en atelier.
Avant de commencer : le plan anti verrouillage
Avant toute modification, on met en place trois sécurités. C’est rapide, et ça évite les regrets.
- Garder une session SSH ouverte (celle qui marche).
- Ouvrir une deuxième session SSH pour tester les changements.
- Si possible : avoir un accès console (Proxmox, iLO, console VPS, écran local).
Et surtout, on ne redémarre pas SSH « au hasard ». On teste la syntaxe, on recharge proprement.
Étape 1 : faire une sauvegarde et vérifier la conf
On sauvegarde le fichier, puis on check la syntaxe ensuite.
bash sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
Ensuite, on regarde vite fait ce qui est actif, sans se perdre dans le fichier.
bash sudo sshd -T | head
sshd -T affiche la configuration effective. Très utile quand tu as des Include ou des valeurs par défaut qui te surprennent.
Étape 2 : mettre à jour OpenSSH (rapide, mais important)
Sur Debian/Ubuntu :
bash sudo apt update sudo apt -y upgrade openssh-server
Sur Rocky/Alma/CentOS :
bash sudo dnf -y update openssh-server
Tu ne durcis pas un service si tu laisses une version vieillissante. Ça paraît évident, mais ça saute vite.
Étape 3 : créer un utilisateur admin, et préparer la clé SSH
Objectif : ne plus utiliser root en direct, et passer en clés.
Créer un utilisateur
bash sudo adduser admin sudo usermod -aG sudo admin
Sur Red Hat like :
bash sudo usermod -aG wheel admin
Générer une clé (côté client)
Sur ta machine à toi :
bash ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519_admin
Ensuite, on copie la clé sur le serveur.
bash ssh-copy-id -i ~/.ssh/id_ed25519_admin.pub admin@IP_DU_SERVEUR
Test immédiat :
bash ssh -i ~/.ssh/id_ed25519_admin admin@IP_DU_SERVEUR
Si ça marche, tu as déjà fait 60 % du boulot.
Étape 4 : durcir sshd_config sans se piéger
On édite proprement.
bash sudo nano /etc/ssh/sshd_config
Je te donne un bloc de réglages « base solide ». Tu peux l’adapter, mais évite de tout changer d’un coup si tu es sur un serveur distant.
Bloc recommandé (à adapter)
conf
Protocol 2
PermitRootLogin no PasswordAuthentication no KbdInteractiveAuthentication no ChallengeResponseAuthentication no UsePAM yes
PubkeyAuthentication yes
X11Forwarding no PermitEmptyPasswords no
MaxAuthTries 3 LoginGraceTime 30 ClientAliveInterval 300 ClientAliveCountMax 2
AllowUsers admin
Quelques notes, vite fait, parce que sinon on fait n’importe quoi :
PermitRootLogin no: root ne se connecte plus en SSH. Tu passes paradminpuissudo.PasswordAuthentication no: plus de mot de passe en SSH. Donc attention, tu dois avoir ta clé OK avant.AllowUsers admin: option super efficace pour réduire la surface. Mais si tu te trompes de nom, tu te bloques. Donc vérifie deux fois.ClientAliveIntervaletClientAliveCountMax: évite des sessions zombies et certaines déconnexions bizarres.
Option bonus : changer le port, mais sans fantasmer
Changer le port ne remplace pas un durcissement. Ça baisse juste le bruit des scans basiques.
Si tu veux le faire :
- tu choisis un port libre, par exemple
2222 - tu modifies :
conf Port 2222
Mais… si tu fais ça, pense firewall, SELinux, et tes scripts d’automatisation. Et surtout : on teste avant de fermer la session existante.
Étape 5 : tester la conf avant de recharger
Test syntaxe :
bash sudo sshd -t
Si aucune sortie, c’est bon signe. S’il y a une erreur, corrige avant de toucher au service.
Recharge :
bash sudo systemctl reload ssh
Sur certaines distros, le service s’appelle sshd :
bash sudo systemctl reload sshd
Étape 6 : test réel dans une deuxième session
Très important. Tu testes comme un humain, pas comme un fichier.
Si tu as gardé le port 22 :
bash ssh -i ~/.ssh/id_ed25519_admin admin@IP_DU_SERVEUR
Si tu as changé le port :
bash ssh -p 2222 -i ~/.ssh/id_ed25519_admin admin@IP_DU_SERVEUR
Tu dois te connecter sans demander de mot de passe. Ensuite :
bash sudo -l
Tu vérifies que admin a bien les droits sudo.
Si tout est OK, seulement là tu peux fermer l’ancienne session.
Étape 7 : activer un firewall minimaliste (UFW ou firewalld)
Debian/Ubuntu avec UFW
bash sudo apt -y install ufw sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 2222/tcp # ou 22/tcp si tu n'as pas changé le port sudo ufw enable sudo ufw status verbose
Rocky/Alma/CentOS avec firewalld
bash sudo systemctl enable --now firewalld sudo firewall-cmd --permanent --add-port=2222/tcp sudo firewall-cmd --reload sudo firewall-cmd --list-all
Si tu es resté sur 22, remplace 2222 par 22.
Étape 8 : Fail2ban pour calmer les bruteforces
Ce n’est pas magique, mais c’est efficace et léger.
Installation
Debian/Ubuntu :
bash sudo apt -y install fail2ban
Red Hat like :
bash sudo dnf -y install fail2ban
Config rapide
On crée un jail.local minimal.
bash sudo nano /etc/fail2ban/jail.local
Contenu :
ini [sshd] enabled = true port = 2222 maxretry = 3 findtime = 10m bantime = 1h
Si tu es sur le port 22, adapte port = 22.
Puis :
bash sudo systemctl enable --now fail2ban sudo fail2ban-client status sshd
Étape 9 : option propre, plus avancée, autoriser SSH seulement depuis ton réseau
Là, on passe dans le « vraiment pratique » pour un serveur d’admin interne : tu limites par IP source.
Exemple UFW, autoriser uniquement depuis ton IP publique :
bash sudo ufw allow from TON_IP_PUBLIQUE to any port 2222 proto tcp sudo ufw deny 2222/tcp
Exemple firewalld :
bash sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="TON_IP_PUBLIQUE/32" port protocol="tcp" port="2222" accept' sudo firewall-cmd --permanent --add-port=2222/tcp --remove-port=2222/tcp sudo firewall-cmd --reload
Ça demande un peu de rigueur, parce que ton IP peut changer si tu es en DHCP. Mais pour de l’admin, c’est souvent le meilleur rapport effort sécurité.
Étape 10 : petit check final, et retour arrière si besoin
Vérifier que SSH écoute bien où il faut
bash sudo ss -ltnp | grep sshd
Lire les logs en cas de souci
Debian/Ubuntu souvent :
bash sudo journalctl -u ssh -n 50 --no-pager
Sinon :
bash sudo journalctl -u sshd -n 50 --no-pager
Plan de rollback rapide
Si tu t’aperçois que tu as fait une bêtise, tant que tu as une session ouverte :
bash sudo cp -a /etc/ssh/sshd_config.bak.YYYY-MM-DD /etc/ssh/sshd_config sudo sshd -t && sudo systemctl reload ssh
Adapte la date, évidemment.
Une config exemple, un peu plus « propre » (optionnelle)
Si tu veux aller un cran plus loin, tu peux aussi ajouter :
conf PermitUserEnvironment no AllowAgentForwarding no AllowTcpForwarding no
Attention : AllowTcpForwarding no peut casser des usages légitimes (tunnels SSH, certaines méthodes d’admin). Donc à activer seulement si tu sais que tu n’en as pas besoin.
Ce que tu viens de gagner, concrètement
En 10 minutes, tu as :
- supprimé l’accès SSH root
- supprimé l’auth par mot de passe
- forcé l’usage des clés
- réduit la liste des utilisateurs autorisés
- ajouté un firewall
- ajouté fail2ban
- gardé une méthode de test et un rollback, donc tu ne t’es pas enfermé dehors
C’est exactement le genre de durcissement « quotidien » qu’on aime bien transformer en TP reproductible. Si tu veux d’autres labs dans le même esprit (hardening Linux, supervision, services réseau, scripts d’automatisation), passe sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), il y a de quoi faire.
Récap rapide des commandes
bash sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F) sudo sshd -t sudo systemctl reload ssh || sudo systemctl reload sshd
ssh-keygen -t ed25519 -a 64 ssh-copy-id admin@IP
sudo ufw allow 2222/tcp || sudo firewall-cmd --permanent --add-port=2222/tcp sudo systemctl enable --now fail2ban sudo fail2ban-client status sshd
Si tu veux, je peux te proposer une variante « serveur en prod » un peu plus stricte, ou une variante « salle info BTS SIO » avec comptes nominaux, bannière légale, journalisation renforcée, et un mini audit final.
Questions fréquemment posées
Pourquoi est-il important de garder une session SSH ouverte avant de modifier la configuration ?
Garder une session SSH ouverte permet d'éviter de se verrouiller hors du serveur en cas d'erreur dans la configuration. Cela sert de porte de sortie pour corriger rapidement les erreurs sans perdre l'accès.
Comment puis-je vérifier la syntaxe de ma configuration SSH avant de redémarrer le service ?
Vous pouvez utiliser la commande sshd -T pour afficher la configuration effective et vérifier la syntaxe. Cela permet de s'assurer que le fichier sshd_config ne contient pas d'erreurs avant de recharger ou redémarrer SSH.
Pourquoi faut-il créer un utilisateur admin et utiliser des clés SSH au lieu de se connecter directement en root ?
Se connecter directement en root est risqué car cela donne un accès complet immédiat. Créer un utilisateur admin avec privilèges sudo et utiliser des clés SSH améliore la sécurité en limitant les connexions directes root et en évitant l'usage des mots de passe, réduisant ainsi les risques d'intrusion.
Quels sont les réglages essentiels pour durcir le fichier sshd_config sans se bloquer ?
Les réglages recommandés incluent : Protocol 2, PermitRootLogin no, PasswordAuthentication no, PubkeyAuthentication yes, AllowUsers admin, MaxAuthTries 3, entre autres. Ces options renforcent la sécurité tout en gardant une configuration stable et fonctionnelle.
Est-il utile de changer le port SSH pour améliorer la sécurité ?
Changer le port SSH peut réduire le bruit des scans automatisés sur le port standard 22, mais ce n'est pas une mesure suffisante à elle seule. Il faut combiner ce changement avec un durcissement complet de la configuration pour une meilleure sécurité.
Comment mettre à jour OpenSSH sur différentes distributions Linux ?
Sur Debian/Ubuntu, utilisez : sudo apt update puis sudo apt -y upgrade openssh-server. Sur Rocky/Alma/CentOS, utilisez : sudo dnf -y update openssh-server. Garder OpenSSH à jour est crucial pour bénéficier des dernières corrections de sécurité.
0 Commentaires