Comment prot?ger son serveur SSH des attaques brute force en 2026

Pourquoi votre serveur SSH est une cible permanente

Le protocole SSH ?coute sur le port 22 par d?faut, accessible depuis n'importe o? sur Internet. Des botnets automatis?s testent en permanence des millions d'adresses IP, cherchant des serveurs qui r?pondent sur ce port, puis tentent des milliers de combinaisons login/mot de passe par seconde.

Si votre serveur est expos? sur Internet, vous subissez probablement des centaines d'attaques par jour sans le savoir. V?rifiez par vous-m?me :

grep "Failed password" /var/log/auth.log | wc -l

Le r?sultat vous surprendra. Sur un serveur expos? depuis quelques semaines, il n'est pas rare de voir des dizaines de milliers d'?checs d'authentification.

1. Passer aux cl?s SSH ? la mesure la plus importante

L'authentification par mot de passe est la principale porte d'entr?e des attaques brute force. Un mot de passe, aussi complexe soit-il, peut ?tre devin? avec suffisamment de tentatives. Une cl? cryptographique, elle, est math?matiquement impossible ? forcer.

G?n?rer une paire de cl?s ED25519

Sur votre machine locale (jamais sur le serveur), g?n?rez une paire de cl?s. ED25519 est l'algorithme recommand? en 2026 ? plus rapide et plus robuste que RSA ou ECDSA :

# G?n?rer la paire de cl?s
ssh-keygen -t ed25519 -C "votre@email.com" -f ~/.ssh/id_ed25519

# Optionnel : prot?ger la cl? priv?e par un mot de passe
# (fortement recommand? si votre machine locale peut ?tre vol?e)

Copier la cl? publique sur le serveur

# M?thode automatique (recommand?e)
ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@votre-serveur

# M?thode manuelle si ssh-copy-id n'est pas disponible
cat ~/.ssh/id_ed25519.pub | ssh utilisateur@serveur \
  "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

D?sactiver l'authentification par mot de passe

Éditez /etc/ssh/sshd_config :

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AuthorizedKeysFile .ssh/authorized_keys

Red?marrez SSH :

sudo systemctl restart sshd

2. Changer le port SSH par d?faut

Le port 22 est la premi?re cible des scanners automatiques. Changer pour un port non standard (entre 1024 et 65535) ?limine l'immense majorit? des tentatives ? les bots opportunistes ne scannent que les ports par d?faut. Ce n'est pas une protection suffisante seule, mais combin?e aux autres mesures, elle r?duit consid?rablement le bruit.

Dans /etc/ssh/sshd_config :

Port 2222   # Remplacez par le port de votre choix

Ouvrez ce port dans votre pare-feu avant de red?marrer SSH :

# Avec UFW (Ubuntu/Debian)
sudo ufw allow 2222/tcp comment "SSH custom port"
sudo ufw reload

# Avec firewalld (CentOS/RHEL)
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

# Avec iptables
sudo iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
sudo iptables-save > /etc/iptables/rules.v4

Puis red?marrez SSH et reconnectez-vous avec le nouveau port :

sudo systemctl restart sshd
ssh -p 2222 utilisateur@votre-serveur

3. Configurer Fail2ban

Fail2ban surveille vos fichiers de logs en temps r?el et bannit automatiquement les adresses IP qui ?chouent trop souvent ? s'authentifier. C'est la protection la plus r?pandue contre les attaques brute force SSH.

Installation

# Ubuntu / Debian
sudo apt update && sudo apt install fail2ban -y

# CentOS / RHEL
sudo dnf install fail2ban -y

# V?rifier que le service est actif
sudo systemctl enable fail2ban && sudo systemctl start fail2ban

Configuration recommand?e

Ne modifiez jamais jail.conf directement ? il sera ?cras? lors des mises ? jour. Cr?ez toujours un fichier local :

sudo nano /etc/fail2ban/jail.local

[DEFAULT]
# Dur?e du ban : 1 heure
bantime  = 3600

# Fen?tre d'analyse : 10 minutes
findtime = 600

# Nombre maximum de tentatives avant ban
maxretry = 5

# IP whitelist (votre bureau, VPN...)
ignoreip = 127.0.0.1/8 ::1 203.0.113.0/24

[sshd]
enabled  = true
port     = 2222          # votre port SSH
logpath  = /var/log/auth.log
maxretry = 3             # plus strict que le d?faut pour SSH
bantime  = 86400         # 24h pour SSH sp?cifiquement

Appliquez et v?rifiez :

sudo systemctl restart fail2ban

