Configurer un nouveau serveur root : la checklist des 30 premières minutes

Un nouveau serveur root est joignable dès la première seconde et scanné dès la première minute. D'expérience, les tentatives de connexion automatisées sur le port 22 commencent avant même que vous vous soyez connecté une première fois. Cette liste amène un serveur neuf, en une demi-heure environ, dans un état où vous pouvez le laisser tourner l'esprit tranquille.

Toutes les commandes supposent que vous travaillez en tant que root, comme juste après la mise à disposition. Dès que vous êtes connecté avec votre nouvel utilisateur, faites précéder chaque commande d'un sudo. L'ordre des étapes a été vérifié sur Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS et Ubuntu 22.04 LTS. Là où ces quatre systèmes diffèrent, la différence est signalée.

Étape 0 : sécuriser la voie de retour avant de modifier quoi que ce soit

La seule erreur de cette liste que vous ne pourrez pas réparer par SSH, c'est celle qui vous prive de SSH. Pour les 30 prochaines minutes, une règle absolue s'applique donc : ouvrez une deuxième fenêtre de terminal avec une connexion SSH active et ne la fermez pas. Une session SSH déjà établie survit aussi bien au redémarrage du service SSH qu'à l'activation du pare-feu. Si une nouvelle connexion échoue après une modification, annulez cette modification depuis la session restée ouverte.

Vous devriez également savoir où trouver l'accès console à votre serveur avant d'en avoir besoin. Chez KernelHost, vous le trouvez dans l'espace client, indépendamment de SSH et indépendamment du pare-feu. Chercher le chemin au moment où l'on est déjà bloqué dehors fait perdre du temps.

Il faut savoir distinguer les messages d'erreur suivants, car ils pointent vers des causes totalement différentes :

• ssh: connect to host 203.0.113.10 port 22: Connection refused signifie que le paquet est arrivé, mais que personne n'écoute sur ce port. Le service SSH ne tourne pas, ou bien il écoute sur un autre port.
• ssh: connect to host 203.0.113.10 port 22: Connection timed out signifie que le paquet a été rejeté. C'est presque toujours le pare-feu.
• Permission denied (publickey) signifie que le service tourne et que le pare-feu vous laisse passer, mais que votre clé ne convient pas.

Étape 1 : mettre le système à jour

Une image fraîchement installée est rarement à jour. Entre la fabrication de l'image et votre commande, il s'écoule souvent des semaines pendant lesquelles des mises à jour de sécurité sont parues.

cat /etc/os-release
apt update
apt full-upgrade -y

Le choix de full-upgrade plutôt que upgrade est délibéré : sur un système neuf, apt a le droit de supprimer des paquets si une dépendance l'exige. Sur un système de production déjà en service, vous vérifieriez d'abord ce qui doit être supprimé.

Sur Ubuntu 22.04 et 24.04, needrestart est préinstallé et interrompt la mise à jour par un écran coloré en plein écran qui demande quels services redémarrer. Si vous voulez éviter cela, par exemple dans un script :

NEEDRESTART_MODE=a DEBIAN_FRONTEND=noninteractive apt full-upgrade -y

Ensuite, faites le ménage et vérifiez si un redémarrage est nécessaire :

apt autoremove --purge -y
apt list --upgradable
test -f /var/run/reboot-required && echo "redémarrage requis" || echo "aucun redémarrage requis"

Différence entre les distributions : seul Ubuntu crée le fichier /var/run/reboot-required de façon fiable, il provient du paquet update-notifier-common. Debian ne signale pas du tout un redémarrage nécessaire par défaut. Sur Debian, installez needrestart à la place : à chaque appel, il vous indique si un nouveau noyau est prêt. Debian 13 embarque en plus une génération plus récente d'apt, dont la sortie est colorée et formatée en colonnes. Ce n'est pas une erreur, c'est simplement inhabituel.

Vérification : apt list --upgradable n'affiche plus rien à part la ligne d'en-tête Listing.... Si la mise à jour renvoie le message Release file for ... is not valid yet, l'horloge de votre serveur est fausse : passez à l'étape 5, puis reprenez l'étape 1.

Pour aller plus loin, y compris sur les paquets retenus et les dépôts tiers : mettre à jour un serveur Linux avec apt.

Étape 2 : créer un utilisateur au lieu de travailler en root

On ne travaille pas en root, parce que la moindre faute de frappe touche immédiatement tout le système et parce que tout attaquant connaît déjà le nom d'utilisateur root. Sur les images minimales de Debian, sudo n'est souvent même pas installé :

