Installer et sécuriser un VPS Ubuntu 24.04 en 2026 : le guide complet de A à Z

Vous venez de commander votre premier VPS, le mail de bienvenue vous donne une adresse IP et un mot de passe root, et là… vous vous retrouvez devant un terminal vide. C’est exactement à ce moment que se joue 90 % de la sécurité de votre serveur. Un VPS Ubuntu fraîchement installé est exposé à Internet en quelques minutes : les bots scannent le port 22 en permanence et tentent des milliers de connexions par jour. Laisser l’authentification par mot de passe activée avec le compte root accessible, c’est laisser la porte ouverte.

Dans ce guide, nous allons partir d’un VPS Ubuntu 24.04 LTS vierge et le transformer en serveur durci, prêt à héberger n’importe quel service en production. Tout est expliqué, chaque commande est exacte et testée : création d’un utilisateur non-root, authentification par clés SSH, désactivation du mot de passe et du root, pare-feu UFW, protection anti-bruteforce avec fail2ban, et mises à jour de sécurité automatiques. Comptez 30 à 45 minutes la première fois.

Prérequis

Avant de commencer, assurez-vous d’avoir :

Un VPS sous Ubuntu 24.04 LTS fraîchement provisionné (un fournisseur fiable comme Hetzner à partir de 4 €/mois, ou OVHcloud fait parfaitement l’affaire). Si vous hésitez encore, notre comparatif des meilleurs VPS pour le self-hosting vous aidera à choisir.
L’adresse IP publique de votre VPS et le mot de passe root initial (fournis par mail).
Un terminal sur votre machine locale : Terminal sous macOS/Linux, ou PowerShell / Windows Terminal sous Windows (OpenSSH est intégré depuis Windows 10).
30 minutes devant vous et un peu de rigueur.

Tout au long du tutoriel, remplacez 203.0.113.10 par l’IP réelle de votre serveur et selfhostr par le nom d’utilisateur de votre choix.

Étape 1 : Première connexion et mise à jour du système

Connectez-vous une première fois en root avec le mot de passe reçu :

ssh root@203.0.113.10

Acceptez l’empreinte du serveur (yes) puis saisissez le mot de passe. Vous êtes dans le shell. Avant toute chose, on met le système à jour pour récupérer les derniers correctifs de sécurité :

apt update && apt upgrade -y

Si le noyau est mis à jour, un redémarrage est nécessaire. Vérifiez avec :

[ -f /var/run/reboot-required ] && echo "Redémarrage requis" || echo "Pas de redémarrage nécessaire"

Si un redémarrage est requis, lancez reboot et reconnectez-vous après une minute.

Profitez-en pour définir le fuseau horaire et le nom d’hôte du serveur :

timedatectl set-timezone Europe/Paris
hostnamectl set-hostname srv-selfhostr

Étape 2 : Créer un utilisateur non-root avec sudo

Travailler en root au quotidien est une mauvaise pratique : la moindre erreur peut détruire le système, et un service compromis tournant en root donne un accès total à l’attaquant. On crée donc un utilisateur dédié :

adduser selfhostr

Renseignez un mot de passe fort (il servira de filet de sécurité pour sudo, pas pour SSH). Les autres champs (nom complet, etc.) peuvent rester vides. Ajoutez ensuite cet utilisateur au groupe sudo :

usermod -aG sudo selfhostr

Vérifiez que l’utilisateur dispose bien des droits :

groups selfhostr

La sortie doit contenir sudo. Ne fermez pas la session root tout de suite : on va d’abord configurer les clés SSH et vérifier qu’on peut se connecter avec le nouvel utilisateur.

Étape 3 : Générer et installer une paire de clés SSH

L’authentification par clé est infiniment plus robuste qu’un mot de passe. Une clé Ed25519 moderne est impossible à brute-forcer dans un temps raisonnable.

Sur votre machine locale

Ouvrez un nouveau terminal local (ne fermez pas celui connecté au VPS) et générez la paire de clés :

ssh-keygen -t ed25519 -C "selfhostr@$(hostname)" -f ~/.ssh/id_selfhostr

Acceptez l’emplacement proposé et, idéalement, protégez la clé par une passphrase. Vous obtenez deux fichiers : id_selfhostr (privée, ne la partagez jamais) et id_selfhostr.pub (publique, à déposer sur le serveur).

Copier la clé publique sur le VPS

La méthode la plus simple, si elle est disponible :

ssh-copy-id -i ~/.ssh/id_selfhostr.pub selfhostr@203.0.113.10

Saisissez le mot de passe de l’utilisateur selfhostr. Si ssh-copy-id n’est pas disponible (Windows notamment), faites-le manuellement. Côté serveur (dans la session root déjà ouverte) :

