Sécuriser SSH : clés, fail2ban et UFW

Pourquoi SSH est la premiere cible des attaquants

SSH est le protocole d'acces a distance le plus utilise sur les serveurs Linux. C'est aussi, de ce fait, le protocole le plus scanne et le plus attaque sur Internet. Des l'instant ou un serveur est expose sur une IP publique avec le port 22 ouvert, des bots automatises commencent a tenter des connexions. Ces attaques dites par force brute testent des milliers de couples identifiant/mot de passe par heure, en ciblant systematiquement des comptes comme root, admin, ubuntu ou deploy.

Le probleme ne vient pas de SSH en lui-meme : le protocole est solide et bien concu. Le probleme vient d'une configuration par defaut qui autorise l'authentification par mot de passe, sans limite de tentatives et souvent avec l'utilisateur root directement accessible. Sur un serveur tout juste installe et expose, quelques heures suffisent pour que les logs /var/log/auth.log soient remplis de milliers de tentatives d'authentification echouees.

La bonne nouvelle, c'est que ces attaques sont presque entierement preventibles avec trois outils complémentaires :

• Cles SSH Ed25519 : remplacent les mots de passe par une paire de cles asymetriques impossibles a deviner.
• fail2ban : detecte les tentatives repetees et bannit automatiquement les IPs offensives.
• UFW : ferme tous les ports inutiles et ne laisse ouvert que ce qui est strictement necessaire.

Ensemble, ces trois mesures forment un socle de securite SSH solide et applicable en moins d'une heure sur n'importe quel serveur Ubuntu ou Debian. Cet article vous guide etape par etape, avec toutes les commandes et configurations completes.

Les statistiques qui parlent d'elles-memes

Sur un serveur fraichement deploye avec le port 22 ouvert et aucune protection, il est courant d'observer plusieurs centaines de tentatives de connexion par heure dans les premiers jours. Ces tentatives proviennent de botnets distribues a travers le monde, qui scannent continuellement les plages d'adresses IP publiques. Meme un petit VPS a 5 euros par mois est une cible immediatement apres sa creation.

Pour constater l'ampleur du probleme sur votre propre serveur, lancez cette commande apres quelques heures d'exposition :

# Affiche les tentatives d'authentification SSH echouees
# La commande filtre les lignes "Failed password" dans les logs d'authentification
grep "Failed password" /var/log/auth.log | wc -l

# Pour voir les IPs les plus actives dans les tentatives
# La commande extrait les IPs et les comptabilise par frequence
grep "Failed password" /var/log/auth.log \
  | awk '{print $11}' \
  | sort | uniq -c | sort -rn \
  | head -20

Generer et deployer des cles Ed25519

L'authentification par cle SSH repose sur un principe asymetrique : vous generez une paire de cles (privee et publique), vous deposez la cle publique sur le serveur, et votre machine locale conserve la cle privee. Pour se connecter, votre client SSH prouve qu'il possede la cle privee correspondante, sans jamais la transmettre sur le reseau. Un mot de passe ne circule jamais.

Ed25519 est l'algorithme recommande aujourd'hui. Il est plus court, plus rapide et plus sur que RSA 2048 ou DSA. Une cle Ed25519 fait 256 bits et offre un niveau de securite equivalent a RSA 3072 bits, avec des operations de signature et de verification bien plus rapides.

Etape 1 : Generer la paire de cles sur votre machine locale

La generation s'effectue sur votre poste de travail, pas sur le serveur. La cle privee ne doit jamais etre copiee sur le serveur ni partagee.

# Genere une paire de cles Ed25519
# -t ed25519 : specifie l'algorithme
# -C "user@host" : ajoute un commentaire lisible pour identifier la cle
ssh-keygen -t ed25519 -C "mezgani@monserveur"