apt install -y sudo
adduser --disabled-password --gecos "" kernel
usermod -aG sudo kernel

L'option --disabled-password crée l'utilisateur sans mot de passe, ce qui convient exactement à une authentification par clé uniquement. Si vous voulez tout de même définir un mot de passe, par exemple pour sudo depuis la console, utilisez passwd kernel.

Différence entre les distributions : sur Debian et Ubuntu, le groupe des administrateurs s'appelle sudo. Ce n'est que si vous venez d'un système de la famille RHEL que vous chercherez wheel, qui n'existe pas ici.

Passons à la clé publique. Créez le répertoire avec les bonnes permissions, car des permissions incorrectes sont la cause la plus fréquente d'une authentification par clé refusée :

mkdir -p /home/kernel/.ssh
chmod 700 /home/kernel/.ssh
touch /home/kernel/.ssh/authorized_keys
chmod 600 /home/kernel/.ssh/authorized_keys
chown -R kernel:kernel /home/kernel/.ssh

Vous inscrivez le contenu de votre clé publique dans authorized_keys. Plus commode encore, depuis votre poste de travail, avec ssh-copy-id kernel@203.0.113.10.

Vérification, et ce avant de reconfigurer SSH :

id kernel
sudo -l -U kernel

La seconde ligne doit contenir (ALL : ALL) ALL. Connectez-vous ensuite dans une troisième fenêtre en tant que kernel et exécutez une fois sudo -v. Ce n'est qu'une fois que cela fonctionne que vous continuez. Détails : créer un utilisateur et configurer sudo ainsi que créer et déposer une clé SSH.

Étape 3 : sécuriser SSH

Sur les images Debian très épurées, le serveur SSH n'est même pas installé. Commencez alors par l'ajouter :

apt install -y openssh-server

Les quatre systèmes traités ici lisent une configuration supplémentaire depuis /etc/ssh/sshd_config.d/. Ne modifiez donc pas le gros fichier sshd_config, créez plutôt votre propre fichier. Celui-ci survit aux mises à jour de paquets sans aucune question.

