Créer un utilisateur sudo et cesser de travailler en root

Juste après la mise à disposition d'un serveur, vous êtes root, et root a tous les droits, sans jamais demander confirmation. Une faute de frappe touche aussitôt le système entier, et root est le seul nom d'utilisateur que tout attaquant connaît à coup sûr. Ce guide parcourt le chemin complet : créer un utilisateur, l'ajouter au bon groupe, compléter la configuration sudoers, transférer la clé publique et, seulement à la toute fin, désactiver root. La partie décisive se trouve juste avant la conclusion : la preuve que vous ne vous êtes pas bloqué dehors.

Les systèmes de référence sont Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS et Ubuntu 22.04 LTS. Là où les systèmes de la famille RHEL comme AlmaLinux et Rocky Linux diffèrent, la précision est donnée. Les commandes sont écrites pour une utilisation en tant que root ; en tant qu'utilisateur normal, faites précéder chaque commande d'un sudo. La version courte figure dans la checklist pour un nouveau serveur root, voici l'approfondissement.

Avant toute modification : le chemin de retour

Deux modifications peuvent ici vous coûter l'accès : la configuration sudoers et, tout à la fin, l'autorisation pour root de se connecter en SSH. Un fichier sudoers cassé vous retire vos droits, une connexion root désactivée trop tôt vous retire la solution de repli. Trois points sont donc à régler avant de commencer.

Une deuxième session. Ouvrez une deuxième fenêtre de terminal avec une connexion SSH active en tant que root et ne la fermez pas tant que tout n'est pas vérifié. Une session déjà établie survit au redémarrage du service SSH tout comme à un fichier sudoers défectueux.

La voie qui contourne SSH. Sur les serveurs root KVM et les serveurs dédiés de KernelHost, vous ouvrez la console VNC depuis l'espace client. Elle est branchée sur la couche de virtualisation ou directement sur le raccordement de la machine, donc indépendante de SSH, du pare-feu et du fichier sudoers. Connectez-vous-y une fois avant de commencer : une voie de secours que l'on essaie seulement le jour de l'incident n'en est pas une.

Un mot de passe que vous connaissez. La console ne connaît pas les clés SSH : vous vous y identifiez avec un nom d'utilisateur et un mot de passe, ou pas du tout. C'est ici que naissent la plupart des blocages.

Règle empirique : la voie de secours est une console, et une console ne connaît que les mots de passe. Avant de désactiver l'authentification par mot de passe, au moins un compte doit disposer d'un mot de passe que vous connaissez.

État des lieux : sudo est-il seulement installé ?

Sur les images serveur d'Ubuntu, sudo est présent, sur les images minimales de Debian souvent pas. Trois lignes éclaircissent la situation de départ :

command -v sudo || echo "sudo est absent"
getent group sudo
awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3, $7}' /etc/passwd

La deuxième ligne affiche le groupe et ses membres, la troisième tous les comptes réguliers avec leur identifiant et leur shell de connexion. Sur les images qui embarquent cloud-init, un compte doté des droits sudo existe souvent déjà. Si sudo manque, installez-le :

apt-get update
apt-get install -y sudo
sudo -V | head -n 1

adduser ou useradd : deux outils, deux résultats

Utiliser useradd en attendant le comportement d'adduser donne un compte sans répertoire personnel et avec un shell auquel personne ne s'attendait.

Sur Debian et Ubuntu, adduser est le bon choix :

adduser --disabled-password --gecos "" kernel

--gecos "" saute les questions sur le nom et les numéros de téléphone, --disabled-password crée le compte sans mot de passe. C'est ici que guette le premier piège : un compte sans mot de passe ne peut pas se connecter à la console VNC, et il est impossible de répondre correctement à la demande de mot de passe de sudo. Définissez donc un mot de passe immédiatement après :

passwd kernel

Sur les systèmes de la famille RHEL ou dans un script, la version équivalente est la suivante :

useradd -m -s /bin/bash kernel
passwd kernel

Contrôle de réussite :

getent passwd kernel
ls -ld /home/kernel
passwd -S kernel

