Sécuriser l’accès SSH à vos serveurs : clés, fail2ban et bonnes pratiques
Mis à jour le 29 mars 2026
Sécuriser l’accès SSH à vos serveurs : clés, fail2ban et bonnes pratiques
SSH (Secure Shell) est le protocole standard d’administration à distance des serveurs Linux. C’est aussi la cible numéro un des attaques automatisées : un serveur exposé sur internet reçoit en moyenne 10 000 tentatives de connexion SSH frauduleuses par jour, selon les données de Honeypot Project. Sécuriser l’accès SSH n’est pas un luxe de sysadmin paranoïaque : c’est la première ligne de défense de votre infrastructure.
Sommaire
Les menaces qui ciblent SSH
Les attaques SSH sont massives, automatisées et permanentes. Des botnets parcourent internet en continu, testant des combinaisons d’identifiants sur chaque serveur détecté avec le port 22 ouvert.
Les types d’attaques
- Brute force : tentative de toutes les combinaisons possibles de mots de passe
- Dictionary attack : utilisation de listes de mots de passe courants (admin, root, password123)
- Credential stuffing : réutilisation de couples identifiant/mot de passe issus de fuites de données
- Exploitation de vulnérabilités : attaque de versions de OpenSSH non patchées
- Man-in-the-middle : interception de la connexion SSH sur un réseau compromis
Authentification par clés : la base
L’authentification par clé SSH est la mesure de sécurité la plus fondamentale et la plus efficace. Elle remplace le mot de passe par un couple de clés cryptographiques (clé privée + clé publique), rendant les attaques par brute force totalement inefficaces.
Comment fonctionnent les clés SSH
Le principe est simple : vous générez une paire de clés sur votre poste de travail. La clé publique est copiée sur le serveur. Lors de la connexion, le serveur vérifie que vous possédez la clé privée correspondante, sans jamais la transmettre sur le réseau.
Générer et déployer une clé SSH
La génération d’une clé SSH se fait en une seule commande. En 2026, l’algorithme recommandé est Ed25519, plus sûr et plus rapide que le RSA traditionnel. La commande ssh-keygen -t ed25519 génère la paire de clés. Protégez la clé privée avec une passphrase forte.
- Utilisez Ed25519 (ou RSA 4096 bits si la compatibilité l’exige)
- Protégez toujours la clé privée avec une passphrase
- Utilisez ssh-agent pour ne saisir la passphrase qu’une seule fois par session
- Ne partagez jamais votre clé privée, ne la stockez jamais sur un serveur
- Générez une clé par utilisateur, pas une clé partagée
Point clé : Une fois l’authentification par clé en place et testée, désactivez impérativement l’authentification par mot de passe dans la configuration SSH (PasswordAuthentication no). Tant que l’authentification par mot de passe reste active, les attaques par brute force restent possibles, même si vous utilisez aussi des clés.
Fail2ban : bloquer les attaquants
Fail2ban est un outil qui surveille les logs système et bloque automatiquement les adresses IP qui génèrent des échecs de connexion répétés. C’est un complément indispensable à l’authentification par clé.
Configuration de Fail2ban pour SSH
La configuration par défaut de Fail2ban pour SSH est déjà efficace. Elle surveille le fichier de log auth.log (ou secure sur CentOS) et bloque toute IP qui échoue 5 fois en 10 minutes, pour une durée de 10 minutes.
Pour une protection renforcée, ajustez ces paramètres :
- maxretry = 3 : bloquez après 3 échecs au lieu de 5
- bantime = 3600 : bloquez pendant 1 heure au lieu de 10 minutes
- findtime = 600 : fenêtre de détection de 10 minutes
- bantime.increment = true : durée de blocage progressive (ban exponentiel)
Actions et notifications
Fail2ban peut envoyer un email à chaque blocage, permettant de suivre les tentatives d’intrusion. Pour les serveurs critiques, configurez une notification Slack ou un envoi vers votre outil de monitoring pour une visibilité en temps réel.
L’action de blocage par défaut utilise iptables pour rejeter les connexions de l’IP bannie. Sur les distributions modernes utilisant nftables, configurez Fail2ban pour utiliser nftables en natif pour de meilleures performances.
Durcissement de la configuration SSH
Le fichier de configuration du serveur SSH (/etc/ssh/sshd_config) offre de nombreuses options de durcissement. Chaque option réduit la surface d’attaque.
Les paramètres de durcissement essentiels
- PermitRootLogin no : interdisez la connexion directe en root, utilisez sudo
- PasswordAuthentication no : désactivez l’authentification par mot de passe
- MaxAuthTries 3 : limitez le nombre de tentatives par connexion
- LoginGraceTime 30 : 30 secondes maximum pour s’authentifier
- AllowUsers user1 user2 : limitez explicitement les utilisateurs autorisés
- Protocol 2 : forcez l’utilisation de SSH version 2 uniquement
- X11Forwarding no : désactivez le forwarding graphique si non nécessaire
Changer le port SSH
Changer le port SSH par défaut (22) vers un port non standard (par exemple 2222 ou 22222) réduit considérablement le nombre de tentatives automatisées. Ce n’est pas une mesure de sécurité à proprement parler (security by obscurity), mais elle filtre efficacement 95 % des bots qui ne scannent que le port 22.
Si vous changez le port, documentez-le clairement et mettez à jour les règles de pare-feu en conséquence. Vérifiez également que le nouveau port n’est pas utilisé par un autre service.
Bonnes pratiques avancées
Au-delà de la configuration SSH elle-même, plusieurs pratiques renforcent la sécurité de l’accès à vos serveurs.
Bastion host (jump server)
Un bastion host est un serveur durci qui sert de point d’entrée unique pour accéder aux autres serveurs de l’infrastructure. Les serveurs internes n’exposent pas leur port SSH à internet. Pour y accéder, il faut d’abord se connecter au bastion, puis rebondir vers le serveur cible.
La directive ProxyJump dans la configuration SSH du client simplifie cette double connexion en une seule commande. L’avantage est considérable : un seul point à sécuriser, à monitorer et à auditer.
Authentification multi-facteurs
Pour les serveurs les plus critiques, l’authentification multi-facteurs (MFA) ajoute une couche de sécurité supplémentaire. Google Authenticator (libpam-google-authenticator) ou un module PAM compatible TOTP permet d’exiger un code temporaire en plus de la clé SSH.
- Clé SSH + TOTP : protection maximale contre le vol de clé privée
- Configuration via PAM (Pluggable Authentication Modules)
- Compatible avec les applications d’authentification standard (Google Authenticator, Authy)
Besoin d’accompagnement ?
Odyssix sécurise l’accès SSH de vos serveurs selon les meilleures pratiques du secteur. Audit de configuration, déploiement de clés, mise en place de Fail2ban, configuration de bastion : nous verrouillons votre infrastructure sans compromettre l’accessibilité.
Rédigé par l'équipe Odyssix
Experts IT, Cybersécurité & Digital depuis 2018
Odyssix accompagne les PME dans leur transformation numérique et la sécurisation de leur système d'information. Nos experts certifiés (CEH, OSCP, ISO 27001) partagent leur expérience terrain à travers nos articles de blog.
Besoin d'en savoir plus ?
Contactez nos experts pour une démonstration personnalisée.
