- Sécuriser un VPS de base tient en huit gestes.
- Tu crées un utilisateur non-root avec sudo, tu installes ta clé SSH, puis tu coupes le login root et le mot de passe.
- Restent le pare-feu ufw, fail2ban, les mises à jour automatiques et les sauvegardes.
Lecture complète : 7 min
Sécuriser un VPS de base tient en huit gestes. Tu crées un utilisateur non-root avec sudo, tu installes ta clé SSH, puis tu coupes le login root et le mot de passe. Restent le pare-feu ufw, fail2ban, les mises à jour automatiques et les sauvegardes. Une heure, copier-coller compris.
La première fois que j’ai loué un VPS chez Hetzner, c’était pour faire tourner n8n et mes automatisations LinkedIn et Notion. Le serveur a été en ligne en cinq minutes. Le soir même, j’ai ouvert les logs de connexion.
Des dizaines de tentatives de login venues d’IP inconnues, jour et nuit. Personne ne m’attaquait, moi. Des robots scannent internet en continu et frappent à toutes les portes ouvertes. Je build avec l’IA, sans background dev, et j’administre ce serveur moi-même. Voici la checklist que j’applique avant de laisser un VPS tourner.
Durcir un VPS, ça veut dire quoi ?
Durcir un VPS, c’est réduire les portes d’entrée d’un serveur avant qu’un attaquant ne les trouve. Tu fermes les ports inutiles, tu bloques les tentatives répétées, tu changes ta façon de te connecter. Le but n’est pas une forteresse. C’est de ne plus être la cible la plus facile du quartier.
Un VPS, c’est un serveur privé que tu loues au mois. Tu en as le contrôle total, donc la sécurité te revient. Sur un hébergement managé, ce travail est fait pour toi. Pas sur un VPS, où rien n’est durci par défaut.
Le réglage le plus dangereux laissé tel quel, c’est le compte root accessible par mot de passe. Un mot de passe se devine par force brute, une clé SSH non. Le reste découle de là : moins de portes, mieux verrouillées.
Si tu pars de zéro, j’ai détaillé l’installation dans mon guide pour configurer un VPS Hetzner pas à pas. Ici, on reste sur le durcissement.
Les commandes de durcissement à copier-coller
Voici le coeur de la checklist, dans l’ordre. Tu crées un utilisateur non-root avec sudo, tu y installes ta clé SSH, tu coupes le login root et l’authentification par mot de passe, puis tu actives le pare-feu et fail2ban. Chaque commande se copie telle quelle sur Ubuntu ou Debian.
Première étape, créer un utilisateur normal avec les droits administrateur. Remplace le nom par le tien.
adduser samwane
usermod -aG sudo samwaneCopie ensuite ta clé SSH sur ce compte. Elle remplace le mot de passe pour te connecter.
ssh-copy-id samwane@ip_du_serveurConnexion par clé testée, durcis la config SSH. Passe ces deux lignes à no.
PermitRootLogin no
PasswordAuthentication noRecharge SSH pour appliquer.
systemctl restart sshActive le pare-feu. Autorise d’abord SSH, sinon tu te coupes l’accès. Ouvre les ports web seulement si tu sers un site.
ufw allow OpenSSH
ufw allow 80
ufw allow 443
ufw enableEnfin, installe fail2ban. Il surveille les logs et bannit toute IP qui multiplie les échecs.
apt install fail2ban
systemctl enable fail2banUn avertissement avant de couper le mot de passe. Garde une session SSH ouverte pendant que tu testes la clé. Si tu te trompes, tu corriges sans rester dehors.
Menace contre parade : ce que chaque réglage bloque
Chaque ligne de la checklist répond à une menace précise. Comprendre laquelle t’évite de copier des commandes en aveugle. Le tableau ci-dessous met face à face le risque réel et le réglage qui le neutralise. C’est le résumé à relire avant de remettre un serveur en ligne.
| Menace | Parade |
|---|---|
| Attaque par force brute sur le mot de passe | Clé SSH et authentification par mot de passe désactivée |
| Connexion directe au compte root | Login root coupé, accès via un utilisateur sudo |
| Bots qui scannent tous les ports ouverts | Pare-feu ufw, seuls SSH et le web restent ouverts |
| Tentatives de connexion répétées | fail2ban bannit l’IP après plusieurs échecs |
| Faille de sécurité connue non corrigée | Mises à jour automatiques de sécurité |
| Serveur perdu ou disque corrompu | Sauvegardes régulières et testées |
La menace la plus fréquente, c’est la force brute sur SSH. C’est ce que je voyais dans mes logs Hetzner. La clé SSH plus le mot de passe coupé règle ce point. fail2ban vient en deuxième couche, pour les robots qui insistent.
Le durcissement que j’ai appliqué sur mon VPS Hetzner
Sur mon VPS Hetzner, celui qui fait tourner n8n et mes automatisations LinkedIn et Notion, j’ai suivi cette checklist le jour de la mise en ligne. Deux gestes m’ont le plus rassuré : couper l’accès root par mot de passe et brancher les mises à jour automatiques. Voici comment, concrètement.
Le problème, je l’ai vu dans les logs dès le premier soir. Des tentatives de connexion en boucle sur le compte root, depuis des IP étrangères. Juste des robots qui testent les serveurs neufs. Mais root par mot de passe, c’est la porte qu’ils espèrent ouverte.
L’action a pris vingt minutes. J’ai créé mon utilisateur sudo, posé ma clé SSH, puis basculé PermitRootLogin et PasswordAuthentication sur no. Ensuite, fail2ban et les mises à jour automatiques avec deux commandes.
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgradesLe résultat, je le mesure à ce que je ne fais plus. Je ne me connecte plus en root. Je ne surveille plus mes logs avec angoisse. Pour les sauvegardes, j’ai activé les snapshots côté Hetzner et je garde une copie de ma config n8n. Ma config initiale, je l’ai racontée dans comment j’ai configuré mon VPS.
La checklist à cocher avant de laisser ton VPS tourner
Voici la checklist complète, dans l’ordre où je l’applique. Huit points, du compte utilisateur jusqu’aux sauvegardes. Coche-les un par un avant de considérer ton serveur comme prêt. Si un seul manque, c’est souvent celui-là qui se retourne contre toi. Garde cette liste, elle ressert à chaque nouveau VPS.
- Créer un utilisateur non-root et lui donner les droits sudo.
- Installer ta clé SSH sur ce compte et tester la connexion.
- Désactiver le login root dans la configuration SSH.
- Désactiver l’authentification par mot de passe.
- Activer le pare-feu ufw et n’ouvrir que SSH et le web.
- Installer fail2ban pour bannir les IP trop insistantes.
- Brancher les mises à jour automatiques de sécurité.
- Programmer des sauvegardes et vérifier qu’elles se restaurent.
Un dernier réflexe. Une sauvegarde jamais testée n’est pas une sauvegarde. Restaure-la une fois pour être sûr qu’elle marche le jour venu.
Ce qu’un VPS durci change pour toi
Trois choses à retenir. La force brute sur SSH est la menace numéro un, et la clé SSH plus le mot de passe coupé la règle presque entièrement. Le pare-feu ufw et fail2ban ferment le reste des portes faciles. Et les sauvegardes te rendent un serveur même après une grosse bêtise.
Sécuriser un VPS n’est pas réservé aux dev chevronnés. C’est une checklist que je déroule en moins d’une heure. Toi, ton prochain VPS, tu le durcis avant la mise en ligne, ou tu attends de voir tes logs se remplir ?
Dernière mise à jour : juin 2026
Discussion