Sécuriser un VPS Linux en Production : SSH, UFW et Fail2ban

1. Supprimer les vecteurs d’authentification vulnérables

Dès qu’un VPS Debian ou Ubuntu fraîchement installé reçoit une IP publique, il commence à recevoir des tentatives de connexion SSH en quelques minutes, pas en quelques jours. Des botnets automatisés scannent en permanence l’ensemble de l’espace IPv4, et l’authentification par mot de passe sur le port 22 reste le vecteur de compromission le plus courant pour les serveurs de production. La solution n’est pas une politique de mot de passe plus stricte, c’est de retirer complètement le mot de passe du chemin d’authentification. Générez une paire de clés ed25519 sur votre poste de travail, copiez la clé publique dans authorized_keys du serveur, et désactivez ensuite l’authentification par mot de passe dans sshd_config.

Respectez l’ordre des opérations, sinon vous risquez de vous retrouver bloqué dehors. Vérifiez d’abord que vous pouvez vous connecter avec la clé depuis un second terminal, en gardant la session root/mot de passe originale ouverte. Ce n’est qu’après cette vérification que vous éditez /etc/ssh/sshd_config pour définir PasswordAuthentication no et PermitRootLogin prohibit-password (ou no, si vous disposez déjà d’un utilisateur sudo dédié). Redémarrez sshd avec un reload plutôt qu’un stop complet, pour qu’une connexion existante survive à une éventuelle erreur de configuration.

Une seconde mesure, peu coûteuse, consiste à déplacer SSH hors du port 22. Cela n’arrêtera pas un attaquant ciblé, mais cela élimine plus de 95 % du bruit des scans automatisés, ce qui garde vos logs d’authentification lisibles et réduit la charge de travail de Fail2ban par la suite. Combinez cela avec la désactivation pure et simple de la connexion root et la création d’un utilisateur de déploiement dédié avec privilèges sudo, afin que chaque action soit attribuable à un compte nommé plutôt qu’à une session root partagée.

2. Créer un utilisateur de déploiement à privilèges limités

Faire tourner votre application, votre pipeline CI et vos sessions interactives en root est le moyen le plus rapide de transformer une simple erreur, une clé de déploiement fuitée ou une vulnérabilité de dépendance en compromission totale du serveur. Créez un utilisateur non-root dédié avec un accès sudo limité à ce dont il a réellement besoin, et utilisez ce compte pour chaque session SSH, chaque déploiement GitHub Actions et chaque invocation de docker compose à partir de maintenant.

L’accès sudo ne doit pas signifier root illimité. Pour un compte de déploiement dont le rôle se limite à récupérer le code, lancer docker compose et redémarrer des services, accordez un accès NOPASSWD restreint à une liste précise de commandes via un fichier dédié dans /etc/sudoers.d, plutôt que d’ajouter l’utilisateur au groupe sudo dans son intégralité. Cela permet aux pipelines CI automatisés de fonctionner sans invite de mot de passe interactive, tout en limitant le rayon d’impact si la clé de déploiement venait à fuiter.