SSH est la porte d'entrée de votre serveur. Les bots automatisés commencent a marteler le port 22 quelques minutes après la mise en ligne d'un VPS. Ce guide passe en revue chaque modification de sshd_config nécessaire pour verrouiller SSH sur Debian 12 (OpenSSH 9.2) et Ubuntu 24.04 (OpenSSH 9.6), avec une étape de vérification après chaque changement pour confirmer que tout fonctionne.

Prérequis

Vous avez besoin de :

Un VPS sous Debian 12 ou Ubuntu 24.04 (neuf ou existant)
Un utilisateur non-root avec accès sudo
Un second terminal ou une seconde session SSH ouverte sur le serveur (indispensable pour tester les changements sans vous bloquér)

Ce guide fait partie de la série Sécurité Linux VPS : menaces, couches de défense et guide de durcissement. Après avoir durci SSH ici, mettez en place une protection automatique contre le brute-force avec Installer et configurer Fail2Ban sur un VPS Linux.

Comment générer une clé SSH sécurisée pour mon VPS ?

Générez une clé Ed25519 sur votre machine locale (votre laptop ou poste de travail, pas le serveur). Ed25519 produit une clé de 256 bits offrant 128 bits de sécurité, équivalent a RSA-3072, tout en étant plus rapide a générer et a vérifier. Les signatures sont déterministes : elles ne dépendent pas d'un générateur de nombres aléatoires au moment de la signature. Cela élimine toute une classe d'attaques d'implementation qui affectent RSA.

ssh-keygen -t ed25519 -C "yourname@yourmachine"

Vous verrez une sortie de ce type :

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/yourname/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/yourname/.ssh/id_ed25519
Your public key has been saved in /home/yourname/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:xR5xGk3TOs4mEfW8sBv7g7LkE2PLxYae2TqfGxpfM3Q yourname@yourmachine

Définissez une passphrase. Si quelqu'un vole votre fichier de clé privée, la passphrase est le seul rempart entre cette personne et vos serveurs.

Ed25519 vs RSA : quelle clé choisir ?

	Ed25519	RSA-4096
Taille de clé	256 bits	4096 bits
Force de sécurité	~128 bits	~140 bits
Génération de clé	Instantanée	1-5 secondes
Vérification de signature	Plus rapide	Plus lente
Taille du fichier de clé privée	464 octets	~3.3 Ko
Dépendance au RNG à la signature	Non (déterministe)	Oui
Compatibilité	OpenSSH 6.5+ (2014)	Universelle

Utilisez Ed25519 sauf si vous devez vous connectér à des systèmes utilisant OpenSSH plus ancien que 6.5, ce qui est rare en 2026.

Copier votre clé publique sur le serveur

Depuis votre machine locale :

ssh-copy-id -i ~/.ssh/id_ed25519.pub youruser@your-server-ip

Si ssh-copy-id n'est pas disponible (certaines configurations macOS), copiez manuellement :

cat ~/.ssh/id_ed25519.pub | ssh youruser@your-server-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Connectez-vous depuis un nouveau terminal avec l'authentification par clé :

ssh -i ~/.ssh/id_ed25519 youruser@your-server-ip

Si vous obtenez un shell sans entrer le mot de passe du serveur (seulement la passphrase de votre clé), l'authentification par clé fonctionne.

Comprendre la directive Include