# Le resultat attendu :
# Generating public/private ed25519 key pair.
# Enter file in which to save the key (/home/user/.ssh/id_ed25519):
# Enter passphrase (empty for no passphrase):
# Enter same passphrase again:
# Your identification has been saved in /home/user/.ssh/id_ed25519
# Your public key has been saved in /home/user/.ssh/id_ed25519.pub

Etape 2 : Copier la cle publique sur le serveur

La commande ssh-copy-id est la maniere la plus sure et la plus simple de deposer votre cle publique sur le serveur. Elle cree automatiquement le fichier ~/.ssh/authorized_keys avec les bonnes permissions.

# Copie la cle publique sur le serveur distant
# -i : specifie le fichier de cle publique a copier
# user@server : remplacez par votre utilisateur et l'adresse IP ou nom de domaine
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@192.168.1.100

# Si le port SSH n'est pas 22, ajoutez l'option -p
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 user@192.168.1.100

Etape 3 : Verifier que l'authentification par cle fonctionne

Avant de desactiver l'authentification par mot de passe, testez la connexion par cle dans une nouvelle session. Ne fermez pas la session actuelle.

# Teste la connexion avec la cle (dans un nouveau terminal)
# -i : force l'utilisation de cette cle specifiee
# -v : mode verbeux pour voir ce qui se passe (utile pour le diagnostic)
ssh -i ~/.ssh/id_ed25519 user@192.168.1.100

# Si la connexion reussit sans saisir de mot de passe serveur
# (uniquement votre passphrase locale si vous en avez une),
# l'authentification par cle est operationnelle.

Etape 4 : Verifier les permissions sur le serveur

Les permissions du dossier .ssh et du fichier authorized_keys doivent etre tres restrictives, sinon SSH ignore les cles par securite.

# Sur le serveur : verifie et corrige les permissions si necessaire
# Le dossier .ssh doit etre accessible uniquement par le proprietaire
chmod 700 ~/.ssh

# Le fichier authorized_keys doit etre lisible uniquement par le proprietaire
chmod 600 ~/.ssh/authorized_keys

# Verification des permissions actuelles
ls -la ~/.ssh/

Gerer plusieurs machines avec ssh-agent

Si vous travaillez avec plusieurs cles ou si votre passphrase devient fastidieuse a saisir, ssh-agent garde vos cles dechiffrees en memoire pour la duree de votre session.

# Demarre l'agent SSH dans le shell courant
eval "$(ssh-agent -s)"

# Ajoute la cle a l'agent (saisie de la passphrase une seule fois)
ssh-add ~/.ssh/id_ed25519

# Verifie les cles chargees dans l'agent
ssh-add -l

Configurer sshd_config et desactiver les mots de passe

Le daemon SSH est configure via le fichier /etc/ssh/sshd_config. La configuration par defaut est fonctionnelle mais pas securisee. Il faut la durcir explicitement en desactivant les vecteurs d'attaque les plus courants.

Editer sshd_config

# Ouvre le fichier de configuration SSH avec les droits root
sudo nano /etc/ssh/sshd_config

# Ou avec vim si vous le preferez
sudo vim /etc/ssh/sshd_config

Configuration complete recommandee

Voici le bloc de configuration a appliquer. Chaque directive est commentee pour expliquer son role.

# ========================================================
# /etc/ssh/sshd_config — Configuration securisee
# ========================================================

# Port d'ecoute du serveur SSH
# Garder 22 par defaut ou changer pour un port non standard (ex: 2222)
# Un port non standard reduit le bruit des scans automatises
Port 22

# Protocole : uniquement SSHv2, la version 1 est obsolete et vulnerable
Protocol 2

# Interface reseau sur laquelle SSH ecoute
# Pour une machine avec plusieurs IPs, limitez a l'IP d'administration
# ListenAddress 0.0.0.0

# Duree maximale d'une connexion sans authentification reussie
# 30 secondes est suffisant pour une cle SSH
LoginGraceTime 30

