Adduser sudo Debian : la bonne méthode

Il y a six semaines, un client parisien qui gère une PME de e-commerce m’a appelé un dimanche soir parce que son serveur Debian venait de refuser une connexion SSH à son responsable technique. Pas un piratage, pas une panne réseau : juste un compte root partagé entre quatre personnes depuis trois ans, plus le compte d’un ancien alternant parti huit mois plus tôt qui avait toujours les droits sudo complets. Ce genre de situation, je le vois en moyenne sur un serveur sur trois quand j’audite l’infrastructure d’un nouveau client. Dans cet article, je vous montre le diagnostic que j’ai fait, la méthode complète pour créer proprement un utilisateur sudo sur Debian, et les erreurs de sécurité qui reviennent tout le temps sur le terrain.

Je m’appelle Laurent, je suis basé à Chiang Mai en Thaïlande, et depuis 2008 j’accompagne des PME françaises sur leur infrastructure serveur et leur SEO technique. Ce que je décris ici n’est pas de la théorie de documentation officielle : c’est une intervention réelle, avec les commandes exactes que j’ai tapées et les résultats mesurés à la fin.

Le contexte : un serveur Debian géré comme en 2012

Le client exploitait un VPS Debian 12 hébergeant une boutique PrestaShop et son back-office de gestion de stock. L’infrastructure avait été montée par un prestataire qui avait quitté le projet, et personne en interne n’avait de vue claire sur qui avait accès à quoi. Trois symptômes m’ont mis la puce à l’oreille dès le premier appel :

• Tout le monde se connectait avec ssh root@serveur et un mot de passe partagé sur un fichier texte dans un Google Drive commun.
• Le compte de l’ancien alternant (identifiant « stagiaire2025 ») existait toujours, avec accès sudo complet, mot de passe jamais changé depuis son départ.
• Personne ne savait dire qui avait modifié un fichier de configuration Nginx la semaine précédente, provoquant une coupure de 40 minutes du site en pleine période de soldes.

C’est ce dernier point, très concret et chiffré en perte de chiffre d’affaires (le client a estimé la coupure à environ 1 800 € de ventes manquées), qui a débloqué le budget pour l’intervention. En 15 ans de terrain, j’ai remarqué que les clients réagissent rarement à « c’est une mauvaise pratique » — ils réagissent à un chiffre de perte.

Diagnostic : ce que j’ai trouvé en une heure d’audit

Première chose que je fais systématiquement sur un nouveau serveur : lister les comptes existants et vérifier qui a des droits d’administration. La commande est simple mais elle révèle énormément :

