SSH, c’est un peu le paillasson de ta infra. Tout le monde le voit, tout le monde tente d’entrer. Et le pire, c’est que beaucoup de serveurs sortent en prod avec une config SSH par défaut, pas forcément catastrophique, mais… permissive. Et surtout bourrée de petites habitudes qui finissent en grosse boulette.
L’objectif ici : te donner une checklist simple, faisable en 30 minutes, pour durcir SSH proprement sans te tirer une balle dans le pied. On va rester pragmatiques. Pas de théorie infinie. Des commandes, des fichiers, et des points de contrôle.
Important : fais ça dans une session SSH déjà ouverte. Et idéalement avec un second terminal de secours, ou une console out of band (VPS panel, iLO, IPMI, etc.). Parce que oui, tu peux te lock out.
Pré requis avant de toucher à quoi que ce soit : plan anti lock out
Avant de modifier /etc/ssh/sshd_config :
- ouvre une deuxième session SSH vers le même serveur
- vérifie que tu as un accès console de secours (au cas où)
- note le port actuel (souvent 22)
- note ton utilisateur et si tu as bien
sudo
Et surtout : à chaque étape, tu testes la config, tu reload, et tu reconnectes. C’est la base.
Commandes utiles :
bash sudo sshd -t sudo systemctl reload ssh
sudo systemctl reload sshd
Étape 1 : mettre à jour OpenSSH (la base, mais vraiment)
Oui c’est évident. Non ce n’est pas toujours fait.
Sur Debian/Ubuntu :
bash sudo apt update && sudo apt install --only-upgrade openssh-server
Sur Rocky/Alma/CentOS :
bash sudo dnf update openssh-server
Après mise à jour :
bash ssh -V sshd -V 2>&1 | head -n 1
Étape 2 : sauvegarder ta config et préparer un rollback
Tu vas modifier sshd_config. Tu sauvegardes d’abord :
bash sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M)
Option utile : garder une copie des fichiers inclus, parce que beaucoup de distros utilisent Include :
bash grep -R "^[[:space:]]*Include" /etc/ssh/sshd_config
Étape 3 : désactiver le login root (ou le verrouiller proprement)
Dans /etc/ssh/sshd_config :
conf PermitRootLogin no
Oui. Juste ça, déjà tu enlèves une cible énorme. Tu utilises un utilisateur normal + sudo.
Alternative acceptable si tu sais ce que tu fais : prohibit-password (root autorisé mais uniquement par clé). Perso, sur des serveurs exposés, je préfère no.
Étape 4 : passer en authentification par clé, couper le mot de passe
Tu génères une clé côté client si tu n’en as pas :
bash ssh-keygen -t ed25519 -a 64
Tu copies la clé publique sur le serveur :
bash ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server
Ensuite, dans sshd_config :
conf PasswordAuthentication no KbdInteractiveAuthentication no ChallengeResponseAuthentication no PubkeyAuthentication yes
Puis tu testes dans une nouvelle session :
bash ssh user@server
Seulement après test OK, tu reload :
bash sudo sshd -t && sudo systemctl reload ssh
Étape 5 : limiter les utilisateurs autorisés (le filtre simple et efficace)
Même si tu as plusieurs comptes sur le serveur, tous n’ont pas besoin d’entrer en SSH.
Dans sshd_config :
conf AllowUsers user1 user2
Ou si tu veux gérer par groupe :
conf AllowGroups sshusers
Puis tu ajoutes les bons comptes au groupe :
bash sudo groupadd -f sshusers sudo usermod -aG sshusers user1
Attention : si tu te trompes ici, tu te bloques toi même. Donc tu vérifies deux fois.
Étape 6 : changer le port SSH (optionnel, mais utile contre le bruit)
On va être honnêtes : changer le port ne remplace pas un vrai durcissement. Mais ça coupe une énorme partie du bruit des scans automatisés.
Dans sshd_config :
conf Port 2222
Ensuite, ouvre le firewall avant de reload SSH.
UFW :
bash sudo ufw allow 2222/tcp sudo ufw status
Firewalld :
bash sudo firewall-cmd --add-port=2222/tcp --permanent sudo firewall-cmd --reload
Puis reload SSH et teste :
bash sudo sshd -t && sudo systemctl reload ssh ssh -p 2222 user@server
Et seulement quand tu es sûr, tu peux fermer 22 :
bash sudo ufw delete allow 22/tcp
Étape 7 : durcir les paramètres de session (timeouts, tentatives)
Toujours dans sshd_config :
conf MaxAuthTries 3 LoginGraceTime 20 ClientAliveInterval 300 ClientAliveCountMax 2
Ce que ça fait, en clair : moins de tentatives, moins de temps pour traîner sur l’écran de login, et les sessions mortes dégagent.
Étape 8 : désactiver les fonctions inutiles (surface d’attaque)
Si tu n’en as pas besoin, coupe.
conf X11Forwarding no AllowTcpForwarding no PermitTunnel no GatewayPorts no
Si tu utilises des tunnels SSH (port forwarding) pour du debug, laisse AllowTcpForwarding yes mais réfléchis. Beaucoup de gens l’activent « parce que c’est cool » puis oublient.
Étape 9 : forcer des algorithmes modernes (sans casser les vieux clients)
Selon ta version d’OpenSSH, certains réglages sont déjà bons par défaut. Mais tu peux verrouiller un minimum.
Dans sshd_config, tu peux expliciter :
conf HostKey /etc/ssh/ssh_host_ed25519_key
Et éviter DSA (normalement déjà mort). Pour le reste (KexAlgorithms, Ciphers, MACs), je recommande de ne pas sur-spécifier si tu n’es pas sûr, parce que tu peux casser des clients légitimes. En 30 minutes, la vraie victoire est ailleurs : clés, mots de passe off, root off, allowlist, fail2ban.
Étape 10 : activer des logs propres et surveillables
Dans sshd_config :
conf LogLevel VERBOSE
Puis tu checkes :
bash sudo journalctl -u ssh -n 100 --no-pager
sudo journalctl -u sshd -n 100 --no-pager
Étape 11 : installer Fail2ban (le garde du corps anti bruteforce)
Sur Debian/Ubuntu :
bash sudo apt install fail2ban
Sur Rocky/Alma :
bash sudo dnf install fail2ban
Ensuite :
bash sudo systemctl enable --now fail2ban
Crée un override simple :
bash sudo nano /etc/fail2ban/jail.d/sshd.local
Contenu :
conf [sshd] enabled = true maxretry = 4 findtime = 10m bantime = 1h
Puis :
bash sudo systemctl restart fail2ban sudo fail2ban-client status sshd
Étape 12 : vérifier le firewall (et fermer ce qui ne doit pas être public)
Checklist rapide :
- seul le port SSH (ex : 2222) est ouvert
- pas de ports d’admin exposés par accident
- si possible : restreindre SSH à une IP ou un VPN
Exemple UFW, restriction à une IP :
bash sudo ufw allow from 203.0.113.10 to any port 2222 proto tcp
Là, tu réduis radicalement le risque.
Étape 13 : bonus rapide, un fichier ssh_config côté client pour éviter les erreurs
Sur ton poste, dans ~/.ssh/config :
conf Host monserveur HostName x.x.x.x User user Port 2222 IdentityFile ~/.ssh/id_ed25519
Puis tu te connectes avec :
bash ssh monserveur
Moins d’erreurs, moins de commandes copiées, moins de confusion.
Checklist finale anti boulette (à cocher)
- session SSH de secours ouverte
- backup de
/etc/ssh/sshd_config sshd -tavant chaque reloadPermitRootLogin noPasswordAuthentication noAllowUsersouAllowGroupsconfiguré- timeouts et limites :
MaxAuthTries,ClientAlive* - fonctions inutiles coupées (X11, tunnel, forwarding si inutile)
- port changé (optionnel), firewall aligné
- logs OK (
LogLevel VERBOSE) - Fail2ban actif et testé
- reconnection testée depuis un nouveau terminal
Petit mot de fin (et ressource)
Si tu veux, je publierai aussi une version « durcissement SSH + audit express » avec : audit des clés, sshd -T, bannières légales, 2FA SSH (selon contexte), et une mini routine de monitoring. Je mets souvent ce genre de guides sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com/), donc garde le lien sous le coude si tu bosses sur de la sécu sysadmin ou des checklists rapides de prod.
Et surtout, rappelle toi le vrai truc : le hardening, ce n’est pas de cocher des options au hasard. C’est de réduire ce que tu exposes, puis de vérifier que tu peux toujours entrer. Sans stress. Sans surprise.
Questions fréquemment posées
Pourquoi est-il important de durcir la configuration SSH sur un serveur ?
SSH est souvent la porte d'entrée vers ton infrastructure. Une configuration par défaut, même si elle n'est pas catastrophique, reste permissive et attire les tentatives d'intrusion. Durcir SSH réduit les risques de compromission en limitant les accès et en renforçant l'authentification.
Quelles précautions prendre avant de modifier le fichier /etc/ssh/sshd_config ?
Avant toute modification, ouvre une seconde session SSH et assure-toi d'avoir un accès console de secours (VPS panel, iLO, IPMI). Note le port SSH actuel et ton utilisateur avec droits sudo. Teste chaque changement avec sshd -t, recharge le service SSH, puis reconnecte-toi pour éviter de te bloquer hors du serveur.
Comment désactiver ou sécuriser la connexion root via SSH ?
Dans /etc/ssh/sshd_config, il faut définir PermitRootLogin à 'no' pour interdire totalement l'accès root. Une alternative est 'prohibit-password', qui autorise root uniquement avec une clé SSH. Sur des serveurs exposés, il est recommandé d'utiliser 'no' pour limiter la surface d'attaque.
Quelle est la méthode recommandée pour passer à une authentification par clé SSH ?
Génère une paire de clés côté client avec ssh-keygen (type ed25519 recommandé), copie la clé publique sur le serveur avec ssh-copy-id, puis dans sshd_config désactive PasswordAuthentication, KbdInteractiveAuthentication et ChallengeResponseAuthentication tout en activant PubkeyAuthentication. Teste toujours avant de recharger la configuration.
Comment limiter les utilisateurs autorisés à se connecter via SSH ?
Utilise les directives AllowUsers ou AllowGroups dans /etc/ssh/sshd_config pour restreindre l'accès aux seuls comptes nécessaires. Par exemple, crée un groupe 'sshusers', ajoute-y les utilisateurs autorisés via usermod -aG sshusers user1, puis configure AllowGroups sshusers. Vérifie bien pour ne pas te bloquer toi-même.
Changer le port SSH est-il une bonne pratique de sécurité ?
Changer le port SSH (par exemple vers 2222) ne remplace pas un durcissement complet mais aide à réduire le bruit des scans automatisés. Après avoir modifié le port dans sshd_config, il faut ouvrir ce nouveau port dans le firewall avant de recharger SSH et tester la connexion sur ce nouveau port.
0 Commentaires