mkdir -p /home/selfhostr/.ssh
chmod 700 /home/selfhostr/.ssh
nano /home/selfhostr/.ssh/authorized_keys

Collez le contenu de votre fichier id_selfhostr.pub, enregistrez (Ctrl+O, Entrée, Ctrl+X), puis fixez les permissions :

chmod 600 /home/selfhostr/.ssh/authorized_keys
chown -R selfhostr:selfhostr /home/selfhostr/.ssh

Tester la connexion par clé

Avant de désactiver quoi que ce soit, ouvrez un nouveau terminal local et testez :

ssh -i ~/.ssh/id_selfhostr selfhostr@203.0.113.10

Vous devez arriver dans le shell sans qu’aucun mot de passe SSH ne vous soit demandé (seulement la passphrase de la clé, le cas échéant). Si ça fonctionne, la suite peut se faire en toute sécurité. Si ça échoue, ne touchez pas à la config SSH tant que la connexion par clé n’est pas opérationnelle.

Pour vous simplifier la vie, créez un alias dans ~/.ssh/config sur votre machine locale :

Host selfhostr
    HostName 203.0.113.10
    User selfhostr
    IdentityFile ~/.ssh/id_selfhostr
    Port 22

Vous pourrez alors vous connecter avec un simple ssh selfhostr.

Étape 4 : Durcir la configuration du serveur SSH

C’est l’étape la plus importante. On va désactiver le login root et l’authentification par mot de passe. Connecté en tant que selfhostr, éditez la config via un fichier dédié (Ubuntu 24.04 charge les fichiers de /etc/ssh/sshd_config.d/, c’est plus propre que de modifier le fichier principal) :

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

Collez le contenu suivant :

# Désactive la connexion directe en root
PermitRootLogin no

# Désactive l'authentification par mot de passe (clés uniquement)
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no

# Active l'authentification par clé publique
PubkeyAuthentication yes

# Limite les tentatives et les sessions
MaxAuthTries 3
MaxSessions 5
LoginGraceTime 30

# Restreint l'accès au seul utilisateur autorisé
AllowUsers selfhostr

Enregistrez. Validez la syntaxe avant de redémarrer le service, sinon vous risquez de vous bloquer :

sudo sshd -t

Si la commande ne renvoie rien, la config est valide. Rechargez SSH :

sudo systemctl restart ssh

Piège classique : Ne fermez surtout pas votre session actuelle. Ouvrez un nouveau terminal et testez ssh selfhostr. Si la connexion par clé fonctionne toujours, c’est bon. Si vous êtes verrouillé, vous gardez l’ancienne session ouverte pour corriger. La plupart des hébergeurs proposent aussi une console VNC/KVM de secours en cas de blocage total.

Vérifions que root est bien refusé (cette commande doit échouer rapidement) :

ssh root@203.0.113.10

Vous devez obtenir Permission denied (publickey). Parfait.

Étape 5 : Configurer le pare-feu UFW

Par défaut, tous les ports sont potentiellement exposés. UFW (Uncomplicated Firewall) permet de ne laisser passer que ce dont vous avez besoin. La règle d’or : on bloque tout en entrée, on autorise tout en sortie, puis on ouvre uniquement les ports utiles.

sudo ufw default deny incoming
sudo ufw default allow outgoing

Autorisez SSH avant d’activer le pare-feu (sinon vous coupez votre propre connexion) :

sudo ufw allow OpenSSH

Si vous prévoyez d’héberger un site ou un reverse proxy, ouvrez aussi le web :

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Activez le pare-feu et confirmez par y :

sudo ufw enable

Vérifiez l’état des règles :

sudo ufw status verbose

Vous obtenez la liste des ports ouverts. Tout le reste est bloqué en entrée.

Astuce sécurité : Si vous voulez limiter encore le bruteforce SSH au niveau réseau, sudo ufw limit OpenSSH bloque temporairement une IP qui ouvre plus de 6 connexions en 30 secondes.

Étape 6 : Installer fail2ban contre le bruteforce

Même avec les clés SSH, les bots vont continuer à marteler votre port 22 et polluer vos logs. fail2ban surveille les journaux et bannit automatiquement les IP qui multiplient les échecs.

sudo apt install -y fail2ban

Ne modifiez jamais jail.conf directement (il est écrasé aux mises à jour). Créez un fichier jail.local :

sudo nano /etc/fail2ban/jail.local

Avec ce contenu :

[DEFAULT]
# Bannir 1 heure après 4 échecs sur une fenêtre de 10 minutes
bantime = 1h
findtime = 10m
maxretry = 4
# Ne jamais se bannir soi-même (ajoutez votre IP fixe si vous en avez une)
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true
port = ssh

Sur Ubuntu 24.04, le backend de log par défaut est systemd, ce qui est géré automatiquement. Activez et démarrez le service :

