Quand on parle de sécurité serveur, la première ligne de front, c’est souvent SSH. C’est la porte d’entrée. Et malheureusement, c’est aussi la cible favorite des bots, des scanners, et parfois même d’attaquants plus sérieux.
On voit encore trop souvent des serveurs accessibles avec le port 22 ouvert à tous vents, du root autorisé en login direct, ou des clés privées non protégées. Et pourtant, il suffit de quelques ajustements pour bloquer 90 % des risques les plus courants.
Dans cet article, on va durcir proprement une config SSH sur Linux, en s’appuyant sur les recommandations officielles de l’ANSSI (l’agence nationale française en charge de la cybersécurité). C’est du solide, éprouvé, et adapté à une production sérieuse.
1. Désactiver l’accès root en SSH
Pourquoi ? Parce que si un attaquant trouve le mot de passe root, il a directement les pleins pouvoirs. Mieux vaut obliger à passer par un utilisateur classique, puis faire un sudo une fois connecté.
Dans /etc/ssh/sshd_config, vérifie ou ajoute :
PermitRootLogin noEt relance le service :
sudo systemctl restart sshd⚠️ Si tu es connecté en root en ce moment, commence par créer un nouvel utilisateur et ajoute-le au groupe sudo avant de couper l’accès root :
adduser monuser
usermod -aG sudo monuser2. Interdire l’authentification par mot de passe
Pourquoi ? Parce que les attaques par force brute sur SSH, ça tourne en boucle sur des milliers de serveurs. L’objectif : deviner ton mot de passe.
La solution propre, c’est d’utiliser uniquement les clés SSH.
Dans sshd_config :
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM noEt assure-toi d’avoir ta clé publique dans ~/.ssh/authorized_keys de ton utilisateur.
3. Utiliser une paire de clés forte (ed25519 ou RSA ≥ 4096)
Les anciennes clés DSA ou RSA 1024 ne sont plus considérées comme sûres. L’ANSSI recommande d’utiliser ed25519, ou à défaut, RSA 4096 bits.
Pour générer une nouvelle clé (sur ta machine locale) :
ssh-keygen -t ed25519 -a 100Le -a 100 renforce la dérivation de la clé privée, donc plus de sécurité côté brute force.
Si tu dois utiliser RSA :
ssh-keygen -t rsa -b 4096 -o -a 100Et évidemment, protège ta clé privée avec une passphrase solide.
4. Limiter le port d’écoute (et éventuellement le changer)
Changer le port SSH (22 → autre) ne renforce pas vraiment la sécurité, mais ça limite la visibilité aux scripts automatisés. Si tu veux le faire :
Port 2222Mais surtout, restreins l’écoute SSH à certaines IP, si possible :
ListenAddress 192.168.1.10Ou mieux : via un pare-feu, n’autoriser le port SSH qu’aux IP que tu utilises vraiment.
5. Activer les logs et surveiller les connexions
Tu ne peux pas sécuriser ce que tu ne vois pas.
Dans sshd_config :
LogLevel VERBOSETu pourras ensuite consulter les logs SSH ici :
sudo journalctl -u ssh
# ou
sudo less /var/log/auth.logEt pour une surveillance plus poussée, pense à intégrer SSH à Wazuh, CrowdSec ou même un petit script maison pour détecter les connexions anormales.
6. Restreindre les utilisateurs autorisés
Tu ne veux probablement pas que n’importe quel utilisateur système puisse se connecter via SSH.
Dans sshd_config, spécifie les utilisateurs ou groupes autorisés :
AllowUsers alice bobOu par groupe :
AllowGroups admins7. Forcer des algorithmes modernes (cryptographie)
L’ANSSI recommande d’utiliser des algorithmes forts et d’éliminer les vieux chiffrement bancals.
Voici un exemple conforme :
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512,hmac-sha2-256Et on désactive ce qui est obsolète :
HostKeyAlgorithms ssh-ed25519,ssh-rsa(Même ssh-rsa est en voie de dépréciation — à tester selon ton parc).
8. Activer le délai de bannissement après échecs (Fail2ban ou CrowdSec)
En complément, tu peux installer un outil comme CrowdSec ou Fail2ban pour bloquer automatiquement les IP qui s’acharnent.
Avec fail2ban, par exemple :
sudo apt install fail2banPuis créer un fichier /etc/fail2ban/jail.local :
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 36009. Limiter le nombre de tentatives et la vitesse de connexion
Toujours dans sshd_config :
MaxAuthTries 3
LoginGraceTime 30
MaxSessions 2Moins de tentatives, moins de temps pour s’authentifier : les bots auront moins de marge pour tester.
10. Tester avant de relancer
C’est le détail qui sauve : toujours tester la nouvelle config dans une autre session SSH avant de relancer le service.
sudo sshd -tPuis, si c’est bon :
sudo systemctl restart sshEt garde ta session initiale ouverte, au cas où la nouvelle config te verrouille dehors.
