Sécuriser un nouveau VPS Linux en 10 minutes : clés SSH, pare-feu, Fail2ban, mises à jour auto

Un nouveau VPS doté d'une IP publique reçoit des tentatives de connexion automatisées quelques minutes seulement après sa mise en ligne. Cette checklist montre comment sécuriser un nouveau VPS Linux en une dizaine de minutes : mettre à jour les paquets, créer un utilisateur sudo, passer à l'authentification par clé SSH, désactiver la connexion root par mot de passe, n'ouvrir que les ports nécessaires dans le pare-feu, bloquer les attaques par force brute avec fail2ban et activer les mises à jour de sécurité automatiques. Les commandes sont fournies pour Debian/Ubuntu et pour CentOS/Rocky Linux/AlmaLinux, et s'appliquent à tout serveur cloud JUSTG à Johannesburg, Moscou, Tokyo ou Séoul.

Étape 1 : Mettre à jour tous les paquets

Connectez-vous en root (voir notre guide de connexion SSH) et installez les derniers correctifs de sécurité avant toute autre chose :

# Debian / Ubuntu
apt update && apt upgrade -y

# CentOS / Rocky / AlmaLinux
dnf upgrade -y

# reboot if a new kernel was installed
reboot

Étape 2 : Créer un nouvel utilisateur sudo

Travailler en root en permanence rend chaque faute de frappe dangereuse, et root est le premier identifiant testé par les attaquants. Créez un utilisateur normal (ici deploy) disposant des droits sudo. Sous Debian/Ubuntu, le groupe d'administration est sudo ; sous les systèmes dérivés de RHEL, c'est wheel.

# Debian / Ubuntu
adduser deploy
usermod -aG sudo deploy

# CentOS / Rocky / AlmaLinux
useradd -m deploy
passwd deploy
usermod -aG wheel deploy

Étape 3 : Configurer l'authentification par clé SSH

Une clé SSH est bien plus robuste qu'un mot de passe et ne peut pas être devinée. Générez la paire de clés sur votre propre ordinateur, pas sur le serveur, puis copiez la clé publique vers le nouvel utilisateur. Protégez la clé privée par une phrase secrète.

# on your own computer (Windows PowerShell, macOS, Linux)
ssh-keygen -t ed25519 -C "my-laptop"

# macOS / Linux: copy the public key to the server
ssh-copy-id [email protected]

# Windows PowerShell (no ssh-copy-id)
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Ouvrez un nouveau terminal et vérifiez que la connexion par clé et sudo fonctionnent :

ssh [email protected]
sudo whoami

Étape 4 : Désactiver la connexion root et l'authentification SSH par mot de passe

Les versions récentes (Debian 12, Ubuntu 22.04+, Rocky/AlmaLinux 9) lisent les fichiers de /etc/ssh/sshd_config.d/, et la première valeur trouvée l'emporte. Choisissez donc un nom de fichier lu en premier, comme 01-hardening.conf, pour prendre le pas sur les images cloud qui activent les mots de passe dans 50-cloud-init.conf. Sur les systèmes plus anciens, modifiez les mêmes lignes directement dans /etc/ssh/sshd_config.

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

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Vérifiez la syntaxe et redémarrez SSH :

sudo sshd -t
# Debian / Ubuntu
sudo systemctl restart ssh
# CentOS / Rocky / AlmaLinux
sudo systemctl restart sshd

Testez à nouveau depuis un nouveau terminal : ssh [email protected] doit être refusé, alors que ssh [email protected] fonctionne toujours.

Étape 5 : Configurer le pare-feu pour n'autoriser que les ports utiles

Refusez tout le trafic entrant par défaut, puis ouvrez uniquement SSH et les services réellement utilisés (80 et 443 pour un site web). Autorisez toujours SSH avant d'activer le pare-feu. Si vous avez changé le port SSH, autorisez ce port à la place.

# Debian / Ubuntu (ufw)
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable

# CentOS / Rocky / AlmaLinux (firewalld)
sudo dnf install firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --permanent --remove-service=cockpit
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

ufw comme firewalld appliquent ces règles à l'IPv4 et à l'adresse IPv6 gratuite de votre VPS JUSTG.

Étape 6 : Installer fail2ban contre la force brute

Même sans mots de passe, fail2ban garde des journaux propres et bloque les scanners. Il surveille les échecs d'authentification et bannit temporairement l'IP source. Le backend systemd lit le journal système et fonctionne sur les deux familles de distributions.

# Debian / Ubuntu
sudo apt install fail2ban python3-systemd

# CentOS / Rocky / AlmaLinux
sudo dnf install epel-release
sudo dnf install fail2ban python3-systemd

sudo nano /etc/fail2ban/jail.local

[sshd]
enabled  = true
backend  = systemd
maxretry = 5
findtime = 10m
bantime  = 1h

sudo systemctl enable --now fail2ban
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Étape 7 : Activer les mises à jour de sécurité automatiques

La plupart des intrusions exploitent des failles déjà corrigées. Laissez le serveur installer seul les mises à jour de sécurité : unattended-upgrades sous Debian/Ubuntu, dnf-automatic sous CentOS/Rocky/AlmaLinux.

# Debian / Ubuntu
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
sudo unattended-upgrade --dry-run --debug

# CentOS / Rocky / AlmaLinux
sudo dnf install dnf-automatic
sudo nano /etc/dnf/automatic.conf
#   upgrade_type = security
#   apply_updates = yes
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

Les mises à jour du noyau nécessitent toujours un redémarrage. Prévoyez de courts redémarrages de maintenance ou vérifiez la présence de /var/run/reboot-required sous Debian/Ubuntu.

Questions fréquentes

Je me suis bloqué après avoir désactivé les mots de passe. Comment revenir ?

Ouvrez la console VNC depuis l'espace client JUSTG, connectez-vous et corrigez le fichier dans /etc/ssh/sshd_config.d/ ou les règles du pare-feu. La console ne dépend ni de SSH ni du pare-feu.

Faut-il aussi changer le port SSH ?

Déplacer SSH hors du port 22 réduit le bruit dans les journaux, mais ce n'est pas une vraie protection à lui seul. Si vous le faites, mettez d'abord le pare-feu à jour et, sur Rocky/AlmaLinux avec SELinux, exécutez semanage port -a -t ssh_port_t -p tcp 2222.

Est-ce valable pour un VPS Windows ?

Les principes sont identiques : laissez Windows Update actif, utilisez un mot de passe Administrator robuste et limitez RDP à vos propres IP dans le Pare-feu Windows Defender.

Si vous avez besoin d'aide pour sécuriser votre serveur, ouvrez un ticket auprès du support technique JUSTG.