Ajouter un utilisateur sudo sous Linux sans ouvrir trop de droits

Ajouter un utilisateur sudo sous Linux ne consiste pas seulement à donner un accès administrateur. C'est une décision de sécurité : le compte pourra installer des paquets, modifier des services, lire des fichiers sensibles ou changer la configuration du système.

La bonne méthode dépend de la distribution, du niveau d'accès attendu et du contexte d'exploitation. Sur un poste de test, l'ajout au groupe sudo peut suffire. Sur un serveur partagé ou de production, il vaut mieux penser moindre privilège, traçabilité et procédure de retour arrière, car un accès administrateur oublié peut rester exploitable longtemps après la fin du besoin initial.

Le principe reste simple : créer un compte personnel, lui accorder seulement les droits nécessaires, tester l'accès dans une session séparée et éviter toute modification directe dangereuse du fichier sudoers.

Avant de créer le compte, décider du niveau de droit

La première question n'est pas la commande à taper. C'est le niveau de confiance que vous accordez au futur utilisateur.

Un administrateur système peut avoir besoin d'un accès large. Un développeur peut seulement devoir redémarrer un service. Un prestataire peut avoir un accès temporaire limité à quelques commandes. Ces trois cas ne méritent pas la même règle sudo, même s'ils commencent tous par la création d'un compte Linux. La bonne question n'est donc pas "comment donner sudo vite ?", mais "quel périmètre suffit pour travailler sans exposer tout le système ?"

Sur un serveur critique, donner un accès complet parce que c'est plus rapide revient à déplacer le risque. Si le compte est compromis, mal utilisé ou partagé, l'attaquant dispose d'un chemin direct vers les droits root. Le temps gagné à la création peut se payer cher lors d'un incident, surtout si aucune revue ne permet d'expliquer pourquoi l'accès a été accordé, par qui et pour quelle durée précise.

Avant d'agir, notez donc le besoin exact : durée de l'accès, commandes nécessaires, groupe cible, personne responsable, date de revue et procédure de retrait. Cette mini-fiche évite de laisser des comptes sudo actifs longtemps après la fin d'une intervention, surtout dans les infrastructures où plusieurs personnes peuvent créer des accès sans coordination parfaite. La meilleure commande reste celle que vous pourrez expliquer clairement lors d'un audit.

Créer un utilisateur Linux proprement

Sur la plupart des distributions, commencez par créer le compte avec un mot de passe initial, puis forcez éventuellement le changement de mot de passe à la première connexion.

Sur Debian et Ubuntu, la commande interactive la plus simple reste adduser. Elle crée le dossier personnel, demande un mot de passe et prépare un compte exploitable sans multiplier les options. Pour un serveur automatisé, useradd reste possible, mais il demande plus de paramètres pour obtenir le même résultat. Cette différence explique pourquoi deux tutoriels Linux peuvent être corrects tout en utilisant des commandes différentes, selon la famille de distribution et les conventions locales.

sudo adduser alice

Sur une distribution Red Hat, Rocky Linux ou AlmaLinux, vous utiliserez souvent useradd, puis passwd pour définir le mot de passe. L'important n'est pas de mémoriser une variante unique : il faut vérifier la convention de votre distribution et la politique interne de création de comptes.

sudo useradd -m alice
sudo passwd alice

Donnez un nom de compte stable, lisible et personnel. Évitez admin2, prestataire ou support si plusieurs personnes peuvent l'utiliser. Un compte nommé, associé à une personne et retiré quand il n'est plus nécessaire, offre une trace beaucoup plus exploitable.

Si le serveur est accessible en SSH, préparez aussi l'authentification. Un accès sudo avec un mot de passe faible ou réutilisé reste dangereux. Dans un contexte professionnel, privilégiez une clé SSH personnelle, désactivez les comptes inutiles et vérifiez que le nouvel utilisateur ne reçoit pas plus d'accès réseau que nécessaire. Le droit sudo ne doit pas masquer une porte d'entrée SSH mal cadrée, surtout sur un serveur exposé.

