Liste de contrôle post-installation de Linux : configuration initiale du serveur

Niveau : débutant / intermédiaire
Durée estimée : ~40 minutes
Objectif : réaliser la configuration initiale essentielle d'un VPS Linux – durcir l'accès SSH, créer un utilisateur sudo, configurer un pare-feu, mettre en place les mises à jour de sécurité automatiques et planifier des tâches de maintenance de base avec cron.

Introduction

Les 30 premières minutes suivant le provisionnement d'un VPS sont les plus importantes. Un serveur Linux fraîchement installé est grand ouvert : la connexion root via SSH est généralement activée, aucune règle de pare-feu n'est en place et les paquets sont déjà obsolètes. Cette liste de contrôle post-installation Linux couvre toutes les étapes essentielles pour un environnement de production ou de développement – de la création d'un utilisateur sudo et de la configuration de l'authentification par clé SSH à l'activation d'UFW et à la planification des mises à jour de sécurité automatiques. Suivre ce guide une fois vous protège des vecteurs d'attaque les plus courants avant même de déployer quoi que ce soit dessus.

Ce guide couvre les instances VPS sous Ubuntu, Debian et AlmaLinux (compatible RHEL).

Prérequis

Avant de commencer, assurez-vous que les conditions suivantes sont remplies :

• Système d'exploitation : Ubuntu 20.04/22.04/24.04 LTS, Debian 11/12/13 ou AlmaLinux 8/9/10
• Accès : accès SSH root au serveur (par mot de passe ou par clé – vous le durcirez au cours de ce guide)
• Machine locale : un client SSH disponible (ssh sous Linux/macOS, PuTTY ou Windows Terminal sous Windows)
• Connaissances requises : utilisation de base de la ligne de commande Linux – navigation dans les répertoires, édition de fichiers avec nano
• Durée estimée : ~40 minutes pour une première exécution sans accroc

Étape 1 : définir le nom d'hôte du serveur

Un nom d'hôte approprié rend les journaux lisibles et évite les confusions lors de la gestion de plusieurs serveurs.

Commencez par mettre à jour le fichier /etc/hosts afin que le système puisse résoudre localement son nouveau nom d'hôte. Ouvrez le fichier :

sudo nano /etc/hosts

Ajoutez ou modifiez la ligne correspondant à 127.0.1.1 (ou 127.0.0.1 si 127.0.1.1 n'existe pas) pour qu'elle corresponde à votre nouveau nom d'hôte. Par exemple, si vous prévoyez d'utiliser web-01 :

127.0.1.1   web-01

Enregistrez et quittez (Ctrl+O, Entrée, Ctrl+X).

Définissez ensuite le nom d'hôte de manière globale avec hostnamectl :

sudo hostnamectl set-hostname <YOUR_HOSTNAME>

Vérifiez qu'il a bien été appliqué :

hostnamectl

Sortie attendue :

Static hostname: web-01
       Icon name: computer-vm
         Chassis: vm
      Machine ID: a1b2c3d4e5f6...
         Boot ID: ...
Operating System: Ubuntu 24.04.1 LTS
          Kernel: Linux 6.8.0-31-generic
    Architecture: x86-64

Étape 2 : mettre à jour tous les paquets

Effectuez immédiatement une mise à jour complète du système. Les paquets fournis avec une image VPS neuve sont presque toujours en retard.

Ubuntu/Debian (APT) :

sudo apt update && sudo apt upgrade -y

AlmaLinux/RHEL (DNF) :

sudo dnf update -y

Une fois la mise à jour terminée, vérifiez si un redémarrage est nécessaire.

Debian/Ubuntu :

cat /var/run/reboot-required 2>/dev/null && echo "Reboot required" || echo "No reboot needed"

AlmaLinux/RHEL :

sudo dnf install -y dnf-utils
needs-restarting -r

Si un redémarrage est nécessaire, effectuez-le maintenant avant de poursuivre – certaines mises à jour du noyau et des bibliothèques ne prennent effet qu'après un redémarrage :

sudo reboot

Étape 3 : créer un utilisateur sudo

Se connecter en root pour le travail quotidien n'est pas sûr et constitue une mauvaise pratique. Créez un utilisateur ordinaire et accordez-lui les privilèges sudo.

3.1 Ajouter l'utilisateur

sudo adduser <YOUR_USERNAME>

Sous Ubuntu/Debian, la commande vous invite à définir un mot de passe et à renseigner des champs de contact facultatifs. Saisissez le mot de passe ; ignorez le reste en appuyant sur Entrée.

Sous AlmaLinux/RHEL, adduser est un lien symbolique vers useradd et s'exécute de façon non interactive, sans demander de mot de passe, ce qui laisse le compte verrouillé. Vous devez définir le mot de passe manuellement :

sudo passwd <YOUR_USERNAME>

3.2 Accorder les privilèges sudo

Ubuntu/Debian – ajoutez l'utilisateur au groupe sudo :

sudo usermod -aG sudo <YOUR_USERNAME>

AlmaLinux/RHEL – ajoutez l'utilisateur au groupe wheel :

sudo usermod -aG wheel <YOUR_USERNAME>

3.3 Vérifier l'accès

Basculez vers le nouvel utilisateur et testez sudo :

su - <YOUR_USERNAME>
sudo whoami

Sortie attendue :

root

Si vous voyez root, l'utilisateur dispose de privilèges sudo fonctionnels. Vous pouvez maintenant fermer la session root :

exit

Étape 4 : configurer l'authentification par clé SSH

L'authentification SSH par mot de passe est vulnérable aux attaques par force brute. L'authentification par clé SSH remplace le mot de passe par une paire de clés cryptographiques, bien plus difficile à attaquer. C'est l'une des bonnes pratiques de configuration SSH les plus importantes que vous puissiez appliquer.

4.1 Générer une paire de clés SSH (sur votre machine locale)

Si vous ne disposez pas déjà d'une paire de clés SSH, générez-en une sur votre machine locale (pas sur le serveur) :

ssh-keygen -t ed25519 -C "<YOUR_USERNAME>@<YOUR_HOSTNAME>"

Acceptez l'emplacement de fichier par défaut. Définissez une phrase secrète (passphrase) lorsque vous y êtes invité – elle protège la clé si votre machine locale venait à être compromise.

4.2 Copier la clé publique sur le serveur

Depuis votre machine locale, copiez la clé vers le compte du nouvel utilisateur :

ssh-copy-id <YOUR_USERNAME>@<YOUR_SERVER_IP>

Si ssh-copy-id n'est pas disponible (par exemple sous Windows), copiez manuellement le contenu de ~/.ssh/id_ed25519.pub et ajoutez-le à la fin de ~/.ssh/authorized_keys sur le serveur.

4.3 Tester la connexion par clé

Ouvrez une nouvelle fenêtre de terminal (ne fermez pas encore la session actuelle) et testez la connexion :

ssh <YOUR_USERNAME>@<YOUR_SERVER_IP>

Vous devriez vous connecter sans qu'un mot de passe vous soit demandé (seule la phrase secrète de la clé l'est, si vous en avez défini une).

