Sécuriser son VPS Linux : les 6 étapes indispensables

Un serveur exposé sur Internet reçoit des tentatives de connexion dans les minutes qui suivent sa mise en ligne. Ce guide applique les six protections de base à un VPS Ubuntu, en un quart d'heure. Toutes les commandes ont été exécutées sur Ubuntu 26.04.1 LTS le 27 septembre 2026, en environnement de test puis sur un VPS QuantylCloud ; elles valent aussi pour Ubuntu 24.04 LTS.

Avant de commencer

Deux pare-feu, qui se complètent. Chaque serveur QuantylCloud est créé derrière un pare-feu réseau qui bloque toutes les connexions entrantes, sauf SSH (port 22). Vous le réglez dans l'onglet Pare-feu de la fiche du serveur. Ce guide ajoute un second pare-feu, ufw, sur la machine elle-même : si l'un est mal réglé, l'autre tient encore. Un port à ouvrir, par exemple 80 et 443 pour un site web, doit donc l'être aux deux endroits.

Gardez une porte de secours. Pendant les étapes 3 à 5, laissez votre session SSH ouverte et testez chaque changement depuis un second terminal. Si vous vous retrouvez bloqué dehors, la Console de secours de la fiche du serveur vous connecte à la machine sans passer par SSH.

Étape 1 — Installer les mises à jour

Connecté en root, commencez par les correctifs de sécurité en attente :

apt update && apt upgrade -y

Étape 2 — Créer un utilisateur d'administration

Travailler en root en permanence, c'est donner tous les droits à la moindre erreur. Créez un utilisateur qui passera par sudo. Choisissez votre propre nom : gestion sert d'exemple. Évitez admin : sur les images Ubuntu, un groupe système porte déjà ce nom et adduser refuse de créer l'utilisateur. La commande adduser vous demande un mot de passe : il servira à sudo, pas à la connexion.

adduser gestion
usermod -aG sudo gestion

Donnez-lui la clé SSH déjà autorisée pour root :

mkdir -p /home/gestion/.ssh
cp /root/.ssh/authorized_keys /home/gestion/.ssh/
chown -R gestion:gestion /home/gestion/.ssh
chmod 700 /home/gestion/.ssh
chmod 600 /home/gestion/.ssh/authorized_keys

Vous avez commandé le serveur sans clé SSH ? Créez-en une (voir Créer un VPS au Maroc, étape 5), puis, depuis votre ordinateur, envoyez-la avec ssh-copy-id gestion@ADRESSE_IP, qui demande une dernière fois le mot de passe.

Depuis un second terminal, vérifiez que la connexion et sudo fonctionnent :

ssh gestion@ADRESSE_IP
sudo whoami

La réponse doit être root. Ne passez pas à la suite tant que ce n'est pas le cas : la prochaine étape ferme l'accès root.

Étape 3 — Fermer root et les mots de passe dans SSH

Désormais connecté en gestion, interdisez la connexion directe en root et toute authentification par mot de passe, qui est la cible des robots :

printf 'PermitRootLogin no\nPasswordAuthentication no\nKbdInteractiveAuthentication no\n' | sudo tee /etc/ssh/sshd_config.d/00-durcissement.conf
sudo sshd -t
sudo systemctl reload ssh

Le nom du fichier compte. SSH retient la première valeur qu'il lit, et lit les fichiers de /etc/ssh/sshd_config.d/ par ordre alphabétique. Sur beaucoup d'images, un fichier 50-cloud-init.conf autorise les mots de passe : un fichier nommé 99-… serait lu après lui, et ignoré. Nous l'avons constaté en test. Le préfixe 00- passe avant.

Vérifiez la configuration effective :

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication) '

Les deux lignes doivent se terminer par no. Ouvrez ensuite une nouvelle connexion ssh gestion@ADRESSE_IP depuis un autre terminal avant de fermer la session en cours.

Étape 4 — Activer le pare-feu ufw

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

ufw enable prévient que l'opération peut couper les connexions SSH : répondez y. La règle OpenSSH, ajoutée juste avant, garde votre accès. Contrôlez :

sudo ufw status verbose

Seul le port 22 doit apparaître en ALLOW IN. Plus tard, pour un site web, vous ajouterez sudo ufw allow 80,443/tcp, et les mêmes ports dans l'onglet Pare-feu de la console.

Étape 5 — Bannir les attaques par force brute avec fail2ban

fail2ban lit les journaux de SSH et bloque pendant un moment une adresse qui accumule les échecs de connexion.

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Sur Ubuntu, la protection de SSH est active dès l'installation : cinq échecs en dix minutes valent dix minutes de bannissement. En test, une série de tentatives ratées a bien fait bannir l'adresse attaquante, et toute connexion depuis cette adresse, y compris légitime, a été refusée jusqu'à la levée du bannissement.

Si vous vous bannissez vous-même, par exemple après plusieurs essais avec la mauvaise clé, attendez dix minutes, ou ouvrez la Console de secours et levez le bannissement :

sudo fail2ban-client set sshd unbanip VOTRE_ADRESSE_IP

Étape 6 — Installer les mises à jour de sécurité automatiquement

sudo apt install -y unattended-upgrades
printf 'APT::Periodic::Update-Package-Lists "1";\nAPT::Periodic::Unattended-Upgrade "1";\n' | sudo tee /etc/apt/apt.conf.d/20auto-upgrades
sudo unattended-upgrade --dry-run

Le serveur installe désormais chaque jour les correctifs de sécurité d'Ubuntu. Nous écrivons le fichier directement plutôt que de passer par dpkg-reconfigure, qui ne le recrée pas s'il a été supprimé. Le serveur ne redémarre pas de lui-même : après une mise à jour du noyau, le fichier /var/run/reboot-required apparaît, et c'est à vous de choisir le moment du redémarrage.

Récapitulatif

• correctifs en attente installés ;
• un utilisateur d'administration avec sudo, et plus de connexion root ;
• SSH par clé uniquement, vérifié avec sshd -T ;
• deux pare-feu : celui de la console et ufw, SSH seul ouvert ;
• fail2ban contre la force brute ;
• mises à jour de sécurité quotidiennes.

Ces protections ne remplacent pas des sauvegardes : activez l'option de sauvegarde quotidienne depuis la fiche du serveur, ou tenez les vôtres.