sudo mkdir -p /home/alice/.ssh
sudo cp /tmp/alice.pub /home/alice/.ssh/authorized_keys
sudo chown -R alice:alice /home/alice/.ssh
sudo chmod 700 /home/alice/.ssh
sudo chmod 600 /home/alice/.ssh/authorized_keys

Ces commandes ne remplacent pas une politique SSH complète, mais elles rappellent un point important : l'accès système et l'accès sudo doivent être pensés ensemble. Un compte sans clé, sans mot de passe solide ou sans procédure de retrait devient rapidement un point d'entrée durable. Avant de parler sudoers, vérifiez donc aussi le mode d'authentification et la politique SSH.

Ajouter l’utilisateur au bon groupe sudo

Une fois le compte créé, l'accès sudo passe souvent par un groupe déjà prévu par la distribution.

Pour approfondir ce point, consultez Sudo sous Linux, méthode fiable pour administrer, qui traite plus précisément de sudo sous linux, méthode fiable pour administrer sans ouvrir la porte root.

Sur Debian et Ubuntu, le groupe s'appelle généralement sudo. Ajouter l'utilisateur à ce groupe lui permet d'exécuter des commandes avec sudo, selon la règle installée par défaut dans sudoers. La commande la plus courante est courte.

sudo usermod -aG sudo alice

Le -aG est important : il ajoute le groupe sans remplacer les autres appartenances. Oublier -a peut retirer l'utilisateur de groupes utiles, ce qui crée parfois des pannes indirectes difficiles à relier à la commande initiale. C'est un détail court, mais c'est aussi une erreur d'administration classique, notamment sur des comptes déjà membres de groupes applicatifs, techniques ou métiers.

Sur les distributions de la famille Red Hat, le groupe peut être wheel. La commande ressemble donc à ceci, à condition que la règle wheel soit active dans sudoers.

sudo usermod -aG wheel alice

Après cette étape, l'utilisateur doit ouvrir une nouvelle session pour que ses groupes soient pris en compte. Une session SSH déjà ouverte peut encore voir l'ancien état. C'est une cause fréquente de diagnostic faux : le groupe est bien configuré, mais la session courante ne l'a pas encore chargé. Avant de modifier sudoers, commencez donc par tester depuis une connexion vraiment neuve, avec le compte cible et son environnement réel complet.

Pour vérifier sans ambiguïté, comparez l'état vu depuis votre session d'administration et celui vu depuis le compte cible. La commande id alice lancée en root montre les groupes déclarés, tandis que id dans la session d'Alice montre les groupes réellement chargés.

Tester l’accès sans fermer la session root

Ne quittez pas votre session d'administration tant que le nouveau compte n'a pas été testé. Cette précaution évite de vous enfermer dehors après une erreur de groupe ou de sudoers.

Ouvrez une seconde session avec le nouvel utilisateur, ou utilisez su - alice si le contexte s'y prête. Vérifiez ensuite l'appartenance aux groupes, puis demandez à sudo de valider les droits sans lancer une opération destructive.

id alice
sudo -v
sudo whoami

Si la commande sudo whoami répond root, l'accès fonctionne. Ce test reste volontairement neutre : il ne redémarre pas de service, ne modifie pas de fichier et ne change pas la configuration. Il confirme seulement que la chaîne d'autorisation répond comme prévu.

En cas d'échec, lisez le message exact. alice is not in the sudoers file indique souvent une absence de règle ou de groupe reconnu. Un refus de mot de passe pointe plutôt vers un problème d'identifiant, de clavier, de compte verrouillé ou d'expiration. Les messages sudo sont généralement assez explicites ; les ignorer pousse souvent à créer des règles inutiles.

Lister ce que sudo autorise vraiment