getent passwd kernel affiche le répertoire personnel et le shell de connexion ; si vous y lisez /bin/sh ou /usr/sbin/nologin, usermod -s /bin/bash kernel corrige cela. passwd -S kernel indique dans la deuxième colonne l'état du mot de passe : P pour utilisable, L pour verrouillé, NP pour aucun. Après passwd kernel, un P doit y figurer.

Le groupe d'administration : sudo sous Debian et Ubuntu, wheel sur RHEL

Un malentendu répandu : le groupe n'accorde pas les droits par lui-même, il ne les accorde que parce qu'une ligne de /etc/sudoers s'y réfère. Sous Debian et Ubuntu, elle ressemble à %sudo ALL=(ALL:ALL) ALL, sur les systèmes de la famille RHEL à %wheel ALL=(ALL) ALL. Ce qui est enregistré chez vous s'affiche ainsi :

grep -E '^[^#]*%' /etc/sudoers

Sous Ubuntu apparaît en plus une ligne pour l'ancien groupe admin. Ce groupe n'existe plus sur les images actuelles, la ligne reste donc sans effet. Voici comment ajouter l'utilisateur :

usermod -aG sudo kernel

Le -a n'est pas facultatif. Sans cette option, usermod -G remplace tous les groupes secondaires par la liste indiquée, sans le moindre avertissement, et le dégât ne se remarque souvent que des semaines plus tard. L'option n'agit qu'en combinaison avec -G. La commande gpasswd -a kernel sudo est équivalente et moins sujette aux erreurs.

Contrôle de réussite :

id -nG kernel
getent group sudo
sudo -l -U kernel

La dernière ligne est la plus parlante : elle interroge sudo lui-même. On attend un bloc qui se termine par (ALL : ALL) ALL. Si vous obtenez à la place User kernel is not allowed to run sudo on srv01., aucune règle ne s'applique.

Pourquoi le nouveau groupe ne prend effet qu'à la prochaine connexion

Un processus reçoit ses appartenances de groupe au moment de la connexion, et plus jamais ensuite. C'est pourquoi id -nG kernel exécuté en tant que root affiche le groupe sudo, alors que la même sortie dans la session de l'utilisateur ne le contient pas. Les deux résultats sont exacts : une commande lit la base des utilisateurs, l'autre la session en cours. La solution est une nouvelle connexion, pas un redémarrage. newgrp sudo n'agit que dans le shell exact où vous l'appelez.

Modifier sudoers sans risque : visudo et /etc/sudoers.d

N'ouvrez jamais /etc/sudoers directement avec un éditeur. Une erreur de syntaxe rend sudo inutilisable pour tous les utilisateurs, et si root est déjà désactivé, il ne reste que la console. visudo verrouille le fichier contre les modifications concurrentes et contrôle la syntaxe avant l'enregistrement. S'il trouve une erreur, il vous pose la question :

>>> /etc/sudoers: syntax error near line 22 <<<
What now?
Options are:
  (e)dit sudoers file again
  e(x)it without saving changes to sudoers file
  (Q)uit and save changes to sudoers file (DANGER!)

La bonne réponse est e ; le Q majuscule enregistre le fichier défectueux. Sous Debian et Ubuntu, c'est le système des alternatives qui décide de l'éditeur lancé par visudo : durablement avec update-alternatives --config editor, ponctuellement avec EDITOR=nano visudo.

Pour vos propres règles, ne touchez pas du tout à /etc/sudoers. À la fin du fichier, une ligne inclut un répertoire entier, sous la forme @includedir /etc/sudoers.d ou #includedir /etc/sudoers.d selon l'ancienneté du système. Le croisillon ressemble à un signe de commentaire, mais n'en est pas un. Ce fichier aussi, vous le créez avec visudo :

visudo -f /etc/sudoers.d/10-kernel

Les deux règles qui font échouer les fichiers du répertoire

Le nom du fichier ne doit contenir aucun point ni se terminer par un tilde. sudo ignore ces fichiers en silence, afin que des copies de sauvegarde n'attribuent pas de droits par inadvertance. 10-kernel.conf n'est donc jamais lu, et cela sans le moindre message. La forme correcte est 10-kernel.