# Voir les IP actuellement bannies
sudo fail2ban-client status sshd

# D?bloquer une IP par erreur
sudo fail2ban-client set sshd unbanip 203.0.113.42

4. Restreindre l'acc?s SSH par pare-feu

Si vous vous connectez depuis des IP fixes (bureau, VPN), la protection la plus efficace est de n'autoriser SSH qu'? partir de ces adresses pr?cises. Une IP non autoris?e ne re?oit m?me pas de r?ponse ? le brute force devient impossible.

# UFW : autoriser uniquement votre IP
sudo ufw allow from 203.0.113.42 to any port 2222 comment "SSH depuis bureau"
sudo ufw allow from 10.0.0.0/8 to any port 2222 comment "SSH depuis VPN"

# Bloquer tout le reste sur ce port
sudo ufw deny 2222

sudo ufw reload
sudo ufw status verbose

5. Configuration SSH avanc?e

D'autres directives dans /etc/ssh/sshd_config renforcent significativement la s?curit? sans impact sur l'usage quotidien :

# D?sactiver le forwarding X11 (inutile sur un serveur headless)
X11Forwarding no

# Limiter les tentatives par connexion
MaxAuthTries 3

# Timeout des sessions inactives (5 min)
ClientAliveInterval 300
ClientAliveCountMax 2

# D?sactiver les m?thodes d'authentification inutilis?es
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

# N'autoriser que des utilisateurs sp?cifiques ? se connecter
AllowUsers votre_user deploy ansible

# D?sactiver les tunnels TCP (si non n?cessaires)
AllowTcpForwarding no

# Niveau de log ?lev? pour la tra?abilit?
LogLevel VERBOSE

Apr?s chaque modification, v?rifiez la syntaxe avant de red?marrer :

sudo sshd -t   # Teste la configuration sans red?marrer
sudo systemctl restart sshd

6. Surveiller vos logs SSH en continu

La s?curit? n'est pas une configuration unique ? c'est un processus. Voici les commandes essentielles pour garder un ?il sur votre serveur au quotidien :

# Connexions SSH r?centes (r?ussies et ?chou?es)
last -n 20

# Surveiller les tentatives en temps r?el
sudo tail -f /var/log/auth.log | grep --line-buffered "sshd"

# Statistiques d'?chec par IP
grep "Failed password" /var/log/auth.log | \
  awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20

# Connexions SSH actuellement actives
ss -tnp | grep :2222

# R?sum? Fail2ban
sudo fail2ban-client status sshd

7. Au-del? de Fail2ban : la d?fense automatis?e

Fail2ban est excellent pour les attaques brute force classiques. Mais il a des limites importantes ? conna?tre :

• Il r?agit, il n'anticipe pas. Un attaquant doit d'abord ?chouer plusieurs fois avant d'?tre banni ? ce qui laisse une fen?tre d'exposition.
• Il ne voit pas les attaques distribu?es. Si 1000 bots font chacun une seule tentative depuis des IP diff?rentes, Fail2ban ne d?tecte rien.
• La maintenance est manuelle. Chaque nouveau serveur doit ?tre configur? s?par?ment. Les logs doivent ?tre surveill?s.
• Il ne partage pas les menaces. Une IP malveillante bloqu?e sur un de vos serveurs peut continuer ? attaquer les autres.

Les solutions de cybers?curit? cloud comme CyberGuard r?pondent ? ces limites avec une approche diff?rente :

• Threat intelligence partag?e : les IP identifi?es comme malveillantes chez n'importe quel client sont imm?diatement bloqu?es chez tous.
• D?tection comportementale : les attaques lentes et distribu?es sont d?tect?es par analyse de patterns, pas seulement par comptage de tentatives.
• Gestion centralis?e : un seul tableau de bord pour tous vos serveurs, APIs, et domaines.
• Alertes temps r?el : notification imm?diate d?s qu'une anomalie est d?tect?e, avant qu'elle ne devienne un incident.

Checklist ? S?curisez votre serveur SSH maintenant

Conclusion

La s?curisation SSH n'est pas optionnelle pour tout serveur expos? sur Internet. Les quatre mesures fondamentales ? cl?s SSH, port non standard, Fail2ban, restriction par pare-feu ? peuvent ?tre mises en place en moins d'une heure et couvrent la grande majorit? des attaques opportunistes.

Pour aller plus loin, notamment si vous g?rez plusieurs serveurs ou des environnements critiques, une solution de surveillance automatis?e vous donnera une visibilit? en temps r?el et une protection contre les attaques plus sophistiqu?es que Fail2ban ne peut pas d?tecter.