Un test qui renvoie root prouve que sudo fonctionne, mais il ne dit pas toujours quelle règle a été appliquée. Pour comprendre les droits réels, utilisez sudo -l depuis le compte concerné.

sudo -l

Cette commande liste les privilèges disponibles pour l'utilisateur courant : accès complet, commandes limitées, obligation ou non de mot de passe, hôte concerné, utilisateur cible. Elle est très utile après une modification de sudoers, car elle révèle la règle effectivement interprétée par sudo. Elle peut aussi montrer qu'une règle héritée donne déjà plus de droits que prévu, ce qui évite d'ajouter une règle redondante ou contradictoire.

Sur un parc administré, gardez une copie de cette sortie dans votre ticket de changement ou votre documentation d'exploitation. Elle donne une preuve simple du périmètre accordé au moment de la création, puis facilite la comparaison lors d'une revue d'accès.

Utiliser visudo pour les règles sudoers

Modifier /etc/sudoers directement avec un éditeur classique est une mauvaise habitude. Une erreur de syntaxe peut casser sudo et compliquer la reprise.

La commande visudo ouvre le fichier avec un contrôle de syntaxe avant enregistrement. C'est le garde-fou minimum pour toute modification de règles sudoers. Sur un serveur, cette protection vaut quelques secondes de plus.

sudo visudo

Pour des règles spécifiques, préférez souvent un fichier dédié dans /etc/sudoers.d/. Cela sépare les exceptions, facilite la revue et évite de transformer le fichier principal en mélange de règles historiques. Le fichier doit rester lisible, avec des permissions adaptées.

Une règle simple peut autoriser un utilisateur à exécuter une commande précise. Cette granularité est plus sûre qu'un accès complet, mais elle doit être testée soigneusement, car certaines commandes permettent d'ouvrir un shell, d'écrire des fichiers ou de contourner l'intention initiale. Le chemin absolu de la commande compte autant que le nom affiché dans un tutoriel, et les arguments autorisés doivent rester cohérents avec le besoin documenté, pas seulement avec l'urgence du jour.

alice ALL=(root) /usr/bin/systemctl restart nginx

Éviter les pièges qui affaiblissent la sécurité

Le piège le plus visible consiste à multiplier les administrateurs complets. Plus il y a de comptes sudo larges, plus la surface d'attaque augmente.

Le deuxième piège est le compte partagé. Il semble pratique pour une équipe, mais il détruit la traçabilité. En cas d'erreur ou d'incident, vous ne savez plus qui a lancé la commande. Un compte personnel avec sudo est plus propre qu'un compte générique avec un mot de passe connu de plusieurs personnes.

Le troisième piège concerne les règles trop généreuses. Autoriser un éditeur, un interpréteur, un gestionnaire de fichiers ou une commande capable d'exécuter un shell peut revenir à donner un accès root indirect. Le moindre privilège demande donc de comprendre la commande autorisée, pas seulement son nom.

• Ne donnez pas sudo à un compte dont le mot de passe est faible ou partagé.
• Ne modifiez pas sudoers sans visudo.
• Ne laissez pas un accès temporaire devenir permanent par oubli.
• Ne copiez pas une règle sudoers sans comprendre les chemins de commande.
• Ne fermez pas la session d'administration avant d'avoir testé le nouveau compte.

Faites aussi attention aux options NOPASSWD. Elles peuvent être utiles pour une automatisation précise, mais elles suppriment un frein important. Si vous les utilisez, limitez le périmètre à une commande exacte et documentez clairement la raison de l'exception.

Diagnostiquer les erreurs sudo courantes

Quand sudo refuse l'accès, commencez par vérifier les groupes. La commande id alice montre les appartenances réelles de l'utilisateur. Si le groupe attendu n'apparaît pas, vérifiez la commande usermod, puis ouvrez une nouvelle session.