getent passwd | awk -F: '$3 >= 1000 {print $1, $3, $6}'
grep '^sudo:' /etc/group
cat /etc/sudoers.d/* 2>/dev/null

Résultat chez ce client : trois comptes utilisateurs « nommés » créés à la va-vite par l’ancien prestataire, un compte root utilisé activement en SSH (ce qu’on voit dans /var/log/auth.log avec des lignes Accepted password for root), et le fameux compte « stagiaire2025 » toujours membre du groupe sudo. Aucune authentification par clé SSH n’était en place — tout se faisait par mot de passe, y compris pour root. C’est la combinaison la plus dangereuse que je rencontre : accès root direct + mot de passe + comptes fantômes.

Petit aparté technique pour les non-initiés : sudo (substitute user do) est un mécanisme qui permet à un utilisateur normal d’exécuter des commandes avec les droits d’administrateur, de façon tracée et limitée, sans jamais se connecter directement en tant que root. C’est la différence entre donner les clés du camion à quelqu’un pour un trajet précis, et lui laisser le camion en permanence avec le moteur allumé.

Étape 1 : créer un utilisateur proprement avec adduser

Sur Debian, on utilise adduser plutôt que useradd. C’est un point sur lequel j’insiste toujours auprès des clients qui viennent de CentOS ou d’un tutoriel générique Linux : useradd est la commande bas niveau, adduser est un script Debian interactif qui crée automatiquement le répertoire home, copie les fichiers de configuration par défaut, et demande le mot de passe proprement. Moins d’oublis, moins d’erreurs.

sudo adduser jdupont

La commande va demander un mot de passe (à choisir robuste, 16 caractères minimum, jamais réutilisé ailleurs — je fournis toujours un générateur type pwgen -sy 20 1 à mes clients) puis des informations optionnelles (nom complet, téléphone). Vous pouvez appuyer sur Entrée pour passer ces champs, ils ne sont pas critiques.

Chez ce client, j’ai créé un compte nominatif par personne ayant réellement besoin d’un accès : le développeur backend, le responsable technique, et moi-même en tant que prestataire (compte que je désactive systématiquement à la fin de chaque mission, voir plus bas). Trois comptes au lieu d’un compte root partagé et de trois comptes fantômes.

Étape 2 : ajouter l’utilisateur au groupe sudo

Sur Debian, contrairement à Ubuntu où c’est parfois pré-configuré, le paquet sudo n’est pas toujours installé par défaut selon le type d’installation. Je vérifie d’abord :

dpkg -l | grep sudo || sudo apt update && sudo apt install sudo -y

Puis j’ajoute l’utilisateur au groupe sudo avec usermod (ici on repasse en commande bas niveau, adduser ne gère pas l’ajout à un groupe existant de façon aussi directe) :

sudo usermod -aG sudo jdupont

Le flag -a (append) est non négociable. Sans lui, usermod -G remplace tous les groupes secondaires de l’utilisateur par le seul groupe indiqué — j’ai vu un client casser l’accès www-data d’un compte de déploiement en oubliant ce flag, ce qui a cassé le pipeline CI le lendemain matin. Vérification immédiate après la commande :

groups jdupont
id jdupont

Vous devez voir « sudo » dans la liste des groupes. Si ce n’est pas le cas, la session SSH en cours de l’utilisateur doit être fermée et rouverte — les groupes sont chargés à la connexion, pas à chaud.

Étape 3 : authentification par clé SSH avant de couper le mot de passe

C’est l’étape que 80% des tutoriels bâclent, et c’est exactement ce qui manquait chez mon client. Un compte sudo protégé uniquement par mot de passe reste vulnérable au bruteforce, même avec fail2ban. La clé SSH doit être en place et testée avant de désactiver quoi que ce soit d’autre.

Sur la machine du client (pas sur le serveur), génération d’une paire de clés Ed25519 — plus rapide et plus sûr que RSA sur les longueurs équivalentes :

ssh-keygen -t ed25519 -C "[email protected]"

Puis copie de la clé publique sur le serveur :

ssh-copy-id -i ~/.ssh/id_ed25519.pub jdupont@ip-du-serveur

Action immédiate à faire dans les 24h suivant la création de tout compte sudo : tester la connexion par clé dans un second terminal, sans fermer la session actuelle. Si la connexion par clé échoue et que vous avez déjà coupé l’accès par mot de passe ou l’accès root, vous êtes verrouillé dehors du serveur. Je ne compte plus les tickets de récupération d’urgence via console KVM du fournisseur d’hébergement pour cette exact erreur.

ssh -i ~/.ssh/id_ed25519 jdupont@ip-du-serveur

Une fois connecté par clé et confirmé que sudo whoami renvoie bien root, on peut passer à la suite.

Étape 4 : désactiver la connexion root en SSH

Édition du fichier de configuration SSH :

sudo nano /etc/ssh/sshd_config

Trois lignes à vérifier ou ajouter :

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Redémarrage du service, jamais un simple reload sur ce fichier précis, pour être certain que la config est bien rechargée :

sudo systemctl restart ssh

Piège de sécurité classique à ce stade : redémarrer le service SSH avant d’avoir validé que la connexion par clé fonctionne pour au moins un compte sudo. Je garde toujours une session root ouverte en arrière-plan (sans rien exécuter) pendant que je teste une nouvelle connexion dans un terminal séparé. Si ça casse, la session ouverte permet de revenir en arrière sans passer par la console d’urgence du VPS.

Étape 5 : nettoyer le fichier sudoers correctement

Ne jamais éditer /etc/sudoers directement avec un éditeur classique — une erreur de syntaxe peut casser sudo pour tout le système. La bonne commande est visudo, qui valide la syntaxe avant d’enregistrer :

sudo visudo

Pour ce client, j’ai plutôt créé un fichier dédié dans /etc/sudoers.d/ plutôt que de toucher le fichier principal — c’est la pratique que je recommande systématiquement, car elle isole les règles personnalisées et facilite l’audit :

sudo visudo -f /etc/sudoers.d/jdupont

Contenu type, avec obligation de mot de passe à chaque usage de sudo (je déconseille NOPASSWD sauf cas très spécifique de script automatisé identifié) :

jdupont ALL=(ALL:ALL) ALL

Le fichier doit être en permissions 0440, ce que visudo applique automatiquement à la création. Vérification :

sudo visudo -c

Cette commande contrôle la syntaxe de tous les fichiers sudoers sans les modifier — je la lance systématiquement après toute intervention sur les droits, même en fin de journée quand la fatigue augmente le risque de faute de frappe.

Étape 6 : supprimer les comptes fantômes

C’est là qu’on traite le cas du « stagiaire2025 ». Avant suppression, je vérifie toujours ce que le compte possède comme fichiers et process actifs, pour éviter de perdre des données utiles :

sudo find / -user stagiaire2025 -type f 2>/dev/null
ps -u stagiaire2025

Aucun process actif chez ce client, et le home ne contenait que des scripts de déploiement obsolètes que j’ai archivés avant suppression. Retrait immédiat du groupe sudo (à faire même si la suppression suit dans la foulée — principe de moindre privilège appliqué à chaque étape) puis suppression complète du compte et de son répertoire home :

sudo gpasswd -d stagiaire2025 sudo
sudo deluser --remove-home stagiaire2025

Action à faire dans les 24h pour tout départ d’un collaborateur ayant eu un accès serveur, sans exception : révocation immédiate des droits sudo, puis suppression du compte sous 7 jours maximum après vérification qu’aucun processus ou tâche cron ne dépend de ce compte. J’ai vu des entreprises garder des comptes d’anciens salariés « au cas où » pendant des années — c’est une surface d’attaque qui ne rapporte jamais rien.

Les pièges de sécurité que j’ai évités sur cette intervention

Quatre points de vigilance qui reviennent sur presque tous les serveurs Debian mal administrés que j’audite :

• Ne jamais couper PasswordAuthentication avant d’avoir testé la clé SSH depuis un terminal frais. Un test dans le même terminal où la clé a été chargée en mémoire (agent SSH) peut donner un faux sentiment de sécurité.
• Fail2ban en complément, pas en remplacement. Même avec authentification par clé uniquement, j’installe systématiquement fail2ban pour limiter le bruit des tentatives de connexion automatisées sur le port SSH, et je change le port par défaut sur les serveurs exposés publiquement.
• Ne jamais donner ALL=(ALL:ALL) ALL par réflexe. Pour un compte de déploiement automatisé (CI/CD), je restreins sudo à une liste précise de commandes dans le fichier sudoers.d dédié, jamais un accès total.
• Historiser qui a accès à quoi. J’ai mis en place pour ce client un fichier de suivi (hors serveur, dans leur gestionnaire de mots de passe d’équipe) listant chaque compte, sa date de création, son rôle, et une revue trimestrielle obligatoire.

Sur ce dernier point, je recommande à tous mes clients PME une revue d’accès tous les trois mois — ça prend 20 minutes et ça évite exactement le genre de situation qui m’a fait intervenir un dimanche soir.

Résultats mesurés après intervention

Voici le bilan chiffré de cette intervention, réalisée en une session de 3h30 :

• 4 comptes nettoyés : 1 compte root partagé désactivé pour la connexion SSH, 1 compte fantôme supprimé, 2 comptes recréés proprement avec authentification par clé.
• 0 mot de passe SSH actif sur le serveur après intervention, contre 4 avant (tous partagés ou obsolètes).
• Temps de résolution d’incident passé de plus de 45 minutes (personne ne savait qui avait accès, ni comment retracer une action) à moins de 5 minutes lors d’un test réalisé trois semaines plus tard, grâce aux logs sudo nominatifs dans /var/log/auth.log qui permettent désormais d’identifier immédiatement l’auteur d’une commande.
• Tentatives de connexion SSH bloquées par fail2ban : environ 60 par jour en moyenne sur les deux semaines suivant l’intervention, contre un serveur qui acceptait auparavant toute tentative jusqu’à épuisement des essais de mot de passe.

Le point le plus parlant pour le client a été la traçabilité : la semaine suivant l’intervention, une modification de configuration Nginx a de nouveau posé problème, mais cette fois j’ai pu identifier en moins de 5 minutes, via sudo grep jdupont /var/log/auth.log, qui avait exécuté quelle commande et à quelle heure. Sans les comptes nominatifs et sudo correctement configuré, cette information n’existait tout simplement pas.

Check-list à appliquer dès aujourd’hui

Si vous gérez un serveur Debian et que vous n’êtes pas certain de la propreté de vos accès, voici l’ordre exact que j’applique, à faire dans les 24 heures si vous avez le moindre doute :

1. Lister les comptes existants et les membres du groupe sudo (getent passwd, grep sudo /etc/group).
2. Créer un compte nominatif par personne avec adduser, jamais de compte partagé.
3. Ajouter au groupe sudo avec usermod -aG sudo (attention au flag -a).
4. Configurer et tester l’authentification par clé SSH avant toute autre modification.
5. Désactiver PermitRootLogin et PasswordAuthentication seulement après validation de la clé.
6. Nettoyer sudoers via visudo, avec un fichier dédié par utilisateur dans sudoers.d.
7. Supprimer sous 7 jours tout compte d’une personne ayant quitté le projet.
8. Planifier une revue d’accès trimestrielle.

Ce n’est pas une liste théorique : c’est exactement la séquence que j’ai suivie chez ce client, dans cet ordre, avec les vérifications intermédiaires à chaque étape. La sécurité des accès serveur n’est pas un projet ponctuel, c’est une hygiène récurrente — et sur les PME que j’accompagne, c’est presque toujours le premier chantier qui révèle ensuite d’autres angles morts (sauvegardes non testées, mises à jour système en retard, monitoring absent).

Si vous avez un doute sur l’état de vos accès serveur, l’audit prend rarement plus d’une heure et il vaut mieux le faire un mardi après-midi tranquille que de le découvrir un dimanche soir comme mon client.