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.