# Desactiver la connexion directe en tant que root
# Un attaquant doit d'abord trouver un compte utilisateur valide
PermitRootLogin no

# Verifier les permissions des fichiers de l'utilisateur avant de connecter
# Empeche les connexions si ~/.ssh a des permissions trop larges
StrictModes yes

# Nombre maximal de tentatives d'authentification par connexion
# Reduire a 3 pour limiter les essais automatises
MaxAuthTries 3

# Nombre maximal de sessions SSH simultanees par connexion
MaxSessions 5

# -------- Methodes d'authentification --------

# Activer l'authentification par cle publique (obligatoire)
PubkeyAuthentication yes

# Chemin vers le fichier des cles autorisees
AuthorizedKeysFile .ssh/authorized_keys

# Desactiver l'authentification par mot de passe
# A n'activer QU'APRES avoir verifie que la cle SSH fonctionne
PasswordAuthentication no

# Desactiver l'authentification par mot de passe vide (securite supplementaire)
PermitEmptyPasswords no

# Desactiver l'authentification par challenge-response (PAM, etc.)
ChallengeResponseAuthentication no

# -------- Securite supplementaire --------

# Desactiver le transfert X11 (interface graphique via SSH)
# Inutile sur un serveur headless et vecteur d'attaque potentiel
X11Forwarding no

# Desactiver le forwarding TCP generique si non necessaire
# AllowTcpForwarding no

# Ignorer les fichiers .rhosts et /etc/hosts.equiv (protocoles anciens)
IgnoreRhosts yes

# Desactiver l'authentification RSA basee sur l'hote (obsolete)
HostbasedAuthentication no

# Afficher le message /etc/motd apres connexion
PrintMotd yes

# Afficher la date et l'heure de la derniere connexion
PrintLastLog yes

# Envoyer des keepalives pour detecter les connexions mortes
# Le serveur envoie un paquet si aucun trafic pendant 60 secondes
ClientAliveInterval 60

# Deconnecte apres 3 keepalives sans reponse (soit 3 minutes d'inactivite)
ClientAliveCountMax 3

# Desactiver la resolution DNS inverse pour accelerer les connexions
# Utile si votre DNS est lent ou absent
UseDNS no

# -------- Restriction d'acces optionnelle --------

# Limiter SSH a certains utilisateurs seulement (recommande)
# Remplacez "deployer" par votre nom d'utilisateur reel
AllowUsers deployer mezgani

Recharger le service SSH

Apres la modification, rechargez le service pour appliquer la configuration. Utilisez reload plutot que restart : cela applique la config sans tuer les sessions existantes.

# Valide la configuration avant de recharger (evite les erreurs de syntaxe)
sudo sshd -t

# Si aucune erreur : recharge le service SSH (les sessions actives restent ouvertes)
sudo systemctl reload sshd

# Verifie que le service tourne correctement apres le rechargement
sudo systemctl status sshd

Que faire si vous etes bloque dehors

Si vous perdez l'acces SSH suite a une mauvaise configuration, voici les options selon votre infrastructure :

• VPS chez un hebergeur : utilisez la console d'urgence (KVM/VNC) disponible dans votre panel de controle.
• Serveur dedie : acces IPMI ou iDRAC pour une console physique a distance.
• Serveur physique : connexion directe via clavier/ecran.

Installer et configurer fail2ban contre les brute-force

Meme avec l'authentification par mot de passe desactivee, les bots continuent de tenter des connexions SSH. Ces tentatives remplissent les logs, consomment des ressources reseau et CPU, et peuvent potentiellement exploiter des vulnerabilites futures. fail2ban surveille les logs en temps reel et bannit automatiquement les IPs qui effectuent trop de tentatives echouees.

