Le protocole SSH reste la porte d’entrée la plus courante des administrateurs sur les serveurs Linux, et il attire naturellement les attaques automatisées. Face aux tentatives de connexion répétées et aux attaques par force brute, il faut une réponse rapide et concrète.
En trente minutes, une combinaison d’authentification par clés et de Fail2ban permet d’obtenir un accès sécurisé utilisable en production immédiatement. Les étapes pratiques suivantes facilitent une mise en place robuste pour réduire le bruit et bloquer les IP malveillantes.
A retenir :
- Authentification par clés SSH forte, gestion centralisée des clés
- Fail2ban actif, blocage des IP après tentatives répétées
- Pare-feu configuré, restrictions par adresse IP
- Port SSH non standard, surveillance des journaux système
Configurer l’authentification par clés SSH pour un accès sécurisé
En liaison avec le rappel précédent, commencer par l’authentification par clés réduit immédiatement les risques liés aux mots de passe. Sophie, administratrice d’une PME, a d’abord généré une paire de clés ed25519 et centralisé la gestion pour ses serveurs.
Sur une machine locale, la commande ssh-keygen -t ed25519 -C « admin@exemple.com » crée une clé publique et une clé privée sécurisées. Copier la clé publique vers le serveur avec ssh-copy-id facilite l’accès sans mot de passe, et cela prépare la désactivation progressive de l’authentification par mot de passe.
Modifier /etc/ssh/sshd_config permet de renforcer les options essentielles comme PasswordAuthentication no et PermitRootLogin no pour fermer les entrées classiques. Redémarrer le service SSH ensuite garantit l’application des paramètres et prépare l’étape suivante qui consiste à ajouter une protection active contre le brute force.
Paramètres de sécurité recommandés :
- Clé ed25519 unique par utilisateur, pas de partage
- PasswordAuthentication disabled, accès par clés uniquement
- PermitRootLogin disabled, comptes administrateurs dédiés
- PubkeyAuthentication enabled, vérification de la liste d’autorisation
Selon la documentation officielle d’OpenSSH, les clés publiques offrent une meilleure résistance aux attaques automatisées que les mots de passe. L’adoption de ces paramètres réduit la surface d’attaque et prépare la mise en place de Fail2ban pour un blocage IP actif.
Génération et déploiement des clés SSH
Ce H3 se rattache à la configuration des clés et détaille la séquence opérationnelle à suivre pour Sophie. Commencer par ssh-keygen, puis vérifier la présence de id_ed25519.pub avant la copie vers le serveur.
L’exemple pratique montre que ssh-copy-id user@serveur automatise l’ajout dans authorized_keys et évite les erreurs manuelles. Après cette opération, une connexion testée avec ssh user@serveur confirme le fonctionnement et prépare l’étape Fail2ban.
Paramètres SSH serveur recommandés
Paramètre
Valeur recommandée
Effet attendu
PasswordAuthentication
no
Empêche l’authentification par mot de passe
PermitRootLogin
no
Réduit l’impact d’une compromission du compte root
PubkeyAuthentication
yes
Autorise l’authentification par clé publique
AllowUsers
user@ip spécifique
Limite les accès aux adresses IP connues
Ces réglages s’appuient sur des pratiques éprouvées et sur des recommandations publiques, et ils préparent un blocage IP efficace par Fail2ban. La protection active qui suit complète le verrouillage de l’accès SSH et oriente vers la surveillance continue.
« J’ai réduit les tentatives de brute force sur nos serveurs en activant les clés et en fermant l’accès root. »
Paul N.
Installer et configurer Fail2ban pour bloquer automatiquement
En continuité de la sécurisation des accès, l’ajout de Fail2ban protège contre les attaques par force brute en analysant les journaux. L’outil augmente la résilience du serveur en bannissant automatiquement les adresses IP fautives.
Sur Debian ou Ubuntu, sudo apt install fail2ban installe le paquet et permet la création d’un fichier /etc/fail2ban/jail.local personnalisé. Une configuration minimale pour sshd inclut enabled = true, port = ssh, logpath = /var/log/auth.log.
Selon la documentation Fail2ban, définir maxretry sur cinq et bantime sur une heure bloque efficacement les bots sans pénaliser des utilisateurs légitimes. Une fois activé, redémarrer le service et vérifier le statut avec sudo fail2ban-client status sshd assure le bon fonctionnement.
Étapes d’installation :
- Installer fail2ban via le gestionnaire de paquets
- Créer /etc/fail2ban/jail.local personnalisé
- Configurer maxretry et bantime selon le risque
- Redémarrer le service et vérifier le statut
Un contrôle régulier des journaux complète Fail2ban, et il faut ajuster les règles si des faux positifs apparaissent. Cette phase opérationnelle prépare la surveillance réseau et l’intégration avec les pare-feu existants.
« Après l’installation de Fail2ban, le nombre d’IP malveillantes a chuté drastiquement, facilitant notre exploitation. »
Sophie N.
Exemple de fichier jail.local pour SSH
Ce H3 précise le contenu minimal du fichier jail.local afin de rendre Fail2ban efficace dès la première mise en service. Inclure un bloc [sshd] actif, le port, le chemin du journal et les valeurs de seuil comme maxretry et bantime.
Option
Exemple
Raison
enabled
true
Activation de la surveillance SSH
port
ssh ou 2222
Permet la flexibilité si port non standard
logpath
/var/log/auth.log
Source des tentatives de connexion
maxretry
5
Seuil courant pour bloquer les bots
bantime
3600
Blocage d’une heure pour dissuader les attaques
Selon la documentation officielle de Fail2ban, ces paramètres constituent un bon compromis entre sécurité et disponibilité. Ajuster ces valeurs selon le contexte applicatif reste une meilleure pratique pour éviter les interruptions involontaires.
« L’automatisation du blocage IP nous a permis d’économiser du temps d’administration et d’alerter plus vite. »
Marc N.
Durcissement complémentaire, surveillance et bonnes pratiques opérationnelles
Pour aller plus loin après Fail2ban, combiner pare-feu, restrictions IP et surveillance renforce la protection globale. Un pare-feu comme UFW ou nftables appliqué en complément réduit fortement la surface d’attaque réseau.
Parmi les bonnes pratiques, l’usage d’un port non standard comme 2222, la définition d’AllowUsers pour limiter les adresses IP et la collecte des logs avec journalctl sont des mesures simples. Cette phase opérationnelle vise à détecter les anomalies et prévenir les attaques persistantes.
Selon l’ANSSI, une stratégie de défense en profondeur combinant contrôles d’accès, filtrage réseau et surveillance améliore significativement la résilience. Préparer des règles de blocage granulaires facilite le maintien de l’accès légitime et la réduction des faux positifs.
Bonnes pratiques opérationnelles :
- Activer un pare-feu et limiter l’accès aux IP connues
- Utiliser des clés SSH fortes et renouveler périodiquement
- Surveiller les journaux avec journalctl -u sshd
- Documenter et tester les procédures de déblocage
Pour illustrer, Sophie a mis en place des règles UFW et des scripts d’alerte qui collectent les tentatives de connexion suspectes. Cette démarche a réduit le temps moyen de réaction face aux incidents et a renforcé la sécurité opérationnelle.
« La combinaison clés SSH et Fail2ban a transformé notre gestion des accès à distance. »
Elise N.
La mise en place de ces couches complémentaires permet de maintenir un accès sécurisé tout en limitant les interruptions pour les personnels autorisés. Une revue périodique des règles et des journaux garantit le maintien de cette protection au fil du temps.
Source : ANSSI, « Guide d’hygiène informatique », ANSSI, 2018 ; The OpenBSD Project, « OpenSSH », openbsd.org ; fail2ban contributors, « fail2ban documentation », fail2ban.org.
