Rédigé par Rédaction CyberSDF / 19 September 2026 / mis à jour 23 September 2026

fail2ban : bannir les adresses qui tentent des mots de passe SSH

un poste de travail sobre vu de trois quarts, ecran eteint, clavier mecanique, carnet ouvert

« Have not found any log file for sshd jail » : ce message tombe à l’installation de fail2ban sur une Debian 12 dépourvue de rsyslog, alors que la prison sshd est activée d’office par le paquet. Les deux versions livrées par Debian ne lisent pas les mêmes traces. Le paquet Debian 12 (bookworm) embarque fail2ban 1.0.2-2 et surveille /var/log/auth.log. Celui de Debian 13 (trixie) embarque 1.1.0-8, lit le journal systemd et bannit avec nftables.

Sommaire

Dix minutes de ban et cinq essais, actifs dès apt install
Cinq étapes, jusqu’au ban vérifié dans le pare-feu
« Have not found any log file » : le cas de Debian 12 sans rsyslog
Le socket explique les deux messages d’erreur de fail2ban-client
Le compteur par adresse ne voit ni l’attaque répartie ni les clés refusées
Le ban dépend de trois valeurs et d’une liste d’exceptions

Dix minutes de ban et cinq essais, actifs dès apt install

fail2ban compte les échecs d’authentification et bloque l’adresse qui recommence. Les valeurs appliquées sortent de deux fichiers livrés par les paquets : /etc/fail2ban/jail.conf pose bantime = 10m, findtime = 10m et maxretry = 5, et /etc/fail2ban/jail.d/defaults-debian.conf active la prison sshd sans qu’aucune ligne soit à écrire. Le paquet Debian 12 embarque fail2ban 1.0.2-2, dont le fichier Debian se limite à enabled = true : la prison lit /var/log/auth.log et le ban passe par iptables-multiport. Le paquet Debian 13 embarque fail2ban 1.1.0-8, dont le defaults-debian.conf ajoute trois lignes décisives, banaction = nftables, backend = systemd et journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd. Un tutoriel écrit pour l’une des deux versions ne se transpose donc pas à l’autre, et le premier réglage à vérifier reste la source des échecs de la prison.

Ce que le paquet fixe	Debian 12, fail2ban 1.0.2-2	Debian 13, fail2ban 1.1.0-8
Source des échecs	/var/log/auth.log, backend auto	journal systemd, backend systemd
Filtre du journal	aucun, lecture du fichier	_SYSTEMD_UNIT=ssh.service + _COMM=sshd
Action de ban	iptables-multiport	nftables
Durée du ban, bantime	10 minutes	10 minutes
Essais avant ban, maxretry	5	5
Fenêtre de comptage, findtime	10 minutes	10 minutes
Statistiques par prison	absentes de fail2ban-client	fail2ban-client stats

sudo apt install fail2ban
sudo systemctl status fail2ban --no-pager
sudo fail2ban-client status

La deuxième commande annonce Active: active (running), la troisième affiche Jail list: sshd.

Cinq étapes, jusqu’au ban vérifié dans le pare-feu

Un ban se contrôle à trois endroits, la prison, son journal et les règles du pare-feu, et ces contrôles se font dans cet ordre. La procédure vise une Debian 13 avec fail2ban 1.1.0-8, où la source des échecs est le journal systemd et l’action de ban nftables ; sur Debian 12, seule la dernière étape change, iptables remplaçant nft. La prison porte le nom sshd, son filtre est sshd.conf, et l’action exécutée est celle du réglage banaction. Un ban manuel déclenche exactement la même action qu’une attaque réelle, il sert donc à valider la chaîne complète sans attendre cinq échecs. La levée du ban se fait par la commande inverse, et l’adresse doit alors disparaître de la liste comme du pare-feu. Chaque étape se termine par la sortie attendue, et une sortie différente désigne l’étape fautive.

