Créer un compte sous Linux paraît anodin, jusqu’au jour où un audit sécu ou une migration de fichiers révèle un chaos d’UID qui ne collent pas, de groupes fantômes et de comptes sans mot de passe. La commande useradd se trouve exactement au cœur de ce sujet : tout ce qui tourne autour de la gestion utilisateurs en ligne de commande se joue dans quelques options bien choisies ou oubliées. Sur un petit serveur perso, ça passe encore. Sur un parc d’entreprise ou un hébergement partagé, la moindre incohérence se paye un jour ou l’autre.
L’objectif ici : montrer comment utiliser useradd Linux de façon propre, reproductible et sécurisée, sans tomber dans la parodie d’usine à gaz. On va voir quand préférer useradd à adduser, quelles options useradd deviennent vite indispensables dans la vraie vie, comment lier la création de compte avec la gestion des mots de passe, et comment éviter les pièges classiques qui font perdre des heures de debugging. Le tout avec des exemples concrets et des scénarios qui parlent à n’importe qui a déjà dû créer des comptes pour des devs, des prestataires, des batchs ou des services techniques.
En bref
- useradd est l’outil de base pour la création compte scriptable en ligne de commande, là où adduser joue la carte interactive.
- Sans options explicites, un compte peut se retrouver sans home, sans bon shell ou sans mot de passe actif, ce qui complique vite la gestion utilisateurs.
- Les options useradd comme -m, -s, -u, -G, -e ou -d conditionnent directement la sécurité et la lisibilité du parc.
- Une politique claire sur les UIDs, les groupes et les shells évite les sueurs froides lors des migrations de données ou des audits de sécurité.
- L’enchaînement useradd + passwd (ou useradd avec mot de passe chiffré) reste la base pour des comptes opérationnels mais contrôlés.
useradd Linux vs adduser : quelle commande choisir pour la création de compte et pourquoi ça change tout
Sur un serveur Ubuntu ou Debian fraîchement installé, beaucoup découvrent très vite deux commandes apparemment jumelles : useradd et adduser. À première vue, toutes les deux créent un utilisateur, donc pourquoi se compliquer la vie ? En pratique, leur philosophie est radicalement différente, et ce choix influe sur toute la stratégie de gestion utilisateurs.
adduser fonctionne comme un petit assistant en mode texte. Quand tu le lances, il te pose une série de questions : login, nom complet, création du répertoire personnel, choix du mot de passe, etc. Pour un admin qui ajoute trois comptes par an sur un serveur maison, c’est confortable, pas besoin de se souvenir de toutes les options useradd. Le script se charge de créer le home, de mettre en place le groupe, et même de demander un mot de passe dans la foulée.
useradd, lui, joue la carte « brut ». Il ne pose aucune question. Tu passes tout par options, ou tu acceptes des valeurs par défaut définies dans la configuration système. Résultat : un useradd mal utilisé peut créer un utilisateur sans home, avec un shell rustique, sans appartenance de groupe cohérente. C’est exactement ce qu’il faut pour l’automatisation, beaucoup moins rassurant pour les usages ponctuels.
Un cas assez typique : la petite structure « TechFlore » démarre avec un seul admin, tout se fait à la main avec adduser. L’équipe grossit, l’infra s’industrialise, Ansible arrive pour déployer les nouveaux serveurs. Les playbooks utilisent naturellement useradd pour tout automatiser. Trois ans plus tard, on se retrouve avec des comptes historiques créés via adduser (home dans /home, shell bash, groupes créés automatiquement), et une génération plus récente de comptes techniques créés via useradd sans stratégie claire. Certains n’ont pas de home, d’autres ont /bin/sh, voire un shell bloquant, et les UIDs partent dans tous les sens.
À ce stade, chaque audit de sécurité se transforme en enquête archéologique : pourquoi ce compte a-t-il un home, et celui-ci non ? Pourquoi deux comptes ont-ils des UIDs différents sur deux serveurs censés être identiques ? Ces décalages viennent rarement de grandes décisions techniques, mais plutôt de ce mélange des deux outils sans ligne directrice.
En pratique, pour garder une infra lisible sur le long terme, plusieurs choix se dessinent :
- Comptes humains, création ponctuelle sur un petit serveur : adduser reste confortable et lisible pour un admin unique.
- Comptes de service, batchs, automation CI/CD, déploiements : useradd gagne haut la main, car tout est scriptable et reproductible.
- Parc de serveurs en entreprise : se fixer une règle (useradd partout, ou adduser uniquement pour l’onboarding manuel) et la documenter.
Pour clarifier les comportements concrets des deux commandes, un tableau comparatif aide à trancher sans passer deux heures dans les manpages.
| Commande | Type d’usage | Interaction | Home par défaut | Scénario recommandé |
|---|---|---|---|---|
| useradd | Automatisation, comptes techniques, parcs homogènes | Non interactif | Souvent non, sans option -m | Scripts, déploiements, gestion stricte des UIDs |
| adduser | Administration manuelle, comptes humains isolés | Interactif (questions successives) | Oui, dans /home par défaut | Serveurs gérés à la main, petits environnements |
Un point souvent sous-estimé : quand une équipe choisit useradd Linux comme brique centrale, tout ce qui touche à la création compte devient documentable et versionnable dans Git. Chaque option, chaque groupe et chaque shell se retrouve dans un script, auditable par les pairs. Pour une équipe qui tourne, c’est bien plus sain que des créations manuelles au fil de l’eau.
Fichiers système touchés par useradd et impact réel sur la gestion utilisateurs Linux
Derrière chaque useradd réussi, plusieurs fichiers critiques du système bougent. On pense souvent à /etc/passwd et /etc/shadow, mais ce n’est que la surface. Comprendre ce qui s’écrit réellement permet d’éviter les bricolages manuels du genre « j’édite /etc/passwd à la main, ça ira plus vite ». Ce genre de réflexe finit presque toujours par un comportement étrange dans la gestion utilisateurs.
Le fichier /etc/passwd reste la base : une ligne par compte, avec login, UID, GID, commentaire, répertoire personnel et shell. useradd y insère la nouvelle entrée, ce qui rend immédiatement le compte visible pour le système et les commandes comme getent passwd. Tant que le mot de passe n’est pas défini, le compte existe sur le papier mais ne permet pas de connexion classique.
Le fichier /etc/shadow, lui, stocke les mots de passe chiffrés et quelques paramètres liés à leur vieillissement. Il n’est lisible que par root, ce qui limite la fuite d’informations sensibles. Lorsqu’on lie useradd et passwd, c’est ce fichier qui se met à jour. D’où l’intérêt d’éviter les manipulations directes, même pour « réparer rapidement » un mot de passe.
Un autre acteur silencieux, /etc/skel, sert de modèle pour le répertoire personnel quand on utilise useradd -m. Tout ce qui se trouve dans ce dossier est recopié dans le home du nouvel utilisateur. Si /etc/skel traîne des vieux dotfiles, des alias douteux ou des scripts obsolètes, chaque nouveau compte héritera de ces reliques. Plusieurs admins ont déjà découvert un vieux .bashrc avec des fonctions cassées, cloné dans des dizaines de homes pendant des années.
Les paramètres par défaut de useradd Linux se pilotent aussi via des fichiers comme /etc/default/useradd et /etc/login.defs. C’est là qu’on retrouve des valeurs de base pour les shells, les politiques d’UID, voire certaines contraintes sur les mots de passe. Plutôt que de surcharger chaque commande avec une avalanche d’options, soigner ces réglages globaux permet de limiter les oublis.
Un exemple concret qui revient souvent dans les PME : un admin supprime un utilisateur à la hache en effaçant le dossier /home/toto avec un rm -rf, puis retire vaguement les accès sur une appli web. Le compte reste pourtant bien présent dans /etc/passwd et /etc/shadow. Six mois plus tard, un nouveau venu demande le login « toto ». useradd accepte, mais attribue un nouvel UID différent, puisque l’ancien traîne encore dans les fichiers. Résultat : dans les ACL d’un NAS ou d’un partage NFS, les anciens fichiers de « toto » sont associés à l’UID historique, pas au nouveau. Bonjour les droits illisibles.
La solution saine, c’est d’adopter le trio useradd / usermod / userdel comme seul canal de pilotage. userdel sait retirer proprement les entrées dans les fichiers système, et avec l’option adéquate, peut effacer le home en même temps. En interdisant les modifications manuelles de /etc/passwd en équipe, on supprime une bonne moitié des soucis bizarres liés aux UIDs orphelins.
Du coup, avant de mettre en place une usine à scripts pour la gestion utilisateurs, prendre une heure pour auditer le contenu de /etc/skel, la politique dans /etc/login.defs et les habitudes autour de userdel est loin d’être du temps perdu. Une fois ce socle posé, chaque nouvelle création de compte devient plus prévisible, et le jour où il faut migrer les données, tout le monde s’en félicite.
Syntaxe useradd, options Linux et stratégie pour des comptes propres et cohérents
La commande useradd Linux impressionne facilement avec ses nombreuses options, mais dans la pratique, une poignée de paramètres couvrent 90 % des besoins. Le piège, c’est justement de les ignorer et de se reposer sur des valeurs par défaut mal connues. Quelques commandes bien construites suffisent pour encadrer la création compte de manière durable.
La forme la plus simple ressemble à : sudo useradd identifiant. Ce genre d’appel brut crée un compte minimal, souvent sans home et avec un shell basique comme /bin/sh. Pour un service technique ou un compte purement système, pourquoi pas. Pour un humain qui va se connecter en SSH, c’est beaucoup moins confortable. L’option -m fait alors la différence : sudo useradd -m identifiant déclenche la création du répertoire personnel en recopiant le contenu de /etc/skel.
Le choix du shell avec -s finit par structurer la manière dont les comptes sont utilisés. Pour un utilisateur classique, -s /bin/bash ou un shell plus avancé comme zsh est généralement ce qu’on attend. Pour un compte de service, au contraire, -s /usr/sbin/nologin ou équivalent coupe tout accès interactif, ce qui renforce la sécurité. Mélanger les deux usages rend la lecture de /etc/passwd très pénible.
L’option -u vient sur le devant de la scène dès qu’on traite plusieurs serveurs. Forcer l’UID d’un utilisateur critique permet d’aligner les droits entre différentes machines ou avec des systèmes de fichiers externes. Un exemple typique : sur trois serveurs de fichiers, l’utilisateur « backup » finit avec trois UIDs différents, car ils ont été créés à des moments variés. Quand on monte un NFS partagé, les fichiers appartiennent à des numéros différents selon les contextes, et les droits deviennent incompréhensibles. Recréer les comptes avec useradd -u UID résout ce puzzle.
Pour les appartenance de groupes, -g définit le groupe principal et -G permet d’ajouter des groupes secondaires. Une commande comme : sudo useradd -m -g devs -G sudo,gitlab alice crée un compte Alice avec un home, un groupe principal « devs » et des droits supplémentaires via les groupes « sudo » et « gitlab ». Tout dépend de la politique maison, mais formaliser cette structure noir sur blanc rend les audits plus lisibles.
Deux autres options gagnent à être connues dans les environnements où les comptes ne sont pas éternels : -e pour fixer une date d’expiration, et -f pour piloter les délais autour de l’expiration de mot de passe. Pour les stagiaires, prestataires et comptes d’audit, utiliser useradd -e AAAA-MM-JJ évite le fameux « on a oublié de supprimer son accès après la mission ».
Enfin, l’option -c permet d’ajouter une description lisible directement dans /etc/passwd. Sur un parc rempli de comptes techniques aux noms cryptiques, cette petite zone texte devient un carnet de notes intégré. Par exemple : -c « Compte batch facturation 2026 » aide énormément quand on doit faire le tri entre ce qui sert encore et ce qu’on peut retirer sans tout casser.
Autrement dit, plutôt que d’empiler des règles orales floues, mieux vaut définir un « pattern » de useradd par type de compte. Un pour les développeurs, un pour les comptes système, un pour les prestataires. Une fois cette base en place, les scripts d’onboarding deviennent de simples déclinaisons, et la cohérence du parc s’en trouve renforcée sans effort supplémentaire au quotidien.
Exemples useradd Linux concrets : développeurs, comptes de service, prestataires et scénarios réels
La théorie sur les options useradd est utile, mais tout se joue quand il faut aligner ça avec la vie réelle d’une équipe. Pour garder des repères clairs, prenons un fil rouge : l’entreprise fictive « PixelForge », agence web qui gère plusieurs serveurs Linux pour ses projets clients, avec une dizaine de devs, quelques comptes de service et un flux récurrent de freelances.
Premier cas, l’arrivée d’un nouveau développeur. Le besoin est simple : accès SSH, environnement de travail dans son home, appartenance au groupe des devs, éventuellement des droits sudo limités. Une commande standard pourrait ressembler à :
sudo useradd -m -s /bin/bash -g devs -G sudo,git john.d
Le home est créé, le shell est confortable, John rejoint directement le groupe projet et le groupe sudo (si la politique interne le permet). Il ne manque plus que la définition du mot de passe pour un premier accès, ou la configuration d’une clé SSH selon les habitudes de l’équipe.
Deuxième cas, un compte de service pour faire tourner une application web. Ici, l’objectif change : aucun humain ne doit se connecter directement avec ce compte, mais il doit posséder les bons droits sur les dossiers applicatifs. Une commande possible :
sudo useradd -m -d /srv/app/webapp -s /usr/sbin/nologin -g web webapp
Le répertoire personnel n’est pas dans /home mais dans /srv/app, ce qui clarifie son rôle purement applicatif. Le shell n’autorise aucun accès interactif. Ce type de configuration réduit fortement la surface d’attaque en cas de faille dans l’application qui utiliserait ce compte.
Troisième cas, très fréquent en 2026 : un prestataire vient faire un audit de sécurité pendant trois mois. Il lui faut un accès SSH, mais son compte ne doit pas survivre indéfiniment. On peut écrire :
sudo useradd -m -s /bin/bash -g externes -G devs -e 2026-06-30 audit_ext1
La date d’expiration mettra automatiquement ce compte hors circuit à la fin de la mission, même si tout le monde a oublié de le supprimer. Pendant un audit futur, les équipes sécurité verront tout de suite quels comptes étaient réservés aux interventions temporaires.
Quatrième cas, un compte ultra minimaliste pour un agent de logs qui expédie des journaux vers une plateforme externe. Aucune raison de lui donner un home ni un shell classique. On peut aller sur :
sudo useradd -M -s /usr/sbin/nologin logshipper
Pas de répertoire personnel, pas de connexion interactive, mais un identifiant système dédié pour gérer finement les permissions sur les fichiers de logs. Pour les systèmes soumis à des contraintes réglementaires, cette séparation nette entre humain et technique est souvent exigée.
Dans tous ces exemples, la commande useradd ne représente que la première étape. Sans sudo passwd identifiant ou une autre méthode de gestion de mots de passe (clé SSH, intégration annuaire externe), les utilisateurs interactifs ne pourront pas se connecter. Plusieurs supports IT se retrouvent régulièrement avec des tickets du type « mon compte a été créé, mais je ne peux pas me connecter en SSH » simplement parce que la commande passwd a été oubliée.
Pour éviter ce genre d’oubli, PixelForge a fini par écrire un petit script maison « create_user.sh » qui enchaîne : useradd avec le bon lot d’options, passage dans passwd, ajout aux groupes par défaut, puis affichage d’un résumé clair à l’écran. Ce type de wrapper réduit les erreurs humaines et sert de documentation vivante, bien plus efficace que des procédures PDF qui dorment sur un NAS.
En résumé, dès qu’on rattache les appels useradd Linux à des scénarios précis (dev, service, prestataire, audit), tout devient plus simple à expliquer à l’équipe. Et si un jour on doit prouver à un client ou à un auditeur que la gestion utilisateurs est structurée, disposer de ces patterns de commandes est un argument solide.
Gestion des mots de passe avec useradd, passwd et mkpasswd : sécurité et automatisation sans perdre le contrôle
La création d’un compte sans mot de passe actif donne une fausse impression de travail terminé. Tant que passwd n’a pas été exécuté, ou tant qu’une clé SSH n’a pas été posée, l’utilisateur ne peut pas ouvrir de session. C’est une bonne chose sur le plan de la sécurité, mais dans la pratique, beaucoup d’admins oublient cette étape, surtout lorsqu’ils enchaînent plusieurs créations.
Le duo classique reste : sudo useradd … puis sudo passwd identifiant. La commande passwd guide l’admin pas à pas pour choisir un mot de passe, le retaper, et applique éventuellement les règles de complexité définies dans PAM. C’est robuste, mais peu adapté si tu dois créer vingt comptes d’un coup en suivant un listing fourni par une RH pressée.
Dans certains cas, surtout en script, des admins combinent useradd avec mkpasswd, un utilitaire qui génère un mot de passe chiffré compatible avec /etc/shadow. Une commande du genre :
sudo useradd -m Mowgli -p $(mkpasswd Sonnette1893)
permet de définir le mot de passe en une seule passe. mkpasswd chiffre la chaîne en sortie, et cette valeur alimentera le champ correspondant dans /etc/shadow. Le piège se cache dans les caractères spéciaux, notamment le symbole « $ » souvent généré par les algorithmes de hachage. Les encapsuler directement avec $(mkpasswd …) évite que le shell interprète des morceaux de cette sortie comme des variables.
Il reste cependant une vraie question : veut-on vraiment pousser des mots de passe en clair dans des scripts ou les transmettre par mail aux utilisateurs ? Sur un petit parc interne, certains l’acceptent encore avec une rotation imposée au premier login. Sur des systèmes plus sensibles, la bonne approche ressemble plutôt à : useradd pour créer le compte, puis obligation de changement de mot de passe à la première connexion, ou mise en place de clés SSH et d’un canal de diffusion sécurisé.
Un autre réglage trop peu exploré concerne le vieillissement des mots de passe. Avec les bons paramètres PAM et /etc/login.defs, on peut forcer une expiration au bout d’un certain temps, demander des changements réguliers, ou encore verrouiller automatiquement un compte après une période d’inactivité. useradd ne pilote pas tout cela directement, mais il pose le terrain de jeu en créant l’entrée dans /etc/shadow.
Dans l’histoire de PixelForge, une refonte sécurité est arrivée après qu’un ancien prestataire ait pu se reconnecter avec son vieux mot de passe un an après la fin de sa mission. Le compte n’avait jamais été supprimé, aucune date d’expiration n’était posée, et les mots de passe n’expiraient pas. La correction a combiné trois éléments : date d’expiration via -e pour les comptes temporaires, politique de rotation des mots de passe sur les comptes sensibles, et revue trimestrielle des comptes actifs.
Au passage, les comptes de service ont tous été basculés sur des accès sans mot de passe classique, en s’appuyant sur des clés SSH dédiées ou des mécanismes internes aux applications (tokens, identifiants d’API, etc.). useradd ne fait pas tout, mais il fournit la structure sur laquelle ces pratiques s’appuient.
En gros, l’important n’est pas d’avoir la commande parfaite qui gère tout d’un coup, mais de bien articuler useradd, passwd, éventuellement mkpasswd et la configuration PAM. Une fois cette articulation claire et écrite noir sur blanc, chaque nouveau compte suit un chemin balisé : création, sécurisation du mot de passe ou de la clé, revue périodique, et suppression propre en fin de vie.
Quelle différence pratique entre useradd et adduser sous Linux ?
useradd agit en mode non interactif et se prête très bien à l’automatisation et aux scripts, surtout quand on veut une gestion utilisateurs standardisée. adduser est un script interactif qui pose des questions et configure le compte de façon plus guidée, pratique pour quelques créations manuelles ponctuelles. Dans un parc de serveurs où la cohérence et la traçabilité comptent, useradd est généralement privilégié.
Pourquoi un utilisateur créé avec useradd ne peut-il pas se connecter immédiatement ?
Un compte créé avec useradd n’a pas de mot de passe actif tant que la commande passwd n’a pas été exécutée ou qu’aucune autre méthode d’authentification n’a été configurée. De plus, si le shell défini avec l’option -s est un shell non interactif comme /usr/sbin/nologin, l’utilisateur ne pourra pas ouvrir de session. Il faut donc vérifier à la fois le mot de passe et le shell configuré.
Comment fixer une date de fin de validité à un utilisateur Linux ?
Lors de la création du compte, l’option -e de useradd permet de fixer une date d’expiration au format AAAA-MM-JJ. Par exemple useradd -m -e 2026-12-31 prestataire crée un compte qui sera automatiquement désactivé à cette date. C’est particulièrement adapté pour les stagiaires, freelances ou comptes d’audit temporaires.
Peut-on standardiser la gestion des comptes sans annuaire LDAP ?
Oui, pour de nombreuses PME, des scripts basés sur useradd, une convention sur les logins, les groupes, les shells et les dates d’expiration couvrent la majorité des besoins. L’essentiel est de documenter ces conventions, de les versionner et de s’y tenir. LDAP ou d’autres annuaires deviennent intéressants quand le nombre d’utilisateurs et de services grandit fortement.
Comment ajouter un utilisateur Linux à plusieurs groupes en une seule commande ?
L’option -G de useradd accepte une liste de groupes séparés par des virgules. Par exemple useradd -m -G devs,sudo alice crée le compte alice et l’ajoute directement aux groupes devs et sudo, à condition que ces groupes existent déjà. Pour modifier les groupes après coup, il faudra utiliser usermod avec l’option -aG.