Si le groupe est présent, vérifiez ensuite la règle sudoers. Sur Debian ou Ubuntu, une ligne donnant les droits au groupe sudo doit exister. Sur une distribution Red Hat-like, la ligne wheel peut être commentée selon l'installation. Dans ce cas, le groupe seul ne suffit pas.

Si sudo demande sans cesse un mot de passe ou refuse malgré une règle correcte, regardez l'état du compte, l'expiration du mot de passe, les politiques PAM et les journaux système. Les logs donnent souvent le nom de l'utilisateur, la commande demandée et la raison du refus.

Auditer et retirer les accès devenus inutiles

Créer un accès sudo n'est que la moitié du travail. Il faut aussi savoir le revoir et le retirer.

Planifiez une revue périodique des comptes membres de sudo ou wheel, ainsi que des fichiers placés dans /etc/sudoers.d/. Un compte d'ancien prestataire, une règle temporaire ou un utilisateur de test oublié peut rester actif longtemps si personne ne l'intègre à une revue formelle. La liste des membres et les règles dédiées doivent être relues ensemble, car un retrait de groupe ne supprime pas forcément une exception nominative persistante.

Pour retirer un utilisateur du groupe sudo sur Debian ou Ubuntu, utilisez deluser ou gpasswd selon vos habitudes. Sur les systèmes utilisant wheel, adaptez le groupe. Testez ensuite que l'accès n'est plus disponible, car une règle nominative dans sudoers.d peut encore donner des droits malgré le retrait du groupe. Le retrait doit donc contrôler toutes les sources de privilèges.

sudo deluser alice sudo
sudo gpasswd -d alice wheel

Conservez aussi les journaux nécessaires à l'audit. Les commandes sudo laissent des traces qui peuvent aider à comprendre une opération sensible, mais elles ne remplacent pas une gouvernance claire des accès. La sécurité tient autant à la procédure de revue qu'à la commande de création.

Dans une équipe, associez chaque ajout sudo à un ticket ou à une demande validée. Le jour où il faut expliquer pourquoi un compte a reçu des droits élevés, la trace de décision vaut autant que la trace technique, car elle relie la commande exécutée au besoin métier qui l'a justifiée.

Une méthode courte pour intervenir sans improviser

Quand vous devez créer l'accès rapidement, gardez une séquence fixe. Elle évite de mélanger création de compte, ajout de groupe, test sudo et configuration SSH dans le désordre. D'abord, créez le compte. Ensuite, ajoutez le groupe ou la règle. Puis ouvrez une session fraîche avec l'utilisateur cible. Enfin, contrôlez les droits avec sudo -l et un test neutre, avant toute commande destructive.

Arrêtez-vous si une étape ne correspond pas au résultat attendu. Ne compensez pas un refus sudo en ajoutant plusieurs règles au hasard. Un accès qui ne fonctionne pas a presque toujours une cause simple : mauvais groupe, session non renouvelée, règle commentée, chemin de commande incorrect, mot de passe expiré ou syntaxe sudoers invalide. Corrigez la cause, pas seulement le symptôme.

Le bon réflexe est de documenter la correction. Notez le groupe utilisé, la règle ajoutée, le test validé et la date de revue. Cette discipline paraît administrative, mais elle rend les audits beaucoup plus rapides et évite de découvrir six mois plus tard un accès root accordé sans raison claire.

La commande pour ajouter un utilisateur sudo est rapide. La vraie qualité se joue dans le cadrage : donner le bon niveau de droit, tester sans se verrouiller dehors, modifier sudoers avec prudence et retirer les accès qui ne servent plus.

Pour un poste de travail ou un petit serveur, le groupe sudo ou wheel peut suffire. Pour une infrastructure professionnelle, une règle ciblée, une revue régulière et des comptes personnels restent plus sûrs qu'un accès administrateur distribué par facilité. La différence tient moins à la commande qu'à la gouvernance des privilèges.

Pour approfondir ce point, consultez chmod linux permissions, qui traite plus précisément de utiliser chmod sans ouvrir trop largement ses fichiers linux.