Installez le paquet et vérifiez l’état du service.
```
sudo apt install fail2ban
sudo systemctl status fail2ban --no-pager
```
À l’écran : Active: active (running), puis ExecStart=/usr/bin/fail2ban-server -xf start, la commande de démarrage de l’unité fail2ban.service.
Lisez la source d’échecs de la prison.
```
sudo fail2ban-client status sshd
```
À l’écran : Journal matches: _SYSTEMD_UNIT=ssh.service + _COMM=sshd sur Debian 13, File list: /var/log/auth.log au même endroit sur Debian 12.
Écrivez vos valeurs dans un fichier local, lu après jail.conf et après les .conf de jail.d, comme le documente la page jail.conf(5).
```
sudo nano /etc/fail2ban/jail.d/sshd.local
```
```
[sshd]
bantime  = 1h
findtime = 10m
maxretry = 4
ignoreip = 127.0.0.1/8 ::1 198.51.100.0/24
```
```
sudo fail2ban-client -t
sudo systemctl reload fail2ban
```
À l’écran : OK: configuration test is successful, chaîne écrite dans fail2bancmdline.py.
Bannissez une adresse de documentation, puis relisez la prison.
```
sudo fail2ban-client set sshd banip 203.0.113.9
sudo fail2ban-client status sshd
sudo fail2ban-client get sshd banip --with-time
```
À l’écran : Currently banned: 1 et Banned IP list: 203.0.113.9, puis l’horodatage de fin de ban. Le journal /var/log/fail2ban.log enregistre NOTICE [sshd] Ban 203.0.113.9.
Contrôlez la règle, puis levez le ban.
```
sudo nft list table inet f2b-table
sudo fail2ban-client set sshd unbanip 203.0.113.9
sudo fail2ban-client banned
```
À l’écran : la table inet f2b-table contient la chaîne f2b-chain et un ensemble d’adresses où figure l’adresse bannie, la règle se terminant par reject. Après la levée, fail2ban-client banned ne renvoie plus rien pour sshd.

« Have not found any log file » : le cas de Debian 12 sans rsyslog

Une Debian 12 minimale sans rsyslog n’écrit jamais /var/log/auth.log, et la prison sshd refuse alors de démarrer. Le message vient du lecteur de configuration du client, jailreader.py, et le rapport Debian 1070677 le cite dans son titre, « Failed during configuration: Have not found any log file for sshd jail ». La cause tient à la ligne logpath = %(sshd_log)s de jail.conf, que paths-common.conf résout en /var/log/auth.log : le lecteur cherche le fichier, ne trouve rien, et lève une erreur au lieu de démarrer. Le journal des modifications du paquet Debian date la correction du 25 mai 2024, en version 1.1.0-3, avec le rétablissement de nftables et du backend systemd pour certaines prisons. Sur Debian 13, ce cas ne se produit plus, le backend systemd ignorant logpath et lisant le journal.

Failed during configuration: Have not found any log file for sshd jail

Deux remèdes, selon ce que vous voulez garder.

sudo apt install rsyslog

[sshd]
backend = systemd

Le socket explique les deux messages d’erreur de fail2ban-client

Toutes les commandes fail2ban-client passent par un socket Unix, /var/run/fail2ban/fail2ban.sock d’après fail2ban.conf, et trois messages distincts signalent trois pannes différentes. « Failed to access socket path: … Is fail2ban running? » signifie que le fichier n’existe pas, donc que le service est arrêté. « Permission denied to socket: …, (you must be root) » signifie que le fichier existe mais que la commande n’a pas été lancée en root. Le troisième, « Unable to contact server. Is it running? », apparaît quand le fichier existe et reste accessible sans que le serveur réponde. Les trois chaînes sont identiques dans les versions 1.0.2 et 1.1.0, où elles vivent dans fail2ban/client/fail2banclient.py. Le client avertit aussi qu’un socket périmé peut bloquer le lancement et propose de le retirer avec l’option -x. Le diagnostic commence donc par l’état du service, jamais par la configuration.

Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?
Permission denied to socket: /var/run/fail2ban/fail2ban.sock, (you must be root)

sudo systemctl status fail2ban --no-pager
sudo journalctl -u fail2ban -n 50 --no-pager
sudo systemctl restart fail2ban

La troisième commande crée un socket neuf. Cherchez ensuite la ligne qui précède l’arrêt du service, méthode détaillée dans lire les journaux systemd.

Le compteur par adresse ne voit ni l’attaque répartie ni les clés refusées

Un ban repose sur un compteur par adresse, remis à zéro après findtime, ce qui borne ce que la méthode peut arrêter. Une attaque étalée sur mille adresses, à raison d’une tentative chacune, n’atteint jamais maxretry = 5 dans la fenêtre de 10 minutes fixée par jail.conf. Le filtre sshd.conf de fail2ban 1.1.0 déclare en outre publickey = nofail : un refus de clé pour un utilisateur connu n’incrémente pas le compteur, et une machine en clés seules peut afficher Total failed: 0 pendant toute la campagne. Le wiki Arch formule la même réserve et déconseille fail2ban quand seule l’authentification par clé est ouverte, la vraie parade restant de désactiver les mots de passe. La ligne Connection from … port … n’est écrite qu’avec LogLevel VERBOSE dans sshd_config, comme l’en-tête de sshd.conf le signale.