Avant de modifier sshd_config, sachez ceci : Debian 12 et Ubuntu 24.04 incluent Include /etc/ssh/sshd_config.d/*.conf en haut de /etc/ssh/sshd_config. OpenSSH utilise la première valeur trouvée pour la plupart des directives. Tout fichier .conf dans sshd_config.d/ à la priorité sur les paramètres du fichier principal.

Vérifiez ce qui est déjà configuré :

ls -la /etc/ssh/sshd_config.d/

Sur Ubuntu 24.04, vous trouverez généralement 50-cloud-init.conf si cloud-init est actif. Lisez les fichiers existants avant de faire des modifications :

cat /etc/ssh/sshd_config.d/*.conf 2>/dev/null

Nous allons placer notre durcissement dans un seul fichier chargé en premier :

sudo touch /etc/ssh/sshd_config.d/00-hardening.conf
sudo chmod 600 /etc/ssh/sshd_config.d/00-hardening.conf

Le préfixe 00- garantit que notre fichier est lu avant les autres fragments de configuration. Le chmod 600 restreint l'accès en lecture à root uniquement, puisque ce fichier contrôle qui peut se connectér.

Toutes les modifications sshd_config de ce guide vont dans /etc/ssh/sshd_config.d/00-hardening.conf sauf indication contraire.

Comment désactiver l'authentification SSH par mot de passe ?

Désactiver l'authentification par mot de passe force la connexion par clé uniquement. Les attaques par brute-force deviennent inutiles puisqu'il n'y a pas de mot de passe a deviner.

Ouvrez le fichier de durcissement :

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Ajoutez :

PasswordAuthentication no
KbdInteractiveAuthentication no

KbdInteractiveAuthentication remplace le déprécié ChallengeResponseAuthentication dans OpenSSH 9.x. Désactivez les deux pour fermer tous les chemins de connexion par mot de passe.

Avant de redémarrer sshd, validez toujours la configuration et gardez votre session en cours ouverte.

sudo sshd -t

Si aucune sortie n'apparaît, la configuration est valide. Les erreurs s'affichent dans le terminal.

Redémarrez sshd :

sudo systemctl restart sshd

Vérification depuis un second terminal (ne fermez pas votre session en cours) :

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no youruser@your-server-ip

Vous devriez voir :

youruser@your-server-ip: Permission denied (publickey).

Cela confirme que l'authentification par mot de passe est désactivée. Notez que le message indique (publickey) comme seule méthode autorisée. C'est exactement ce que nous voulons.

Confirmez maintenant que la connexion par clé fonctionne toujours depuis ce même second terminal :

ssh youruser@your-server-ip

Si les deux tests passent, l'authentification par mot de passe est désactivée et la connexion par clé fonctionne. Si la connexion par clé échoue, retournez dans votre première session toujours ouverte et corrigez la configuration avant de vous retrouver bloqué.

Comment désactiver la connexion SSH root sur Ubuntu et Debian ?

La connexion root directe via SSH doit être désactivée. Même avec l'authentification par clé uniquement, une clé compromise pour root donne un accès total au système sans trace d'audit de qui s'est connecté. Utilisez un utilisateur standard avec sudo à la place.

Ajoutez a /etc/ssh/sshd_config.d/00-hardening.conf :

PermitRootLogin no

Validez et redémarrez :

sudo sshd -t && sudo systemctl restart sshd

Vérification depuis un second terminal :

ssh root@your-server-ip

Sortie attendue :

root@your-server-ip: Permission denied (publickey).

Vérifiez que le paramètre est pris en compte avec sshd -T (le T majuscule affiche la configuration active) :

sudo sshd -T | grep -i permitrootlogin

permitrootlogin no

Comment restreindre l'accès SSH à des utilisateurs spécifiques ?

AllowUsers et AllowGroups limitent la connexion SSH à une liste explicite. Toute personne absente de la liste est rejetée, même si elle possède des clés valides. C'est un filet de sécurité contre le déploiement accidentel de clés ou les nouveaux utilisateurs créés par des paquets.

Ajoutez a /etc/ssh/sshd_config.d/00-hardening.conf :

AllowUsers youruser

Remplacez youruser par votre nom d'utilisateur réel. Pour autoriser plusieurs utilisateurs :

AllowUsers youruser deployer

Autre option : l'accès par groupe (preferable pour les équipes) :

sudo groupadd sshusers
sudo usermod -aG sshusers youruser

Puis dans la configuration :

AllowGroups sshusers

Ordre de traitement

OpenSSH évalue l'accès dans cet ordre : DenyUsers, AllowUsers, DenyGroups, AllowGroups. Un refus à n'importe quelle étape bloqué l'utilisateur. Si vous utilisez AllowUsers, seuls les utilisateurs listés peuvent se connectér. Si vous utilisez AllowGroups, seuls les membres des groupes listés peuvent se connectér. Vous pouvez combiner les deux, mais AllowUsers est évalue en premier.

Validez et redémarrez :

sudo sshd -t && sudo systemctl restart sshd

Vérification depuis un second terminal :

ssh youruser@your-server-ip

Confirmez que votre utilisateur peut toujours se connectér. Puis vérifiez qu'un utilisateur non liste serait rejete :

sudo sshd -T | grep -i allowusers

allowusers youruser

Quelles limites de session SSH configurér ?

Ces directives limitent les tentatives d'authentification, les délais de connexion et les connexions non authentifiées. Elles ralentissent les attaques par brute-force et nettoient les sessions inactives.

Ajoutez a /etc/ssh/sshd_config.d/00-hardening.conf :

MaxAuthTries 3
LoginGraceTime 20
MaxStartups 10:30:60
MaxSessions 3
ClientAliveInterval 300
ClientAliveCountMax 2

Voici ce que fait chaque paramètre :

Directive	Valeur	Effet
MaxAuthTries	3	Déconnecté après 3 tentatives d'authentification échouees par connexion
LoginGraceTime	20	Accorde 20 secondes pour s'authentifiér avant déconnexion
MaxStartups	10:30:60	Au-dela de 10 connexions non authentifiées, rejette aleatoirement 30 % des nouvelles. A 60, rejette toutes les nouvelles connexions.
MaxSessions	3	Maximum 3 sessions multiplexées par connexion
ClientAliveInterval	300	Envoie un paquet keepalive toutes les 300 secondes (5 minutes)
ClientAliveCountMax	2	Déconnecté après 2 réponses keepalive manquées

Calcul du ClientAliveInterval : le délai d'inactivité réel est ClientAliveInterval x ClientAliveCountMax. Avec ces valeurs : 300 x 2 = 600 secondes = 10 minutes. Une session inactive se déconnecté après 10 minutes sans réponse.

Validez et redémarrez :

sudo sshd -t && sudo systemctl restart sshd

sudo sshd -T | grep -E "maxauthtries|logingracetime|maxstartups|maxsessions|clientaliveinterval|clientalivecountmax"

maxauthtries 3
logingracetime 20
maxstartups 10:30:60
maxsessions 3
clientaliveinterval 300
clientalivecountmax 2

Désactiver les fonctionnalités de transfert inutiles

Les fonctionnalités de transfert (forwarding) étendent la surface d'attaque de SSH. Désactivez tout ce que vous n'utilisez pas activement.

Ajoutez a /etc/ssh/sshd_config.d/00-hardening.conf :

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

Validez et redémarrez :

sudo sshd -t && sudo systemctl restart sshd

sudo sshd -T | grep -E "allowagentforwarding|allowtcpforwarding|x11forwarding|permittunnel"

allowagentforwarding no
allowtcpforwarding no
x11forwarding no
permittunnel no

Pourquoi désactiver le transfert d'agent SSH ?

Le transfert d'agent (agent forwarding) permet à un serveur distant d'utiliser vos clés SSH locales pour s'authentifiér sur d'autres serveurs. Ça semble pratique pour naviguer entre machines. Le problème : toute personne ayant les droits root sur ce serveur distant peut détourner votre socket d'agent et utiliser vos clés.

Le scénario d'attaque :

Vous activez le transfert d'agent et vous connectéz en SSH au Serveur A.
OpenSSH crée un socket a /tmp/ssh-XXXX/agent.YYYY sur le Serveur A.
Un attaquant avec les droits root sur le Serveur A lit la variable d'environnement SSH_AUTH_SOCK de votre session.
L'attaquant se connecté à ce socket : SSH_AUTH_SOCK=/tmp/ssh-XXXX/agent.YYYY ssh user@server-b.
Le Serveur B voit une authentification valide avec votre clé. L'attaquant est entre.

L'attaquant n'a jamais touche votre clé privée. Il avait juste besoin des droits root sur le serveur intermédiaire pendant que votre session etait active.

Utilisez ProxyJump à la place (section suivante). Il offre le même accès multi-sauts sans exposer votre socket d'agent a aucun serveur intermédiaire.

Comment configurér SSH ProxyJump pour l'accès via un bastion ?

ProxyJump (saut par proxy) achemine votre connexion SSH à travers un serveur de rebond (bastion) sans transfert d'agent. Vos clés ne quittent jamais votre machine locale. La connexion est chiffrée de bout en bout : le bastion ne voit que du trafic chiffré qui transite.

Utilisation en ligne de commande

ssh -J jumpuser@bastion.example.com targetuser@10.0.1.50

Le flag -J indique a SSH de se connectér d'abord au bastion, puis de tunneliser vers la cible. Vous pouvez enchainer plusieurs sauts avec des virgules :

ssh -J jump1@bastion1,jump2@bastion2 targetuser@10.0.1.50

Configuration du fichier SSH config

Pour une utilisation régulière, ajoutez des entrées a ~/.ssh/config sur votre machine locale :

Host bastion
    HostName bastion.example.com
    User jumpuser
    IdentityFile ~/.ssh/id_ed25519

Host internal-app
    HostName 10.0.1.50
    User appuser
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Host internal-db
    HostName 10.0.2.100
    User dbadmin
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Connectez-vous maintenant aux serveurs internes directement :

ssh internal-app

SSH gere le saut par le bastion automatiquement.

Durcir le serveur bastion

Sur le bastion, restreignez ce que les utilisateurs de saut peuvent faire. Ajoutez au sshd_config du bastion :

Match User jumpuser
    PermitTTY no
    X11Forwarding no
    PermitTunnel no
    ForceCommand /usr/sbin/nologin
    AllowTcpForwarding yes

Cela autorise le transfert TCP (nécessaire pour ProxyJump) mais empêche l'utilisateur de saut d'obtenir un shell, d'exécuter des commandes ou d'utiliser X11. Si le bastion est compromis, l'attaquant obtient un compte de transfert uniquement, sans accès shell.

Quels chiffrements et algorithmes d'échange de clés SSH sont surs ?

Les listés de chiffrement par défaut d'OpenSSH incluent des algorithmes conserves pour la rétrocompatibilité. Supprimer les plus faibles réduit votre surface d'attaque. Ces recommandations ciblent OpenSSH 9.2+ (Debian 12) et 9.6+ (Ubuntu 24.04).

D'abord, régénérez les clés d'hote en Ed25519 uniquement et supprimez les clés DSA ou ECDSA :

sudo rm -f /etc/ssh/ssh_host_*key*
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""

Nous conservons une clé d'hote RSA pour les clients qui ne supportent pas Ed25519 (rare, mais ça évite les blocages).

Ensuite, supprimez les moduli Diffie-Hellman faibles (groupes inférieurs à 3072 bits) :

sudo awk '$5 >= 3071' /etc/ssh/moduli > /tmp/moduli.safe
sudo mv /tmp/moduli.safe /etc/ssh/moduli
sudo chown root:root /etc/ssh/moduli
sudo chmod 644 /etc/ssh/moduli

Ajoutez a /etc/ssh/sshd_config.d/00-hardening.conf :

HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Categorie	Algorithmes	Notes
Échange de clés	sntrup761x25519, curve25519, DH group16/18	sntrup761 est un hybride post-quantique. curve25519 est le standard actuel.
Chiffrements	ChaCha20-Poly1305, AES-256-GCM, AES-128-GCM, AES-CTR	ChaCha20 en premier : plus rapide en logiciel sans AES-NI. GCM est du chiffrement authentifié.
MACs	HMAC-SHA2 ETM, UMAC-128 ETM	ETM (Encrypt-then-MAC) uniquement. Les modes non-ETM sont plus faibles.
Clés d'hote	Ed25519, RSA (SHA-2)	Pas de DSA (casse). Pas d'ECDSA (doutes sur les courbes NIST).

Validez et redémarrez :

sudo sshd -t && sudo systemctl restart sshd

Vérifiez depuis un second terminal que vous pouvez toujours vous connectér. Si votre client SSH ne supporte aucun de ces algorithmes (client tres ancien), vous obtiendrez une erreur « no matching cipher ». Dans ce cas, mettez à jour votre client ou rajoutez temporairement l'algorithme nécessaire.

Configurer une bannière de connexion

Masquez les informations de version SSH et affichez une bannière d'avertissement légal :

sudo nano /etc/ssh/banner.txt

Authorized access only. All activity is monitored and logged.

Restez bref. Les bannières longues contenant des informations système aident les attaquants a identifier votre OS.

Ajoutez a /etc/ssh/sshd_config.d/00-hardening.conf :

Banner /etc/ssh/banner.txt
DebianBanner no

DebianBanner no supprime la chaîne de version Debian/Ubuntu de la bannière du protocole SSH. La divulgation de version aide les attaquants a cibler les vulnérabilités connues pour votre build spécifique d'OpenSSH.

Validez et redémarrez :

sudo sshd -t && sudo systemctl restart sshd

depuis votre machine locale :

ssh -v youruser@your-server-ip 2>&1 | grep "banner"

Référence complète : sshd_config durci

Voici le fichier /etc/ssh/sshd_config.d/00-hardening.conf complet avec tous les paramètres de ce guide :

# Authentication
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey

# Access control
AllowUsers youruser

# Session limits
MaxAuthTries 3
LoginGraceTime 20
MaxStartups 10:30:60
MaxSessions 3
ClientAliveInterval 300
ClientAliveCountMax 2

# Forwarding restrictions
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

# Cryptography
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

# Banner
Banner /etc/ssh/banner.txt
DebianBanner no

# Logging
LogLevel VERBOSE

LogLevel VERBOSE enregistre des détails supplémentaires, y compris les empreintes de clés utilisees pour l'authentification. Utile pour auditer qui s'est connecté avec quelle clé.

Après avoir écrit ce fichier, validez toujours avant de redémarrer :

sudo sshd -t && sudo systemctl restart sshd

Contrôlez la configuration effective complète :

sudo sshd -T

Cela affiche chaque paramètre actif, y compris les valeurs par défaut. Filtrez avec grep pour vérifier des valeurs spécifiques :

sudo sshd -T | grep -E "permitrootlogin|passwordauthentication|allowusers"

permitrootlogin no
passwordauthentication no
allowusers youruser

Comment vérifier mon durcissement SSH avec ssh-audit ?

ssh-audit analyse votre serveur et évalue chaque algorithme comme bon, avertissement ou échec. Lancez-le après le durcissement pour confirmer que tout passe.

Installez-le sur votre machine locale ou un serveur separe (pas la cible) :

pip3 install ssh-audit

Ou avec apt sur Debian/Ubuntu :

sudo apt update && sudo apt install -y ssh-audit

Analysez votre serveur :

ssh-audit your-server-ip

Avec le durcissement de ce guide, vous ne devriez voir aucune entrée [fail]. La sortie commence par la version OpenSSH détectée, puis liste chaque catégorie d'algorithmes :

# general
(gen) banner: SSH-2.0-OpenSSH_9.6
(gen) software: OpenSSH 9.6
(gen) compression: enabled (zlib@openssh.com)

# key exchange algorithms
(kex) sntrup761x25519-sha512@openssh.com  -- [info] available since OpenSSH 8.5
(kex) curve25519-sha256                   -- [info] available since OpenSSH 7.4
...

# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com       -- [info] available since OpenSSH 6.5
(enc) aes256-gcm@openssh.com              -- [info] available since OpenSSH 6.2
...

Si vous voyez des entrées [fail], vérifiez que votre 00-hardening.conf est bien chargé (rappelez-vous l'ordre de Include) et qu'aucun autre fichier dans sshd_config.d/ ne surchargé vos paramètres.

ssh-audit dispose aussi de guides de durcissement intégrés :

ssh-audit --list-hardening-guides

Dépannage

Je suis bloqué dehors

Si vous ne pouvez plus vous connectér en SSH après un changement de configuration :

Utilisez la console web de votre fournisseur VPS (KVM/VNC) pour vous connectér directement.
Corrigez /etc/ssh/sshd_config.d/00-hardening.conf.
Lancez sshd -t pour valider.
Redémarrez : systemctl restart sshd.

C'est pour cette raison que nous insistons : ne fermez jamais votre session active avant de tester depuis un second terminal.

sshd refuse de démarrer après un changement de configuration

sudo sshd -t

Cela affiche la ligne et le fichier exacts contenant l'erreur. Problèmes fréquents :

Faute de frappe dans un nom d'algorithme (pas d'espaces autorisés dans les listés séparées par des virgules)
Directives dupliquées dans plusieurs fichiers (vérifiez sshd_config.d/ et le sshd_config principal)
AllowUsers avec un nom d'utilisateur inexistant (sshd demarre, mais personne ne peut se connectér)

Connexion refusée après le durcissement des chiffrements

Votre client SSH local ne supporte peut-être pas les chiffrements configurés. Vérifiez les chiffrements supportés par votre client :

ssh -Q cipher

Comparez avec la liste du serveur. Ajoutez le chiffrement nécessaire à votre client, ou mettez votre client à jour.

Consulter les logs SSH

sudo journalctl -u sshd -f

Observez les logs en temps réel pendant une tentative de connexion depuis un autre terminal. Les échecs d'authentification, erreurs de configuration et coupures de connexion apparaissent ici.

Vérifier quel fichier de configuration définit une directive

sudo sshd -T | grep passwordauthentication

Si la valeur ne correspond pas à ce que vous avez défini, un autre fichier dans sshd_config.d/ surchargé le votre. Les fichiers sont chargés par ordre alphabétique. Notre 00-hardening.conf est chargé en premier, donc il gagne pour la plupart des directives. Mais vérifiez si cloud-init ou d'autres outils de gestion ecrivent leurs propres configurations.

Liste de vérification

Passez en revue chaque point après avoir terminé toutes les étapes de durcissement :

Authentification par mot de passe désactivée : ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no youruser@server retourne « Permission denied »
Connexion root désactivée : ssh root@server retourne « Permission denied »
Authentification par clé fonctionnelle : ssh youruser@server donne un shell
AllowUsers actif : sudo sshd -T | grep allowusers affiche votre utilisateur
Limites de session définies : sudo sshd -T | grep maxauthtries affiche 3
Transfert désactivé : sudo sshd -T | grep allowagentforwarding affiche no
Chiffrements forts uniquement : ssh-audit server-ip n'affiche aucune entrée [fail]
Logs fonctionnels : sudo journalctl -u sshd -n 20 affiche les entrées d'authentification récentes

Après avoir durci SSH, configuréz Installer et configurer Fail2Ban sur un VPS Linux pour bannir automatiquement les adresses IP en échec d'authentification. Pour le contrôle d'accès SSH au niveau réseau, consultez Comment configurer un pare-feu Linux avec UFW et nftables sur un VPS.