Un détail que presque tous les tutoriels ratent : dans la configuration SSH, c'est la première valeur trouvée qui l'emporte, et non la dernière. Chez Debian et Ubuntu, la ligne Include /etc/ssh/sshd_config.d/*.conf figure tout en haut, et les fichiers de ce répertoire sont lus par ordre alphabétique. Sur les images Ubuntu, on y trouve souvent déjà 50-cloud-init.conf avec PasswordAuthentication yes. Un fichier nommé 99-... resterait donc sans effet. Regardez d'abord ce qui est déjà en place :

ls -l /etc/ssh/sshd_config.d/

cat > /etc/ssh/sshd_config.d/10-kernelhost.conf <<'EOF'
PermitRootLogin prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
EOF

Le choix de prohibit-password plutôt que no est délibéré : root peut toujours se connecter avec une clé, mais jamais avec un mot de passe. Cela vous sauve si quelque chose tourne mal avec l'utilisateur sudo. Si vous voulez verrouiller davantage, mettez no, mais à condition d'avoir réellement testé l'accès console au préalable.

Avant chaque redémarrage du service, vérifiez la syntaxe :

ssh-keygen -A
sshd -t && echo "configuration ok"
sshd -T | grep -E "^(permitrootlogin|passwordauthentication|pubkeyauthentication|port) "

sshd -T affiche les valeurs réellement effectives, une fois tous les fichiers Include résolus. C'est la seule preuve fiable que votre modification est bien prise en compte. Si la commande renvoie sshd: no hostkeys available -- exiting, les clés d'hôte manquent et ssh-keygen -A les génère. Si en revanche la vérification s'arrête sur Missing privilege separation directory: /run/sshd, c'est que le service n'a jamais tourné depuis le démarrage du système et que le répertoire d'exécution manque. Un mkdir -p /run/sshd ou un systemctl restart ssh le crée, après quoi sshd -t évalue de nouveau votre configuration.

Une sortie déroute régulièrement : pour PermitRootLogin prohibit-password, sshd -T affiche la ligne permitrootlogin without-password. Il s'agit de la même valeur sous son ancien nom, et non d'un signe que votre réglage n'aurait pas été pris en compte.

Seulement ensuite :

systemctl restart ssh

Le piège du socket sur Ubuntu 24.04 et Debian 13

Depuis Ubuntu 22.10, et donc aussi dans la 24.04, SSH est démarré par activation de socket. Conséquence : une ligne Port dans la configuration sshd est ignorée, le port vient de ssh.socket. Pour changer le port, il faut une surcharge systemd :

systemctl edit ssh.socket

Saisissez ceci dedans, sachant que la première ligne vide efface la valeur par défaut :

[Socket]
ListenStream=
ListenStream=0.0.0.0:2222
ListenStream=[::]:2222

Ensuite systemctl daemon-reload puis systemctl restart ssh.socket. Ubuntu 22.04 ne connaît pas encore ce mécanisme, la ligne Port dans la configuration y suffit.

Sur Debian 13, une curiosité voisine apparaît. Certaines images fraîches ont ssh.socket actif, les systèmes mis à niveau depuis Debian 12 non. Si les deux sont actifs en même temps, un rechargement échoue avec fatal: Cannot bind any address., parce que le service et le socket se disputent le port 22. Vérifiez, et tranchez en cas de doute :

systemctl is-enabled ssh.socket
systemctl disable --now ssh.socket
systemctl enable --now ssh.service

Vérification : ss -tlnp | grep ssh affiche le port attendu, et une nouvelle tentative de connexion depuis une fenêtre neuve aboutit. En détail : sécuriser SSH et désactiver la connexion root et changer le port SSH.

Étape 4 : activer le pare-feu

Sur Ubuntu, ufw est installé mais inactif. Sur les images minimales de Debian, il est totalement absent. L'ordre est ici vital : autoriser SSH d'abord, activer ensuite.

apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

La dernière commande est la plus importante de toute la liste. Les règles et les politiques par défaut ne filtrent rien à elles seules, c'est ufw enable qui arme le pare-feu. Si vous l'oubliez, vous vous retrouvez au bout du compte avec un pare-feu entièrement configuré, mais sans le moindre effet.

À l'activation, ufw demande : Command may disrupt existing ssh connections. Proceed with operation (y|n)?. Cet avertissement est sérieux, mais si la règle pour le port 22 (ou pour votre port modifié) a été posée avant, il ne se passe rien. C'est exactement pour cela que ufw allow 22/tcp figure dans la liste au-dessus de ufw enable. Si vous avez changé le port à l'étape 3, il faut mettre ici ufw allow 2222/tcp, sinon vous vous bloquez dehors. Dans un script ou dans une session non interactive, prenez ufw --force enable, qui saute la question.

Vérification :

ufw status verbose

On attend Status: active, en dessous Default: deny (incoming), allow (outgoing) et, dans la liste des règles, une ligne 22/tcp ALLOW IN pour votre port SSH. Si vous lisez toujours Status: inactive, c'est que ufw enable manque et que rien n'est protégé, aussi complètes que paraissent les règles. Ouvrez ensuite une nouvelle fenêtre et connectez-vous avant de fermer l'ancienne.

En complément, il faut un mécanisme de blocage contre les tentatives de connexion :

apt install -y fail2ban python3-systemd

cat > /etc/fail2ban/jail.local <<'EOF'
[DEFAULT]
backend = systemd
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
EOF

Pourquoi backend = systemd : depuis la version 12, Debian n'installe plus rsyslog, il n'existe donc pas de /var/log/auth.log. La valeur par défaut backend = auto cherche précisément ce fichier et fail2ban refuse alors de démarrer, avec le message Failed during configuration: Have not found any log file for sshd jail. Le paquet python3-systemd est la condition pour que l'accès au journal fonctionne. Sous Ubuntu 22.04 et 24.04, le fichier existe encore grâce à rsyslog, mais la variante systemd y fonctionne tout aussi bien et reste le choix pérenne. Vous pouvez le vérifier ainsi :

test -f /var/log/auth.log && echo "auth.log présent" || echo "pas d'auth.log, backend systemd requis"
fail2ban-client -t

Vérification : fail2ban-client status sshd affiche une ligne Currently banned. Si vous obtenez à la place Sorry but the jail 'sshd' does not exist, la configuration n'a pas été chargée. Plus d'informations dans configurer le pare-feu UFW et configurer Fail2ban.

Étape 5 : fuseau horaire et heure système

Une horloge fausse rend les journaux inexploitables, fait échouer les vérifications de certificats et peut bloquer apt avec Release file is not valid yet. Sur un vrai serveur :

timedatectl set-timezone Europe/Vienna
timedatectl status

Dans la sortie, ces lignes doivent être correctes : Time zone: Europe/Vienna et System clock synchronized: yes ainsi que NTP service: active. Si vous lisez NTP service: inactive, aucune synchronisation de l'heure ne tourne. Ubuntu fournit systemd-timesyncd par défaut, les images minimales de Debian souvent pas :

DEBIAN_FRONTEND=noninteractive apt install -y systemd-timesyncd tzdata
date

Beaucoup d'exploitants laissent volontairement leurs serveurs en UTC, afin que les journaux de différents sites restent comparables. Les deux approches se défendent, l'essentiel est que vous sachiez laquelle est active. Si timedatectl n'est pas disponible dans un environnement de conteneurs (container), la méthode classique fonctionne aussi :

ln -sf /usr/share/zoneinfo/Europe/Vienna /etc/localtime
dpkg-reconfigure -f noninteractive tzdata

Pour approfondir : configurer le fuseau horaire et la synchronisation de l'heure.

Étape 6 : définir le nom d'hôte

Le nom d'hôte apparaît dans les journaux, dans les e-mails sortants et dans les alertes de monitoring. Définissez-le tôt, sinon tous vos serveurs finiront par porter le même nom.

hostnamectl set-hostname srv01.votre-domaine.fr
hostname -f

Il faut ensuite une entrée correspondante dans /etc/hosts, sinon chaque appel à sudo vous accueille avec le message sudo: unable to resolve host srv01: Name or service not known et un délai bien perceptible. La ligne ressemble à 127.0.1.1 srv01.votre-domaine.fr srv01.

Le piège : sur les images avec cloud-init, ce qui est la règle chez Ubuntu, le nom d'hôte est réinitialisé au prochain redémarrage. Le réglage qui l'empêche :

command -v cloud-init || echo "cloud-init non installé"

mkdir -p /etc/cloud/cloud.cfg.d
printf 'preserve_hostname: true\n' > /etc/cloud/cloud.cfg.d/99_hostname.cfg

Vérification : après un redémarrage, hostnamectl renvoie toujours votre nom. Détails : changer durablement le nom d'hôte sous Linux.

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

Le serveur le plus dangereux est celui auquel plus personne ne touche. Les mises à jour de sécurité automatiques sont l'étape la plus efficace de toute cette liste.

apt install -y unattended-upgrades

cat > /etc/apt/apt.conf.d/20auto-upgrades <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
EOF

Installer le paquet ne suffit pas partout, c'est ce fichier qui déclenche vraiment l'exécution quotidienne. Vos réglages personnels vont dans un fichier portant un numéro plus élevé que le 50unattended-upgrades livré d'origine, afin qu'ils l'emportent et ne soient pas écrasés lors d'une mise à jour du paquet :

cat > /etc/apt/apt.conf.d/52unattended-upgrades-local <<'EOF'
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::MinimalSteps "true";
EOF

Par défaut, sur les deux distributions, l'outil ne tire que du dépôt de sécurité, pas les mises à jour ordinaires. C'est voulu et, pour des systèmes de production, c'est généralement le bon réglage. Si vous mettez Automatic-Reboot "true", définissez impérativement aussi une heure, sinon le serveur redémarre quand cela arrange le planificateur.

Vérification : un essai à blanc montre quels paquets seraient concernés, sans rien installer. Attention au singulier dans le nom de la commande :

unattended-upgrade --dry-run --debug
apt-config dump | grep -iE "unattended|periodic"

Après la première exécution, le journal sous /var/log/unattended-upgrades/ doit contenir quelque chose. S'il reste vide, la configuration ne s'applique pas. En détail : configurer les mises à jour de sécurité automatiques.

Étape 8 : monitoring

Dans les 30 premières minutes, monitoring ne veut pas dire monter un Grafana. Cela veut dire que vous serez averti si le serveur s'arrête ou si le stockage se remplit.

apt install -y htop tmux curl
df -h /
free -m

Trois choses suffisent pour commencer. Premièrement, un test de disponibilité externe, qui contrôle depuis l'extérieur et vous alerte, car un serveur qui a planté n'envoie plus d'avertissement sur lui-même. Deuxièmement, une alerte d'espace disque, car un système de fichiers plein est la cause la plus fréquente des pannes que personne n'a vues venir. Troisièmement, un coup d'œil dans le journal dès que quelque chose paraît étrange :

journalctl -p 3 -b --no-pager | tail -n 30
systemctl --failed

systemctl --failed devrait afficher 0 loaded units listed. Chaque ligne qui apparaît là est un service qui ne démarre pas, et que vous avez tout intérêt à réparer maintenant plutôt que dans trois mois. Pour aller plus loin : mettre en place le monitoring d'un serveur.

Étape 9 : sauvegarder avant d'avoir quelque chose à perdre

Le meilleur moment pour la première sauvegarde, c'est avant que les données soient là. Vous répétez alors la procédure sans pression. Deux choses méritent d'être mises de côté tout de suite, parce que leur reconstruction coûte le plus de temps : la configuration sous /etc et la liste des paquets installés.

tar -czf /root/etc-backup-$(date +%F).tar.gz /etc
dpkg --get-selections > /root/paquets.txt
tar -tzf /root/etc-backup-$(date +%F).tar.gz | wc -l

Vous n'avez pas encore une sauvegarde pour autant, seulement une copie sur le même support. Une sauvegarde se trouve sur un autre système, idéalement à un autre endroit. Un outil avec chiffrement et déduplication des blocs identiques vaut la peine dès le premier jour :

apt install -y borgbackup
borg --version

La vérité qui dérange : une sauvegarde dont on n'a jamais rien restauré n'est qu'une supposition. Réservez un créneau pour la première restauration et remettez en place un seul fichier. La marche à suivre est décrite dans stratégie de sauvegarde pour un serveur root.

Si vous vous êtes bloqué l'accès

Cela arrive, le plus souvent à l'étape 3 ou 4. Le chemin de retour est toujours le même : se connecter par la console dans l'espace client, avec nom d'utilisateur et mot de passe plutôt qu'avec une clé. Ensuite, selon la cause :

• Pare-feu trop strict : ufw disable, corriger la règle, ufw enable.
• Configuration SSH cassée : rm /etc/ssh/sshd_config.d/10-kernelhost.conf, puis sshd -t et systemctl restart ssh.
• Mauvais port après une modification du socket : systemctl revert ssh.socket annule la surcharge, ensuite systemctl daemon-reload et systemctl restart ssh.socket.
• Banni par fail2ban : fail2ban-client set sshd unbanip 203.0.113.10. Pour que cela ne vous arrive plus, inscrivez votre adresse fixe sous ignoreip dans le fichier jail.local.
• Clé refusée : presque toujours une question de permissions. chmod 700 sur le répertoire, chmod 600 sur le fichier, et les deux doivent appartenir à l'utilisateur, pas à root.

Le contrôle final

Qu'une commande ne renvoie pas d'erreur ne signifie pas qu'elle a produit son effet. Ces six vérifications montrent l'état réel :

1. sshd -T | grep -E "^(permitrootlogin|passwordauthentication|port) " affiche les valeurs effectives, pas celles que vous souhaitiez.
2. ufw status verbose indique Status: active avec une règle pour votre port SSH.
3. timedatectl status indique System clock synchronized: yes.
4. systemctl --failed ne liste rien.
5. unattended-upgrade --dry-run --debug s'exécute sans message d'erreur.
6. Une nouvelle connexion SSH depuis une fenêtre fraîchement ouverte aboutit, avec la clé, sans demande de mot de passe.

Ce n'est qu'une fois le point six validé que vous pouvez fermer l'ancienne fenêtre de terminal.

Ce qui vient ensuite

Un mot sur le choix de la distribution, car il engage les prochaines années. Depuis juillet 2026, Debian 12 est sortie du support régulier et sera maintenue jusqu'à mi-2028 par l'équipe LTS, avec un périmètre de paquets restreint. Qui installe aujourd'hui une machine neuve prend Debian 13 ou Ubuntu 24.04 LTS. Ubuntu 22.04 LTS reste en support standard jusqu'en 2027, mais pour un serveur destiné à tourner des années, ce n'est plus le premier choix. Debian 10 et Ubuntu 20.04 sont définitivement terminées depuis juin 2024 et mai 2025 respectivement, elles n'ont leur place sur aucun nouveau serveur.

Les différences de versions dans les dépôts comptent aussi en pratique. Debian ne fournit par principe aucun mysql-server, MariaDB y est le standard. Si vous avez besoin d'une version précise de PHP, de Node ou de Java, vérifiez plutôt à l'avance ce que la distribution propose, au lieu d'ajouter des dépôts tiers après coup. Et si vous ajoutez des dépôts tiers : apt-key est obsolète, les clés vont dans /etc/apt/keyrings/ et sont référencées dans la définition du dépôt via signed-by.

Vous disposez ainsi d'un serveur à jour, qui se maintient à jour tout seul, qui ne laisse entrer que vous et qui signale ce qui ne va pas. Tout le reste, serveur web, base de données, certificats, se construit là-dessus et pas à côté.