Sécuriser un VPS : la liste à suivre

1. SSH par clé seulement

Un serveur joignable en SSH reçoit en permanence des tentatives de connexion automatiques. Avec des clés, ces robots ne peuvent rien deviner. Dans /etc/ssh/sshd_config, ou mieux dans un fichier du dossier /etc/ssh/sshd_config.d/, la directive suivante ferme la connexion par mot de passe, selon la page de manuel de sshd_config (Debian 13, lue le 14 octobre 2026) :

PasswordAuthentication no

Avant de recharger SSH avec sudo systemctl reload ssh, vérifiez que votre clé fonctionne dans une seconde session laissée ouverte : une erreur vous couperait du serveur. La création d'une clé est décrite dans Générer une clé SSH.

Travaillez avec un compte ordinaire qui a les droits sudo, plutôt qu'en root : une erreur de commande y fait moins de dégâts, et chaque action d'administration passe par sudo, qui la journalise.

2. Un pare-feu qui ne laisse passer que l'utile

N'ouvrez que les ports dont vous avez besoin : 22 pour SSH, 80 et 443 pour le web, et rien d'autre tant qu'aucun service ne l'exige. Une interface d'administration ou une base de données ne s'ouvre jamais à tout Internet : passez par un tunnel SSH, ou limitez la règle à votre adresse IP. La marche à suivre est dans Ouvrir un port sur un serveur Linux.

3. Les mises à jour de sécurité

Une faille connue et corrigée reste exploitable sur un serveur qui n'est pas à jour. Sur Ubuntu et Debian, le paquet unattended-upgrades applique les mises à jour de sécurité automatiquement, selon la documentation d'Ubuntu, lue le 14 octobre 2026.

Certaines mises à jour, celles du noyau surtout, ne prennent effet qu'après un redémarrage. Sur Ubuntu, la présence du fichier /var/run/reboot-required signale qu'il en faut un. Choisissez un moment calme, puis :

sudo reboot

4. Bannir les adresses qui insistent

fail2ban lit les journaux et bannit pour un temps l'adresse qui échoue plusieurs fois de suite. Il complète les clés : il réduit le bruit dans les journaux et ralentit les essais. Son réglage est décrit dans Fail2ban : installer et configurer sur Linux. Pour voir son action sur SSH :

sudo fail2ban-client status sshd

5. Docker : ne rien publier par accident

Un port publié par Docker, avec ports: dans un fichier compose, contourne le pare-feu installé sur le serveur lui-même. Pour un service qui ne doit être joignable que depuis le serveur, publiez-le sur 127.0.0.1, ou ne publiez rien et laissez les conteneurs se joindre par leur nom. Les applications web passent derrière un proxy inverse en HTTPS, sur 443 : voir Nginx Proxy Manager.

Vérifiez ce qui écoute réellement, de temps en temps :

sudo ss -tlnp
docker ps

Mettez aussi à jour les images de vos conteneurs : le système à jour ne protège pas une application qui tourne sur une image ancienne.

6. Les secrets

Les mots de passe des applications ne vont ni dans un fichier compose publié sur un dépôt Git, ni dans une commande qui reste dans l'historique du terminal. Rangez-les dans un fichier .env à côté du fichier compose, lisible par vous seul (chmod 600 .env), et ajoutez ce fichier à .gitignore.

7. Des sauvegardes hors du serveur

Une sauvegarde est la dernière protection, celle qui sert quand tout le reste a échoué. Exportez régulièrement vos bases et vos volumes, et rangez une copie ailleurs que sur le serveur. Voir Sauvegarde VPS : fonctionnement et restauration.

Sur un VPS Hubspace

La livraison fait déjà les quatre premiers points :

Le pare-feu étant en amont, il bloque aussi les ports publiés par Docker : le piège du point 5 ne vous expose pas par accident. Pour ouvrir un port, passez par l'espace client, sur votre VPS, onglet « Firewalls », en limitant la règle à votre adresse si possible. Le serveur est aussi sauvegardé chaque jour, sept jours gardés.

Un VPS Hubspace n'est pas un serveur managé : vos applications, leurs mises à jour, leurs secrets et leurs sauvegardes de données restent à votre charge, c'est-à-dire les points 5 à 7.

Questions fréquentes