Le fichier doit appartenir à root et ne doit être accessible en écriture ni pour le groupe ni pour les autres, le mode attendu est 0440.

chown root:root /etc/sudoers.d/10-kernel
chmod 0440 /etc/sudoers.d/10-kernel
visudo -c

visudo -c contrôle tous les fichiers inclus et affiche une ligne pour chacun :

/etc/sudoers: parsed OK
/etc/sudoers.d/10-kernel: parsed OK

C'est en même temps le meilleur test pour la première règle : si votre fichier n'apparaît pas ici, il n'est pas lu, et la cause est presque toujours un point dans le nom du fichier. En cas de droits incorrects, visudo signale plutôt /etc/sudoers.d/10-kernel: bad permissions, should be mode 0440.

NOPASSWD : ce que cela coûte vraiment

Tôt ou tard, tout le monde tombe sur cette ligne :

kernel ALL=(ALL) NOPASSWD: ALL

Elle est plus dangereuse qu'elle n'en a l'air. La demande de mot de passe est le dernier obstacle entre « quelqu'un dispose d'un shell en tant que kernel » et « quelqu'un est root ». Celui qui atteint le compte par une application web vulnérable, une clé privée copiée ou une session laissée sans surveillance devient root sans étape supplémentaire grâce à cette ligne. Avec NOPASSWD: ALL, le gain de sécurité par rapport à une connexion root directe se réduit donc à un nom d'utilisateur que l'attaquant ne connaît pas.

NOPASSWD se justifie là où personne ne peut taper au clavier : exécutions Ansible, scripts de sauvegarde, pipelines de déploiement. Mais alors de façon étroitement délimitée, et non pour la personne assise devant le terminal :

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

Trois pièges avec ce type de règles :