sudo systemctl enable --now fail2ban

Vérifiez que la prison SSH est active :

sudo fail2ban-client status sshd

Vous verrez le nombre d’IP actuellement bannies et la liste. Pour débannir une IP au besoin :

sudo fail2ban-client set sshd unbanip 198.51.100.5

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

Un serveur non patché est une cible facile. Le paquet unattended-upgrades applique automatiquement les correctifs de sécurité.

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Sélectionnez Yes dans la fenêtre qui apparaît. Pour aller plus loin, vérifiez le fichier de configuration :

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Assurez-vous que la ligne des mises à jour de sécurité est bien décommentée :

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

Optionnellement, activez le redémarrage automatique la nuit si un correctif noyau l’exige (à faire uniquement si une courte interruption planifiée ne pose pas de problème) :

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Lancez un test à blanc pour vérifier que tout fonctionne :

sudo unattended-upgrades --dry-run --debug

Étape 8 : Vérification finale du durcissement

Faites le tour de contrôle complet. Voici les vérifications qui confirment que votre serveur est correctement sécurisé :

# Le login root SSH doit être refusé
sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"
# Attendu : permitrootlogin no / passwordauthentication no

# Le pare-feu doit être actif
sudo ufw status | head -1
# Attendu : Status: active

# fail2ban doit tourner
sudo systemctl is-active fail2ban
# Attendu : active

# Les mises à jour auto doivent être planifiées
systemctl is-enabled unattended-upgrades
# Attendu : enabled

Si toutes les sorties correspondent, votre VPS est durci selon les bonnes pratiques 2026.

Bonnes pratiques et hardening avancé

Pour aller au-delà du socle de base :

Changer le port SSH (de 22 vers un port haut comme 49222) réduit drastiquement le bruit des bots. C’est de la sécurité par l’obscurité, donc un complément, jamais un substitut aux clés. Pensez à mettre à jour la règle UFW et la directive Port dans la config SSH.
Désactiver IPv6 si vous ne l’utilisez pas, ou pensez à dupliquer vos règles UFW et fail2ban pour IPv6.
2FA SSH via Google Authenticator (libpam-google-authenticator) ajoute une couche TOTP pour les environnements sensibles.
Snapshots réguliers chez votre hébergeur : c’est votre filet de sécurité en cas de mauvaise manipulation. Combinez-les avec des sauvegardes hors-site (voir notre tuto restic ci-dessous).
Surveiller les connexions avec sudo lastb (échecs) et last (succès), et auditer régulièrement /var/log/auth.log.
Principe du moindre privilège : chaque service que vous installerez ensuite doit tourner sous son propre utilisateur, jamais en root.

FAQ

Faut-il vraiment désactiver l’authentification par mot de passe ?

Oui, absolument. C’est la mesure qui a le plus d’impact. Tant que PasswordAuthentication yes est actif, n’importe quel bot peut tenter de deviner votre mot de passe à l’infini. Avec les clés Ed25519, cette attaque devient impossible en pratique. Conservez simplement une copie de sauvegarde de votre clé privée dans un gestionnaire de mots de passe ou un coffre chiffré.

J’ai perdu ma clé SSH, comment me reconnecter ?

Utilisez la console KVM/VNC de secours fournie par votre hébergeur (Hetzner, OVH, etc. en proposent toutes une). Connectez-vous en root via cette console, réactivez temporairement PasswordAuthentication yes ou ajoutez une nouvelle clé publique dans authorized_keys, puis rechargez SSH. C’est pour ce genre de situation qu’il ne faut jamais s’enfermer dehors sans plan B.

UFW et fail2ban font-ils doublon ?

Non, ils sont complémentaires. UFW est un pare-feu statique : il décide quels ports sont ouverts ou fermés. fail2ban est dynamique : il analyse les logs applicatifs et bannit temporairement les IP qui se comportent mal sur les ports que vous avez choisi d’ouvrir. Les deux ensemble couvrent à la fois la surface d’attaque et le comportement.

Ce guide vaut-il aussi pour Debian 12 ?

À 95 %, oui. Les commandes apt, UFW et fail2ban sont identiques. La principale différence concerne la gestion du service SSH (le nom du service est ssh sur les deux récents) et le backend de log de fail2ban. Adaptez les chemins si nécessaire, le reste s’applique tel quel.

Combien de RAM faut-il pour un VPS sécurisé de base ?

Le durcissement en lui-même ne consomme quasiment rien : fail2ban, UFW et unattended-upgrades tiennent dans quelques dizaines de Mo. Un VPS à 1 ou 2 Go de RAM suffit largement pour le socle. Dimensionnez en fonction des services que vous hébergerez ensuite. Pour un panorama des offres abordables, consultez notre sélection de VPS pas chers en 2026.