Si le service SSH refuse la connexion au lieu de simplement ignorer les tentatives, la cause est ailleurs : Connection refused sous Linux détaille les six causes possibles — service non démarré, mauvais port, écoute sur localhost, pare-feu, adresse de liaison ou limite de connexions. Sur un serveur joignable depuis Internet, fail2ban protège SSH du brute force contre un robot isolé, puis cède la place aux clés, traitées dans la configuration de SSH, et à un second facteur, décrit dans l’authentification à deux facteurs. Le reste du travail de fond relève de durcir un serveur Debian, la rubrique Linux rassemblant ces chantiers.

Le ban dépend de trois valeurs et d’une liste d’exceptions

Trois valeurs et une liste d’adresses décident si une adresse finit bannie : maxretry fixe le nombre d’échecs, findtime la fenêtre pendant laquelle ils sont comptés, bantime la durée du blocage, et ignoreip les adresses épargnées. Le paquet fixe maxretry = 5, findtime = 10m et bantime = 10m dans jail.conf, tandis que l’action et la source des échecs varient selon la version de Debian. Un ban se produit donc au cinquième échec en dix minutes, pour dix minutes, sauf si l’adresse figure dans ignoreip ou correspond à une adresse de la machine, que ignoreself = true protège déjà. Une valeur trop basse de maxretry bannit sur trois fautes de frappe, une valeur trop haute laisse passer un millier d’essais avant la première coupure, et bantime = 10m laisse revenir l’attaquant au bout de dix minutes.

Comment éviter de bannir ma propre adresse ?

Le réglage ignoreself vaut true par défaut et ne protège que les adresses de la machine elle-même. Le fichier jail.conf livré par Debian laisse ignoreip commenté, donc l’adresse fixe de l’administrateur reste exposée. Écrivez ignoreip = 127.0.0.1/8 ::1 198.51.100.0/24 dans /etc/fail2ban/jail.d/sshd.local, puis rechargez fail2ban. La commande sudo fail2ban-client set sshd addignoreip 198.51.100.7 agit sans redémarrage, mais l’effet disparaît au prochain redémarrage du service.

Faut-il garder nftables ou revenir à iptables ?

Debian 13 impose nftables dans defaults-debian.conf, Debian 12 utilisait iptables-multiport, et les deux produisent le même effet tant que la règle atterrit dans le pare-feu qui filtre réellement le trafic. Vérifiez-le après un ban, avec sudo nft list table inet f2b-table ou sudo iptables -S. Quand ufw sert d’interface, le wiki Arch conseille banaction = ufw, qui passe par la commande ufw au lieu d’ajouter une règle parallèle.

Comment allonger un ban et contrôler sa durée ?

La commande sudo fail2ban-client set sshd bantime 1h allonge la durée sans redémarrer le service, et le réglage se perd au redémarrage suivant. Écrivez bantime = 1h dans sshd.local pour le rendre permanent. La commande sudo fail2ban-client get sshd bantime répond en secondes, 3600, et fail2ban-client –str2sec 1d12h convertit une notation comme 1 jour et 12 heures.

Pourquoi Total failed reste-t-il à 0 malgré les tentatives ?

Sur Debian 13, la prison lit le journal avec journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd, et un démon SSH qui ne s’annonce pas sous cette unité ne produit aucune ligne reconnue. Comparez sudo fail2ban-client get sshd journalmatch avec le résultat de journalctl -u ssh.service. Sur Debian 12, où la prison lit un fichier, testez le filtre seul avec sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf, qui affiche les lignes reconnues et les lignes manquées.

Une machine en clés SSH uniquement a-t-elle besoin de fail2ban ?

Le filtre sshd.conf déclare publickey = nofail, donc un refus de clé pour un utilisateur connu identifie l’adresse sans incrémenter le compteur, et seules les tentatives sur un nom d’utilisateur inexistant comptent. Le wiki Arch déconseille fail2ban dans cette configuration. Pour compter tous les refus de clé, passez filter = sshd[publickey=any] dans la section [sshd] de sshd.local, en sachant que les utilisateurs légitimes qui se trompent de clé seront comptés aussi.

Combien de place et de ressources consomme fail2ban ?

Le démon est un programme Python, chaque prison active un filtre et une action, et l’état persistant tient dans /var/lib/fail2ban/fail2ban.sqlite3. Le fichier fail2ban.conf de Debian borne ce que cette base conserve, avec dbpurgeage = 1d, soit 86400 secondes d’historique de bans, et dbmaxmatches = 10, soit dix lignes de journal gardées par ticket. Les événements partent dans /var/log/fail2ban.log, où chaque ban s’écrit sur une ligne NOTICE [sshd] Ban suivie de l’adresse.

Sources : jail.conf(5), paquet fail2ban 1.0.2-2 de Debian bookworm, fail2ban-client(1), paquet 1.1.0-8 de Debian trixie, wiki Arch, page Fail2ban, rapport Debian 1070677, prison sshd sans fichier de journal, dépôt fail2ban, client et messages du socket.