• Les chemins absolus sont obligatoires. Un nom de programme sans chemin ne correspond à rien.
• Sans arguments listés, tous les arguments sont autorisés. deploy ALL=(root) NOPASSWD: /usr/bin/systemctl permet n'importe quel appel de systemctl. Ce n'est qu'en écrivant aussi les arguments que la ligne de commande devra correspondre exactement. Si aucun argument ne doit être autorisé, ajoutez une paire d'arguments vide, par exemple /usr/bin/id "".
• Les jokers sont rarement aussi restrictifs qu'ils en ont l'air. /usr/bin/* autorise tous les programmes de ce répertoire et équivaut en pratique à un accès root complet.

La question la plus importante devant toute règle restreinte : la commande autorisée peut-elle lancer un autre programme ou ouvrir un shell ? Les éditeurs, les gestionnaires de paquets, les outils d'archivage et les interpréteurs en sont capables, et une règle qui autorise un éditeur via sudo autorise en pratique tout le reste.

Le meilleur compromis, c'est la durée de mémorisation : sudo conserve une saisie réussie pendant 15 minutes par défaut, séparément pour chaque terminal. Cela s'ajuste dans /etc/sudoers.d/ :

Defaults:kernel timestamp_timeout=5

sudo -k annule cette mémorisation immédiatement, sudo -v la renouvelle sans exécuter de commande.

Transférer la clé publique vers le nouvel utilisateur

Tant que l'authentification par mot de passe est active en SSH, le plus commode depuis votre poste de travail reste ssh-copy-id kernel@203.0.113.10. Si elle est déjà désactivée, la commande échoue avec Permission denied (publickey). Le chemin passe alors par la session root encore ouverte.

Le réflexe évident y est cp -r /root/.ssh /home/kernel/.ssh, et il est faux : les fichiers appartiennent ensuite à root, le serveur SSH les rejette, et la commande emporte au passage une éventuelle clé privée de root, qui n'a rien à faire sur un second compte. Transférez plutôt uniquement les clés publiques, de façon ciblée :

install -d -m 700 -o kernel -g kernel /home/kernel/.ssh
install -m 600 -o kernel -g kernel /root/.ssh/authorized_keys /home/kernel/.ssh/authorized_keys

install définit les droits et le propriétaire en une seule fois, si bien qu'aucun chown oublié ne subsiste. Si /root/.ssh/authorized_keys n'existe pas, créez le fichier cible vide et inscrivez-y la clé avec un éditeur :

install -m 600 -o kernel -g kernel /dev/null /home/kernel/.ssh/authorized_keys

Contrôle de réussite :

ls -ld /home/kernel /home/kernel/.ssh
ls -l /home/kernel/.ssh/authorized_keys
ssh-keygen -l -f /home/kernel/.ssh/authorized_keys

La dernière ligne affiche l'empreinte de chaque clé enregistrée. Comparez-la avec ssh-keygen -l -f ~/.ssh/id_ed25519.pub sur votre poste de travail. Vous savez ainsi, avant même la première tentative de connexion, que la bonne clé est bien arrivée.

Un détail qui peut coûter des heures : avec StrictModes yes, le serveur SSH ne contrôle pas seulement .ssh et authorized_keys, mais aussi le répertoire personnel. S'il est accessible en écriture pour le groupe ou pour les autres, il refuse l'authentification par clé, et le client signale seulement Permission denied (publickey). Les droits attribués par votre système figurent dans /etc/adduser.conf, sous DIR_MODE. Tout ce qui concerne l'authentification par clé elle-même se trouve dans Sécuriser SSH et mettre en place l'authentification par clé.

Le test avant de désactiver root

Quatre vérifications, et vous ne touchez à la configuration SSH qu'une fois les quatre réussies. L'ancienne session root reste ouverte.

Premièrement : une nouvelle session SSH avec le nouvel utilisateur, dans une fenêtre fraîchement ouverte, pas dans la connexion existante.

ssh kernel@203.0.113.10

On attend un shell sans demande de mot de passe. Si un mot de passe vous est demandé, la clé n'a pas fonctionné ; ssh -v montre quelles clés le client propose réellement. Si c'est déjà l'établissement de la connexion qui coince, Se connecter à un serveur en SSH vous aide à aller plus loin.

Deuxièmement : sudo dans cette nouvelle session précisément.

id
sudo -v
sudo id

id doit mentionner le groupe sudo, et sudo id doit commencer par uid=0(root). Un sudo -l -U kernel lancé depuis la session root ne remplace pas ce test : il montre ce que sudo autoriserait, pas si la connexion de l'utilisateur fonctionne.

Troisièmement : la console. Connectez-vous par la console VNC de l'espace client en tant que kernel, avec le nom d'utilisateur et le mot de passe, puis exécutez-y sudo -i. Ce test est le plus important des quatre, car la console est la voie de secours et elle ne connaît que les mots de passe.

Quatrièmement : l'état des mots de passe.

passwd -S root
passwd -S kernel

Au moins un des deux comptes doit afficher un P dans la deuxième colonne. Deux comptes verrouillés plus une configuration SSH défectueuse donnent un système que seul un système de secours permet encore d'atteindre.

Désactiver root, mais correctement

Trois mesures sont souvent mises dans le même panier, alors que leurs conséquences sont très différentes.

Pour la plupart des serveurs, prohibit-password est le bon choix : root reste joignable par clé comme roue de secours, et deviner des mots de passe reste malgré tout sans la moindre chance. Ce réglage a sa place dans un fichier dédié sous /etc/ssh/sshd_config.d/, et le contrôle de syntaxe précède chaque redémarrage du service :

sshd -t && systemctl restart ssh
sshd -T | grep -i permitrootlogin

passwd -l root est la variante la plus radicale et n'est défendable qu'une fois le troisième test ci-dessus effectué. La commande verrouille uniquement l'authentification par mot de passe : une clé SSH enregistrée continue de fonctionner, sudo -i également.

Ce qui est à déconseiller : retirer à root son shell de connexion, par exemple avec usermod -s /usr/sbin/nologin root. Cela bloque non seulement la connexion, mais aussi sudo -i et le shell d'urgence au démarrage.

Erreurs fréquentes et solutions

kernel is not in the sudoers file. : l'utilisateur n'appartient à aucun groupe couvert par une règle, ou bien la session est plus ancienne que la modification de groupe. Vérifiez id -nG kernel en tant que root, puis getent group sudo, et ouvrez ensuite une nouvelle session. Les versions plus anciennes ajoutent encore une phrase au sujet d'un incident signalé.

sudo: 3 incorrect password attempts alors que vous avez tapé correctement : le compte n'a tout simplement pas de mot de passe, typiquement parce qu'il a été créé avec --disabled-password. passwd -S kernel affiche alors L ou NP, et passwd kernel règle le problème. Par ailleurs, sudo demande le mot de passe de l'utilisateur qui l'appelle, pas celui de root.

sudo: no tty present and no askpass program specified : il n'existe aucun terminal sur lequel sudo pourrait poser sa question. Typique avec ssh server 'sudo commande' et dans les tâches cron. En SSH, ssh -t aide, et dans une tâche cron, l'entrée a sa place dans la crontab de root.

sudo: /etc/sudoers.d/10-kernel is mode 0644, should be 0440 : droits incorrects sur le fichier de règles. chmod 0440 corrige cela ; jusque-là, la règle reste sans effet.

/etc/sudoers.d/10-kernel: bad permissions, should be mode 0440 : même cause, signalée cette fois par visudo -c. Utilisez cette commande après chaque modification.

Le fichier de règles n'apparaît pas du tout dans la sortie de visudo -c : le nom du fichier contient un point ou se termine par un tilde. Renommez 10-kernel.conf en 10-kernel.

usermod: group 'sudo' does not exist : vous travaillez sur un système de la famille RHEL. Le groupe d'administration s'y appelle wheel, ce que confirme getent group wheel.

Permission denied (publickey) avec le nouvel utilisateur, alors que root parvient toujours à se connecter : ce sont presque toujours les droits. /home/kernel/.ssh doit être en 700, authorized_keys en 600, les deux doivent appartenir à l'utilisateur, et le répertoire personnel ne doit être accessible en écriture ni pour le groupe ni pour les autres. La cause figure dans le journal :

journalctl -t sshd -n 50 --no-pager

Cherchez une ligne qui commence par Authentication refused: bad ownership or modes for directory et qui nomme le répertoire concerné.

sudo: unable to resolve host srv01: Name or service not known : le hostname manque dans /etc/hosts. sudo fonctionne malgré tout, mais avec un retard perceptible. L'entrée qui convient figure dans la checklist du serveur root.

Et si le compte doit disparaître à nouveau : gpasswd -d kernel sudo ne retire que les droits, tandis que deluser --remove-home kernel ou userdel -r kernel le supprime avec son répertoire personnel.

Les différences entre distributions en un coup d'œil

En bref

1. Préparer le chemin de retour : garder une deuxième session root ouverte, essayer une fois la console VNC dans l'espace client, connaître le mot de passe root.
2. apt-get install -y sudo si command -v sudo ne renvoie rien.
3. adduser --disabled-password --gecos "" kernel, puis passwd kernel, pour que la console reste utilisable.
4. usermod -aG sudo kernel, et wheel sur les systèmes de la famille RHEL. Le -a est obligatoire.
5. Transférer la clé publique avec install : répertoire en 700, fichier en 600, propriétaire le nouvel utilisateur.
6. Créer vos propres règles uniquement avec visudo -f dans /etc/sudoers.d/, nom de fichier sans point, mode 0440, puis visudo -c.
7. Vérifier : sudo -l -U kernel, nouvelle session SSH, sudo id, connexion à la console avec le mot de passe.
8. Ne toucher à PermitRootLogin qu'après cela.

Un utilisateur doté des droits sudo vous épargne le sinistre total involontaire et fait disparaître le nom d'utilisateur le plus connu. Contre les ports ouverts, c'est le pare-feu UFW qui aide, et contre les attaques qui saturent le raccordement réseau, seul un filtrage placé en amont dans le réseau, chez KernelHost dans le datacenter maincubes de Francfort-sur-le-Main. Sur le serveur lui-même, votre tâche reste la plus modeste et en même temps la plus efficace : faire en sorte qu'un seul compte dispose exactement des droits dont il a besoin.