fail2ban fonctionne en lisant les fichiers de logs, en detectant des patterns suspects (trop de tentatives d'authentification echouees), puis en ajoutant des regles au pare-feu systeme pour bloquer temporairement l'IP offensante. Le ban est automatiquement leve apres une duree configurable.

Installation de fail2ban

# Met a jour la liste des paquets disponibles
sudo apt update

# Installe fail2ban (disponible dans les depots officiels Debian/Ubuntu)
sudo apt install fail2ban -y

# Verifie que le service est actif apres installation
sudo systemctl status fail2ban

# Active le demarrage automatique au boot du serveur
sudo systemctl enable fail2ban

Configuration : jail.local

Ne modifiez jamais directement /etc/fail2ban/jail.conf. Ce fichier est ecrase a chaque mise a jour de fail2ban. Creez plutot un fichier jail.local qui surcharge uniquement les parametres que vous souhaitez modifier.

# Cree le fichier de configuration local (n'ecrase pas jail.conf)
sudo nano /etc/fail2ban/jail.local

Voici la configuration complete a coller dans jail.local :

# ========================================================
# /etc/fail2ban/jail.local — Configuration fail2ban SSH
# ========================================================

[DEFAULT]
# Adresse email pour recevoir les notifications de ban (optionnel)
# destemail = admin@mondomaine.com

# IPs jamais bannies, meme en cas de tentatives multiples
# Incluez toujours votre IP fixe personnelle pour eviter un auto-bannissement
ignoreip = 127.0.0.1/8 ::1

# Duree d'un ban en secondes
# 3600 = 1 heure ; -1 = ban permanent (a eviter sur les faux positifs)
bantime = 3600

# Fenetre de temps pour comptabiliser les tentatives
# 600 = les tentatives sont comptees sur les 10 dernieres minutes
findtime = 600

# Nombre maximal de tentatives echouees avant ban
# Apres 5 echecs en 10 minutes, l'IP est bannie pour 1 heure
maxretry = 5

# Backend de detection des logs : auto detecte le meilleur disponible
# "systemd" si journald est utilise, "polling" sinon
backend = auto

# -------- Configuration specifique SSH --------

[sshd]
# Active la jail SSH
enabled = true

# Nom du port SSH (ou numero si vous avez change le port par defaut)
# Si vous avez change le port dans sshd_config, adaptez cette valeur
port = ssh

# Filtre applique (pre-defini dans /etc/fail2ban/filter.d/sshd.conf)
filter = sshd

# Fichier de log a surveiller
logpath = /var/log/auth.log

# Surcharge le maxretry global pour SSH (plus strict)
maxretry = 3

# Surcharge le bantime global pour SSH (ban plus long : 2 heures)
bantime = 7200

# Mode de detection plus agressif : inclut les tentatives de connexion invalides
mode = aggressive

Recharger et verifier fail2ban

# Recharge fail2ban pour appliquer la nouvelle configuration
sudo systemctl reload fail2ban

# Verifie l'etat general de fail2ban
sudo fail2ban-client status

# Verifie specifiquement la jail SSH
# Affiche : nombre d'IPs actuellement bannies, nombre de tentatives detectees
sudo fail2ban-client status sshd

La sortie de la derniere commande ressemble a ceci :

# Exemple de sortie attendue de fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 2
|  |- Total failed: 47
|  `- File list: /var/log/auth.log
`- Actions
   |- Currently banned: 1
   |- Total banned: 8
   `- Banned IP list: 185.220.101.45

Gestion manuelle des bans

# Debannit manuellement une IP (utile si vous vous etes banni vous-meme)
sudo fail2ban-client set sshd unbanip 192.168.1.50

# Bannit manuellement une IP suspecte
sudo fail2ban-client set sshd banip 185.220.101.45

# Consulte les logs de fail2ban pour le diagnostic
sudo tail -f /var/log/fail2ban.log

UFW : pare-feu minimal pour n'exposer que le necessaire

UFW (Uncomplicated Firewall) est une interface simplifiee pour iptables, le pare-feu noyau Linux. Son but est de permettre a un administrateur systeme de definir rapidement des regles reseau claires sans maitriser la syntaxe complexe d'iptables. Sur Ubuntu et Debian, UFW est disponible par defaut et s'integre naturellement avec fail2ban.

Le principe de configuration UFW est simple : par defaut, refuser tout le trafic entrant, puis autoriser explicitement uniquement ce qui est necessaire. Cela suit le principe de moindre privilege : un port non explicitement ouvert ne peut pas etre attaque.

Installation et verification

# UFW est pre-installe sur Ubuntu. Sur Debian, installez-le si besoin :
sudo apt install ufw -y

# Verifie l'etat actuel d'UFW (generalement "inactive" par defaut)
sudo ufw status verbose

Configuration de base avant activation

# Definit la politique par defaut : refuse tout trafic entrant
sudo ufw default deny incoming

# Definit la politique par defaut : autorise tout trafic sortant
sudo ufw default allow outgoing

# Autorise les connexions SSH (port 22)
# Remplacez 22 par votre port si vous avez change le port dans sshd_config
sudo ufw allow 22/tcp

# Si votre serveur heberge un site web, autorisez HTTP et HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Si vous avez une base de donnees a exposer sur un reseau prive uniquement
# Remplacez 10.0.0.0/24 par votre plage IP privee
# sudo ufw allow from 10.0.0.0/24 to any port 5432

Activer UFW et verifier les regles

# Active le pare-feu (demande une confirmation)
# ATTENTION : assurez-vous que SSH est bien autorise avant de valider
sudo ufw enable

# Affiche toutes les regles actives avec le statut detaille
sudo ufw status verbose

# Affiche les regles numerotees (utile pour les supprimer)
sudo ufw status numbered

La sortie de sudo ufw status verbose apres configuration ressemble a ceci :

# Exemple de sortie attendue apres configuration
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
22/tcp (v6)                ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
443/tcp (v6)               ALLOW IN    Anywhere (v6)

Gestion courante des regles UFW

# Supprimer une regle par son numero (utiliser "ufw status numbered" pour voir les numeros)
sudo ufw delete 3

# Supprimer une regle par sa description
sudo ufw delete allow 80/tcp

# Recharger UFW apres modification des regles
sudo ufw reload

# Desactiver UFW temporairement (utile pour le diagnostic reseau)
sudo ufw disable

# Reinitialiser toutes les regles (remet UFW a son etat initial)
# ATTENTION : operation destructrice, a utiliser avec precaution
sudo ufw reset

Integration fail2ban et UFW

fail2ban utilise par defaut iptables pour bannir les IPs. Sur un systeme avec UFW actif, il est preferable de configurer fail2ban pour utiliser UFW comme backend. Cela garantit que les bans sont visibles dans les regles UFW.

# Cree un fichier de configuration pour le backend UFW de fail2ban
sudo nano /etc/fail2ban/action.d/ufw.conf

# /etc/fail2ban/action.d/ufw.conf
# Permet a fail2ban d'utiliser UFW pour bannir les IPs

[Definition]
# Commande executee pour bannir une IP
actionban = ufw insert 1 deny from <ip> to any

# Commande executee pour debannir une IP
actionunban = ufw delete deny from <ip> to any

# Modifie jail.local pour utiliser le backend UFW
# Dans la section [sshd], ajoutez ou modifiez la ligne action :
# action = ufw

# Puis rechargez fail2ban
sudo systemctl reload fail2ban

Tester et verifier le hardening complet

Apres la configuration de ces trois couches de securite, il est essentiel de verifier que tout fonctionne correctement. Un hardening mal verifie peut donner une fausse impression de securite ou, au contraire, bloquer des acces legitimes.

Test 1 : Verifier la connexion SSH par cle

# Depuis votre machine locale, testez la connexion avec cle
ssh -i ~/.ssh/id_ed25519 user@votre-serveur

# Verifiez explicitement que la connexion par mot de passe est refusee
# L'option -o interdit l'utilisation des cles, pour forcer la tentative par mot de passe
ssh -o PubkeyAuthentication=no user@votre-serveur
# Resultat attendu : "Permission denied (publickey)."

Test 2 : Verifier que root ne peut plus se connecter

# Tentative de connexion root directe (doit echouer)
ssh root@votre-serveur
# Resultat attendu : "Permission denied (publickey)."

Test 3 : Verifier les logs SSH en temps reel

# Surveille les evenements SSH en direct avec journalctl
# -f : suit les nouveaux logs en temps reel (equivalent de tail -f)
# -u ssh : filtre uniquement les logs du service SSH
journalctl -u sshd -f

# Sur les systemes utilisant syslog classique
tail -f /var/log/auth.log | grep ssh

Test 4 : Verifier fail2ban en simulant une attaque

# Depuis une machine tierce (ou en testant avec des identifiants errones),
# tentez plusieurs connexions avec un mauvais mot de passe
# Apres le nombre maxretry defini, verifiez que l'IP est bannie

# Sur le serveur, consulte l'etat de la jail SSH
sudo fail2ban-client status sshd

# Consulte les derniers evenements de fail2ban
sudo journalctl -u fail2ban -n 50

# Verifie les regles iptables (bans actifs)
sudo iptables -L f2b-sshd -n --line-numbers

Test 5 : Verifier les regles UFW

# Affiche toutes les regles actives
sudo ufw status verbose

# Teste depuis une machine externe que seuls les ports autorises repondent
# L'outil nmap permet de scanner les ports ouverts
nmap -p 22,80,443,3306 votre-serveur

# Resultat attendu : seuls les ports explicitement autorises dans UFW apparaissent
# PORT     STATE  SERVICE
# 22/tcp   open   ssh
# 80/tcp   open   http
# 443/tcp  open   https
# 3306/tcp closed mysql

Analyser un rapport de securite avec ssh-audit

ssh-audit est un outil qui analyse la configuration SSH d'un serveur et signale les algorithmes faibles ou les mauvaises pratiques.

# Installation de ssh-audit
pip3 install ssh-audit

# Lance l'audit SSH sur votre serveur
ssh-audit votre-serveur

# Version plus courte sans installer (via Docker)
docker run -it --rm positronsecurity/ssh-audit votre-serveur

Checklist de verification finale

Utilisez cette checklist pour valider que votre hardening SSH est complet et operationnel. Chaque point peut etre verifie avec les commandes decrites dans les sections precedentes.

Cles SSH

• Cle Ed25519 generee avec une passphrase robuste.
• Cle publique deposee sur le serveur via ssh-copy-id.
• Connexion par cle testee et operationnelle depuis un nouveau terminal.
• Permissions ~/.ssh = 700 et ~/.ssh/authorized_keys = 600 sur le serveur.

Configuration sshd_config

• PermitRootLogin no — connexion root desactivee.
• PasswordAuthentication no — authentification par mot de passe desactivee.
• MaxAuthTries 3 — tentatives limitees a 3 par connexion.
• PubkeyAuthentication yes — authentification par cle activee.
• sshd -t passe sans erreur — syntaxe valide.
• systemctl status sshd montre "active (running)".

fail2ban

• fail2ban-client status liste la jail sshd comme active.
• fail2ban-client status sshd montre le bon logpath et le bon maxretry.
• Votre IP fixe est dans ignoreip si vous avez une IP statique.
• Le service fail2ban demarres automatiquement au boot (systemctl is-enabled fail2ban).

UFW

• ufw status affiche "active".
• Politique par defaut : deny incoming, allow outgoing.
• Seuls les ports necessaires sont ouverts (22, 80, 443 au minimum).
• Test depuis l'exterieur confirme que les ports fermes ne repondent pas.