Étape 5 : durcir la configuration SSH et désactiver la connexion root

Une fois la connexion par clé confirmée (étape 4), verrouillez le démon SSH. Désactiver la connexion root et l'authentification par mot de passe via SSH est l'une des mesures les plus efficaces de toute liste de contrôle de durcissement d'un serveur Linux.

Sur les trois distributions, le fichier /etc/ssh/sshd_config contient, près du début, une ligne Include /etc/ssh/sshd_config.d/*.conf , et SSH applique la première valeur trouvée pour chaque paramètre. Des fichiers drop-in fournis par les distributions sont déjà présents et l'emportent sur tout ce que vous ajouteriez ensuite dans le fichier principal :

• Ubuntu 24.04 : 50-cloud-init.conf définit PasswordAuthentication yes
• AlmaLinux : 50-redhat.conf définit X11Forwarding yes

Pour cette raison, modifier le fichier principal sshd_config n'est pas fiable. Créez plutôt un fichier drop-in de durcissement portant un numéro bas (00-), afin qu'il soit lu en premier et l'emporte sur les fichiers des distributions. Le même fichier fonctionne sur les trois distributions.

Créez le fichier drop-in :

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
X11Forwarding no
EOF

Le préfixe 00- garantit que ce fichier est analysé avant les fichiers drop-in des distributions, tels que 50-cloud-init.conf et 50-redhat.conf. Comme SSH applique la règle « la première correspondance l'emporte », vous n'avez pas besoin de modifier ces fichiers.

Validez la syntaxe de la configuration avant de redémarrer le service :

sudo sshd -t

Si la commande n'affiche rien, la syntaxe est valide. Vérifiez maintenant les paramètres effectifs que le démon utilisera réellement :

sudo sshd -T | grep -iE "permitrootlogin|passwordauthentication|x11forwarding"

Sortie attendue :

permitrootlogin no
passwordauthentication no
x11forwarding no

Redémarrez le démon SSH pour appliquer les modifications.

Ubuntu 24.04 (activation par socket) :

sudo systemctl restart ssh.socket

Debian et Ubuntu plus anciennes :

sudo systemctl restart ssh

AlmaLinux/RHEL :

sudo systemctl restart sshd

Vérifiez que le service fonctionne (utilisez sshd sous AlmaLinux, ssh.socket sous Ubuntu 24.04) :

sudo systemctl status ssh

Vous devriez voir Active: active (running) (ou active (listening) pour SSH à activation par socket).

Confirmez maintenant que la connexion root est bloquée. Depuis votre machine locale :

ssh root@<YOUR_SERVER_IP>

Résultat attendu : la connexion est refusée avec le message Permission denied (publickey). La connexion root via SSH est désormais désactivée.

Étape 6 : configurer le pare-feu (UFW)

UFW (Uncomplicated Firewall) est l'outil de pare-feu standard sous Ubuntu et Debian. Sous AlmaLinux, firewalld est l'outil par défaut, mais UFW peut aussi y être installé. Cette étape couvre les deux approches.

6.1 UFW (Ubuntu/Debian)

Sous Debian (en particulier Debian 13), ufw n'est peut-être pas installé par défaut. Installez-le d'abord :

sudo apt update && sudo apt install -y ufw

Vérifiez l'état actuel :

sudo ufw status

Autorisez SSH avant d'activer le pare-feu :

sudo ufw allow ssh

Autorisez HTTP et HTTPS si vous prévoyez d'exécuter un serveur web :

sudo ufw allow http
sudo ufw allow https

Activez le pare-feu :

sudo ufw enable

Vérifiez les règles actives :

sudo ufw status verbose

Sortie attendue :

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

6.2 Firewalld (AlmaLinux/RHEL)

Activez et démarrez firewalld :

sudo systemctl enable --now firewalld

Autorisez SSH, HTTP et HTTPS :

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Vérifiez :

sudo firewall-cmd --list-all

Étape 7 : synchroniser l'horloge système (NTP)

Une heure exacte est indispensable aux protocoles de sécurité (validation SSL/TLS, Kerberos), à l'horodatage correct des journaux et aux tâches planifiées. Une horloge désynchronisée peut provoquer des erreurs de certificat SSL, des échecs d'authentification et des entrées de journal déroutantes.

Vérifiez l'état actuel de la synchronisation :

timedatectl status

Sortie attendue :

System clock synchronized: yes
NTP service: active

Si le service NTP apparaît comme inactive ou n/a, installez et activez chrony – le démon NTP recommandé pour les serveurs de production :

Ubuntu/Debian :

sudo apt install chrony -y
sudo systemctl enable --now chrony

AlmaLinux/RHEL :

sudo dnf install chrony -y
sudo systemctl enable --now chronyd

Attendez 30 à 60 secondes après le démarrage du service, puis vérifiez que la synchronisation est active :

chronyc tracking

Recherchez Leap status: Normal. Cela confirme que l'horloge système est synchronisée et que NTP fonctionne correctement.

Étape 8 : activer les mises à jour de sécurité automatiques

Les mises à jour manuelles fonctionnent, mais elles dépendent de votre capacité à ne pas les oublier. Les mises à jour de sécurité automatiques constituent un filet de sécurité – particulièrement crucial pour les instances VPS sans surveillance. Voici comment configurer les mises à jour de sécurité automatiques sous Linux sans nuire à la stabilité.

8.1 Ubuntu/Debian – unattended-upgrades

Installez le paquet :

sudo apt install unattended-upgrades -y

Activez-le et configurez-le :

sudo dpkg-reconfigure --priority=low unattended-upgrades

Vérifiez la configuration :

cat /etc/apt/apt.conf.d/20auto-upgrades

Sortie attendue :

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Pour tester sans appliquer de modifications :

sudo unattended-upgrade --dry-run --debug

8.2 AlmaLinux/RHEL – dnf-automatic

Installez :

sudo dnf install dnf-automatic -y

Ouvrez le fichier de configuration et définissez le type de mise à niveau sur « sécurité uniquement ». Faites d'abord une sauvegarde :

sudo cp /etc/dnf/automatic.conf /etc/dnf/automatic.conf.bak
sudo nano /etc/dnf/automatic.conf

Recherchez et définissez :

apply_updates = yes
upgrade_type = security

Activez et démarrez le minuteur (timer) :

sudo systemctl enable --now dnf-automatic.timer

Vérifiez :

sudo systemctl status dnf-automatic.timer

Étape 9 : planifier la maintenance de base avec cron

Cron gère les tâches planifiées – celles qui doivent s'exécuter régulièrement sans intervention manuelle. Une simple tâche cron pour le nettoyage des journaux ou la vérification du renouvellement des certificats est une pratique courante sur tout serveur géré.

Préparation pour AlmaLinux/RHEL :

Sur une installation propre d'AlmaLinux 10, nano peut ne pas être installé, et crontab -e ouvrira alors vi. Pour utiliser nano à la place, exécutez cette commande en une seule ligne, qui s'exécute proprement dans l'ordre et garantit la persistance de la variable d'environnement :

sudo dnf install nano -y && export EDITOR=nano && crontab -e

Sur les autres systèmes (comme Ubuntu/Debian), ouvrez simplement le crontab de l'utilisateur courant :

crontab -e

Lors de la première exécution (sous Ubuntu/Debian), il vous sera demandé de choisir un éditeur. Sélectionnez nano (option 1).

Exemples de tâches cron courantes

Exécuter une tâche chaque nuit à 2 h 00 :

0 2 * * * /usr/local/bin/my-maintenance-script.sh >> /var/log/maintenance.log 2>&1

Renouveler les certificats SSL chaque semaine (pour les utilisateurs de Certbot) :

0 3 * * 0 certbot renew --quiet >> /var/log/certbot-renew.log 2>&1

Supprimer les fichiers temporaires chaque mois :

0 4 1 * * find /tmp -type f -atime +30 -delete

Vérifiez que vos tâches cron sont bien enregistrées :

crontab -l

Vous devriez voir les entrées que vous avez ajoutées. Cron relit le fichier automatiquement – aucun rechargement n'est nécessaire. Pour vérifier que le service cron fonctionne, utilisez :

Ubuntu/Debian :

sudo systemctl status cron

AlmaLinux/RHEL :

sudo systemctl status crond

Vérification

Parcourez cette liste de contrôle pour confirmer que tout a été correctement appliqué :

Vérifiez le nom d'hôte :

hostnamectl | grep hostname

Confirmez que la connexion SSH root et l'authentification par mot de passe sont désactivées (cela vérifie la configuration active à l'exécution) :

sudo sshd -T | grep -iE "permitrootlogin|passwordauthentication"

Attendu :

permitrootlogin no
passwordauthentication no

Confirmez que le service SSH fonctionne :

# For Ubuntu 24.04:
sudo systemctl status ssh.socket

# For Debian / Older Ubuntu:
sudo systemctl status ssh

# For AlmaLinux:
sudo systemctl status sshd

Vérifiez l'état du pare-feu (Ubuntu/Debian) :

sudo ufw status verbose

Vérifiez la synchronisation NTP :

timedatectl status | grep -E "synchronized|NTP"

Attendu :

System clock synchronized: yes
NTP service: active

Vérifiez les mises à jour automatiques (Ubuntu/Debian) :

cat /etc/apt/apt.conf.d/20auto-upgrades

Listez les tâches cron actives :

crontab -l

Retour arrière (rollback)

Pour annuler certaines étapes en cas de problème :

Réactiver la connexion SSH root (si vous vous êtes verrouillé hors du serveur et que vous récupérez l'accès via la console) :

# Re-enable root/password login temporarily for recovery
sudo rm /etc/ssh/sshd_config.d/00-hardening.conf
sudo sshd -t

# Restart SSH (use the variant for your system):
sudo systemctl restart ssh.socket   # Ubuntu 24.04
sudo systemctl restart ssh          # Debian / older Ubuntu
sudo systemctl restart sshd         # AlmaLinux/RHEL

Désactiver UFW :

sudo ufw disable

Supprimer unattended-upgrades (Ubuntu/Debian) :

sudo apt remove unattended-upgrades -y

Supprimer dnf-automatic (AlmaLinux) :

sudo systemctl disable --now dnf-automatic.timer
sudo dnf remove dnf-automatic -y

Supprimer une tâche cron :

crontab -e
# Delete the relevant line, save and exit

Conclusion

Voilà pour la liste de contrôle post-installation Linux complète. Vous disposez désormais d'un serveur avec un nom d'hôte approprié, des paquets entièrement à jour, un utilisateur sudo non root, l'authentification par clé SSH en place, la connexion root désactivée, un pare-feu configuré, NTP synchronisé, des mises à jour de sécurité automatiques en service et un planning de tâches cron prêt à être étendu. C'est la configuration de base d'un serveur Linux après installation que tout VPS devrait avoir avant que quoi que ce soit d'autre y soit déployé.

La suite logique dépend de la finalité du serveur :

• Serveur web : installez Nginx ou Apache, configurez un hôte virtuel (virtual host) et mettez en place SSL avec Certbot
• Base de données : installez et durcissez MySQL/MariaDB ou PostgreSQL
• Supervision : mettez en place l'agrégation des journaux (par ex. logrotate) ou un agent de supervision léger
• Contrôle d'accès : examinez la configuration de sudoers et ajoutez les membres de l'équipe selon le même schéma qu'à l'étape 3

La liste de contrôle de configuration initiale d'un serveur Linux ne s'arrête pas ici – elle évolue avec le rôle du serveur. Mais cette base constitue le point de départ incontournable.

Version du document : 1.0
Dernière mise à jour : mai 2026
Propriétaire : équipe de documentation technique