Sur un serveur Linux en production, la commande useradd est au cœur de la gestion utilisateurs Linux. Elle sert autant à créer un simple compte pour un stagiaire qu’à préparer des comptes de service avec des droits millimétrés. Mal utilisée, elle laisse des comptes orphelins, des UIDs incohérents ou des répertoires personnels qui traînent dans les sauvegardes pendant des années. Bien maîtrisée, elle devient un outil prévisible, scriptable et facile à intégrer dans un processus d’onboarding ou d’automatisation.
Dans beaucoup de PME, la création utilisateur se fait encore « à la main » dans un terminal, souvent en copiant des commandes vues une fois sur un wiki interne. Les détails comme la date d’expiration, les groupes utilisateur ou le shell de connexion passent à la trappe. Au bout de quelques années, on se retrouve avec un zoo d’utilisateurs impossibles à auditer proprement. L’objectif de ce contenu est de remettre de l’ordre là-dedans, en expliquant la syntaxe useradd, les options useradd vraiment utiles, et surtout des exemples useradd qui collent au quotidien d’un admin système.
En bref
- useradd est un outil bas niveau pour la création utilisateur sous Linux, idéal pour les scripts et les configurations précises.
- adduser est plus interactif et convivial, mais moins adapté aux scénarios automatisés ou très normés.
- La syntaxe de base useradd [options] login ne suffit jamais en production : il faut au minimum gérer le répertoire personnel, le shell et le mot de passe.
- Les options clés à connaître : -m (home), -s (shell), -u (UID), -g/-G (groupes utilisateur), -d (home personnalisé), -e (expiration), -f (grâce mot de passe).
- Un minimum de standardisation évite les surprises lors des audits, des migrations ou des restaurations de sauvegardes.
Commande useradd Linux et différence avec adduser dans la vie réelle
Dans beaucoup de documentations, useradd et adduser sont présentés comme des équivalents. Techniquement, ils mènent tous les deux à la création utilisateur, mais leur usage n’a rien à voir dans un environnement où l’on cherche la reproductibilité. Sur la plupart des distributions Debian/Ubuntu, adduser est un script en shell qui s’appuie sur useradd, pose des questions interactives et applique des conventions raisonnables par défaut.
A contrario, la commande useradd est un binaire bas niveau. Elle ne fait que ce qu’on lui demande, sans poser de question ni inventer des paramètres. C’est exactement ce que l’on veut dans un script d’industrialisation, mais cela surprend souvent les débutants : pas de mot de passe, pas forcément de répertoire personnel, pas toujours de shell cohérent si la distribution est un peu exotique.
Un scénario classique illustre cette différence. L’entreprise « NetCorrèze », petite structure de 40 personnes, déploie quelques serveurs Ubuntu pour héberger Git, un outil de ticketing et deux applis métiers. Le premier admin utilise adduser pour tout, à la main, et ça fonctionne. Trois ans plus tard, un second admin arrive, automatise la gestion avec des scripts Ansible, et s’appuie sur useradd. Résultat : on se retrouve avec deux générations de comptes, créées avec des logiques différentes. Pour l’audit et le support, ce n’est pas idéal.
Dans ce type de contexte, il vaut mieux trancher clairement.
- Sur des serveurs gérés à la main avec peu de comptes, adduser peut rester acceptable pour des comptes humains.
- Pour les comptes techniques, les environnements multi-serveurs et les scripts, le choix le plus propre reste useradd.
- Dans un parc mixte, une convention explicite s’impose : par exemple, adduser uniquement pour les comptes interactifs, useradd pour tout le reste.
Pour visualiser les différences pratiques entre les deux, un tableau aide à cadrer le sujet.
| Commande | Typiquement utilisée pour | Interaction | Création du home | Usage recommandé |
|---|---|---|---|---|
| useradd | Comptes de service, automatisation, déploiements | Non, tout est passé en options | Seulement avec -m | Scripts, normes internes strictes |
| adduser | Utilisateurs humains, postes de dev/test | Oui, questions interactives | Oui par défaut | Gestion manuelle ponctuelle |
En résumé, mélanger les deux sans politique claire finit toujours par créer de la dette technique dans la gestion utilisateurs Linux. Mieux vaut décider tôt de la place exacte de useradd dans l’écosystème de l’entreprise.
Sous le capot de useradd et des fichiers système Linux
Dès qu’un compte est créé via la commande useradd, plusieurs fichiers système changent. Le plus connu reste /etc/passwd, qui stocke les informations de base du compte : login, UID, GID principal, répertoire personnel, shell. Les mots de passe, eux, ne sont plus là depuis longtemps sur les systèmes modernes et se trouvent dans /etc/shadow.
Un point souvent négligé concerne la cohérence entre ces fichiers et le contenu de /home. Un admin pressé peut supprimer un répertoire utilisateur à la main via rm -rf, sans passer par userdel. Sur le papier, ça « libère » de la place. Dans la réalité, les entrées /etc/passwd et /etc/shadow restent, et cet ancien login peut un jour être réutilisé par erreur. Avec un peu de malchance, on se retrouve avec un utilisateur tout neuf qui hérite d’un vieil UID encore présent dans des ACL sur un NAS ou un partage NFS.
C’est pour éviter ce genre de surprise qu’un minimum de discipline autour de useradd, usermod et userdel fait la différence. La commande elle-même est simple, mais l’écosystème qui tourne autour est plus large qu’il n’y paraît.
Syntaxe useradd et utilisation de base sur un serveur Linux
La syntaxe useradd est volontairement dépouillée : useradd [options] login. Sans options, beaucoup de distributions créent un compte minimal, parfois sans répertoire personnel correct, parfois avec un shell de connexion qui ne convient pas. Pour un usage sérieux, cette forme « nue » n’a pas grand intérêt, sauf pour des comptes de service très spécifiques.
La base pour une création utilisateur interactive exploitable ressemble plutôt à quelque chose du type :
- Créer le compte et le home : sudo useradd -m nouvelutilisateur
- Définir un shell cohérent : sudo useradd -m -s /bin/bash nouvelutilisateur
- Attribuer un mot de passe : sudo passwd nouvelutilisateur
Avec cette combinaison, on obtient un compte capable de se connecter en SSH ou en console, avec un environnement de travail classique. La commande passwd reste indispensable, car useradd ne gère pas directement les mots de passe. Sans cette étape, le compte est bloqué pour toute connexion classique.
Un exemple récurrent chez NetCorrèze illustre bien ce point. Un développeur se voit attribuer un compte pour accéder à un serveur de test. L’admin crée simplement le login via useradd, mais oublie de lancer passwd. Le dev passe une heure à chercher pourquoi la connexion SSH refuse obstinément son mot de passe « temporaire » envoyé par mail. En réalité, le compte n’a tout simplement aucun mot de passe, donc aucune possibilité de connexion classique. Une simple procédure standard de création aurait évité cette perte de temps des deux côtés.
Pour synthétiser les cas les plus utilisés au quotidien, un tableau reste pratique.
| Action | Commande useradd | Étape complémentaire | Résultat attendu |
|---|---|---|---|
| Créer un compte basique | sudo useradd nouvelutilisateur | sudo passwd nouvelutilisateur | Utilisateur sans home explicite selon la distro |
| Créer un compte avec home | sudo useradd -m nouvelutilisateur | sudo passwd nouvelutilisateur | Home à /home/nouvelutilisateur |
| Compte avec home + bash | sudo useradd -m -s /bin/bash nouvelutilisateur | sudo passwd nouvelutilisateur | Prêt pour une utilisation interactive |
Sur certains systèmes, les templates de répertoires personnels (contenu de /etc/skel) sont copiés lors de la création du home. Cela inclut les fichiers cachés comme .bashrc ou .profile. Si ces fichiers de base sont mal configurés, tous les nouveaux comptes héritent de ces imperfections. Avant d’industrialiser les créations de comptes avec useradd, un contrôle de /etc/skel ne fait jamais de mal.
Contrôler la création de l’UID et des répertoires
Chaque utilisateur Linux reçoit un UID, identifiant numérique unique. Par défaut, la plage des UIDs alloués automatiquement est définie dans /etc/login.defs. Pour la plupart des usages, le comportement automatique suffit, mais certains environnements exigent un alignement strict des UIDs entre plusieurs serveurs, surtout quand des partages NFS sont en jeu.
La commande useradd -u prend alors tout son sens. Elle permet de forcer un identifiant précis, par exemple pour recréer à l’identique un utilisateur disparu mais encore présent dans des ACL distantes. On peut par exemple écrire :
- sudo useradd -m -u 1500 -s /bin/bash devprojet
- puis sudo passwd devprojet
Avec cette approche, l’UID 1500 se retrouve associé à devprojet sur tous les serveurs, ce qui évite des incohérences de droits sur les fichiers partagés. Ce genre de détail pèse lourd quand on doit diagnostiquer des erreurs « Permission denied » sur un stockage partagé à 3 heures du matin.
Dernier point sur les bases : la gestion des répertoires personnels personnalisés avec l’option -d. Pour héberger des données sensibles sur un volume chiffré différent de /home, ou simplement séparer les comptes de service, on pourra utiliser une commande du type :
sudo useradd -m -d /srv/app/compte_service -s /usr/sbin/nologin compte_service
Cette manière de penser un peu en amont l’organisation des homes évite d’avoir à tout déplacer plus tard, avec les modifications de chemins que cela implique dans les scripts et les fichiers de configuration.
Options useradd les plus utiles pour la sécurité et l’organisation des comptes
Une fois la base maîtrisée, la vraie valeur de useradd se trouve dans ses options. Un bon usage des options useradd permet de garder une structure propre, avec des groupes utilisateur bien segmentés, des dates d’expiration cohérentes et des comptes techniques qui ne deviennent pas des portes d’entrée involontaires.
Chez NetCorrèze, un cas a marqué les esprits. Un prestataire externe obtient un login temporaire sur un serveur frontal. Le compte est créé en urgence, sans date d’expiration ni documentation claire sur ses groupes. Trois ans plus tard, le prestataire est parti depuis longtemps, mais son compte reste actif, toujours membre d’un groupe sudo. Un simple audit des comptes associés à des prestataires aurait suffi, appuyé sur un usage systématique de l’option -e pour limiter la durée de vie de ces accès.
Les options les plus pertinentes pour ce genre de situation se concentrent autour de cinq axes.
- Organisation des groupes avec -g (groupe primaire) et -G (groupes secondaires).
- Gestion du home avec -m et -d.
- Contrôle du shell avec -s.
- Durée de vie du compte avec -e.
- Durée de vie du mot de passe avec -f.
Un tableau de synthèse permet de garder ces éléments en tête lors de la rédaction de scripts.
| Option useradd | Rôle | Exemple concret | Impact sur la sécurité/organisation |
|---|---|---|---|
| -g | Définit le groupe principal | useradd -m -g devs alice | Contrôle fin des permissions par défaut |
| -G | Ajoute des groupes secondaires | useradd -m -G devs,sudo alice | Évite de donner sudo par défaut à tout le monde |
| -e | Fixe la date d’expiration | useradd -m -e 2024-12-31 prestataire1 | Nettoyage automatique des comptes temporaires |
| -f | Délai avant désactivation après expiration du mot de passe | useradd -m -f 7 projet_temp | Réduit le risque lié aux mots de passe oubliés |
| -s | Définit le shell | useradd -m -s /usr/sbin/nologin service_web | Bloque la connexion interactive des comptes de service |
Une position assez tranchée s’impose sur les comptes de service : un compte qui n’a pas besoin de shell interactif ne devrait jamais utiliser /bin/bash. L’option -s /usr/sbin/nologin ou un shell équivalent ferme une porte qui n’avait aucune raison d’être ouverte.
Décrire et tracer les comptes utilisateurs
Beaucoup négligent l’option -c de useradd, qui permet d’ajouter un commentaire ou une description. Pourtant, sur un serveur partagé entre plusieurs équipes, ce simple champ sert de mini-documentation. Savoir que le compte « app_batch » est « compte batch pour l’export vers le SI comptable » aide énormément quand on nettoie des comptes anciens.
Quelques habitudes pragmatiques peuvent faire la différence.
- Inclure l’usage du compte : « accès SSH dev front-end », « compte API pour CRM ».
- Ajouter un identifiant de ticket ou de demande : « JIRA-DEV-842 » par exemple.
- Préciser la date de création si l’outil de suivi ne le fait pas.
On obtient alors des commandes du type :
sudo useradd -m -s /bin/bash -c « Dev front-end projet X (ticket JIRA-DEV-842) » devpx
ou pour un prestataire :
sudo useradd -m -s /bin/bash -e 2024-10-12 -c « Prestataire audit sécu (contrat 2024-Q4) » auditext
Cette discipline paraît anodine, mais elle change complètement la qualité de la gestion utilisateurs Linux sur la durée. Un simple grep sur /etc/passwd suffit ensuite à retrouver tous les comptes liés à un projet ou à un prestataire donné, au lieu de devoir décoder des logins obscurs.
Exemples useradd concrets pour différents profils (dev, prod, comptes temporaires)
Passer de la théorie aux exemples useradd concrets montre vite ce qui fonctionne réellement sur un système Linux en charge. Dans un environnement typique, on retrouve au moins trois catégories de comptes : les utilisateurs interactifs (devs, admins), les comptes techniques pour les services, et les accès temporaires ou à durée limitée.
Pour les utilisateurs interactifs, la commande ressemble souvent à ceci :
- sudo useradd -m -s /bin/bash -g devs -G sudo,gitlab john.d
- sudo passwd john.d
Le groupe principal « devs » permet de gérer des droits partagés sur des répertoires de projet, tandis que le groupe secondaire « gitlab » autorise l’accès à un dépôt auto-hébergé. L’ajout à « sudo » se discute selon la politique de l’entreprise ; dans beaucoup de contextes, seule une poignée d’admins système devrait y avoir accès.
Pour un compte de service lié à une application, on peut viser une configuration beaucoup plus verrouillée :
- sudo useradd -m -d /srv/app/webapp -s /usr/sbin/nologin -g web webapp
- puis configuration du service systemd pour lancer les processus sous ce login.
Dans cet exemple, le répertoire personnel est déplacé sous /srv/app, ce qui clarifie l’emplacement des données de l’application et sépare nettement ces fichiers de ceux des utilisateurs humains. Le shell /usr/sbin/nologin s’assure qu’aucune connexion interactive ne sera possible.
Pour les comptes temporaires, la combinaison date d’expiration + commentaire évite une fouille archéologique des anciens comptes tous les six mois. Une création typique peut prendre cette forme :
| Type de compte | Commande useradd | Caractéristiques | Cas d’usage |
|---|---|---|---|
| Stagiaire | sudo useradd -m -s /bin/bash -g devs -e 2024-08-31 stag_jules | Expiration automatique à fin de stage | Accès limité dans le temps |
| Prestataire | sudo useradd -m -s /bin/bash -g externes -G devs -e 2024-12-31 ext_audit1 | Groupe spécifique pour les externes | Audit ponctuel ou mission courte |
| Compte batch | sudo useradd -m -d /srv/batch/export -s /usr/sbin/nologin batch_export | Pas de shell interactif, home dédié | Tâches planifiées via cron ou systemd |
Dans tous ces cas, la logique reste la même : expliciter le rôle du compte dans la commande elle-même, pour qu’un simple historique shell ou un script d’auto-documentation permette de reconstituer qui sert à quoi.
Exemples useradd avec UID spécifié, home absent et autres cas particuliers
Certaines situations demandent un contrôle encore plus fin. C’est le cas lors de migrations ou de reconstructions de serveurs où il faut retrouver des UIDs précis, ou lorsqu’un compte ne doit volontairement pas avoir de répertoire personnel. L’option -M de useradd supprime la création automatique du home, même si la configuration par défaut de la distribution l’active.
Pour créer un utilisateur sans répertoire personnel, typique d’un compte purement technique, on peut par exemple utiliser :
- sudo useradd -M -s /usr/sbin/nologin logshipper
- puis configuration d’un agent de logs qui tourne avec ce login.
Dans d’autres cas, la priorité est à la cohérence d’UID sur plusieurs machines. NetCorrèze a ainsi dû migrer un vieux serveur de fichiers vers une nouvelle infra. Les UIDs existants devaient rester identiques pour éviter de casser les droits sur un NAS externe déjà peuplé. La solution a consisté à recréer les comptes à l’identique avec useradd -u, après un export de /etc/passwd depuis l’ancien serveur.
Un exemple simplifié :
- sudo useradd -m -u 1200 -s /bin/bash sr_admin
- sudo useradd -m -u 1201 -s /bin/bash sr_dev
Une fois les comptes alignés, un simple rsync avec l’option de préservation des droits permet de transférer les données sans devoir réappliquer toutes les ACL à la main. C’est typiquement le genre de situation où une bonne compréhension de useradd Linux fait gagner plusieurs heures, voire plusieurs jours, lors d’une migration compliquée.
Dépannage et bonnes pratiques autour de la commande useradd
Aucun admin n’y échappe : un jour ou l’autre, une commande useradd retourne un message d’erreur en plein déploiement, ou un nouvel utilisateur se plaint de ne pas pouvoir se connecter. La plupart des problèmes viennent d’options oubliées, de groupes inexistants ou de conventions implicites qu’une personne connaissait, mais pas la suivante.
Les erreurs les plus fréquentes tournent autour de quelques thèmes récurrents.
- Permission denied lors de l’appel à useradd sans sudo.
- Group does not exist lorsque l’option -g ou -G cible un groupe non créé.
- Absence de répertoire personnel par oubli de l’option -m.
- Compte existant déjà, mais oublié, ce qui déclenche un « user already exists ».
- Compte créé sans mot de passe, rendant la connexion impossible par SSH.
Un petit tableau de dépannage permet d’avoir sous la main les réflexes de base.
| Symptôme | Cause probable | Commande de vérification | Correction conseillée |
|---|---|---|---|
| Erreur « Permission denied » | Commande lancée sans droits root | whoami | Relancer avec sudo useradd … |
| Erreur « Group does not exist » | Groupe manquant | getent group nom_groupe | Créer le groupe avec sudo groupadd nom_groupe |
| Pas de home créé | Oubli de l’option -m | getent passwd login, ls /home | Recréer le compte ou créer le home puis ajuster /etc/passwd |
| Impossible de se connecter | Mot de passe non défini | sudo passwd -S login | sudo passwd login pour fixer un mot de passe |
Au-delà du dépannage ponctuel, quelques bonnes pratiques méritent d’être systématisées sur tout environnement Linux un peu sérieux.
Standardiser la gestion utilisateurs Linux avec des scripts et des conventions
La force de useradd, c’est sa prévisibilité. Cette caractéristique colle très bien avec des scripts d’automatisation, que ce soit en bash brut, en Ansible, Puppet ou tout autre outil similaire. Plutôt que de laisser chaque admin taper ses commandes à la main, un simple script de création utilisateur standard couvre déjà une bonne partie des risques.
Un script shell minimal peut, par exemple, appliquer automatiquement :
- Une convention de login (prenom.nom ou initiale_nom).
- Un groupe principal par équipe (devs, ops, finance, etc.).
- Un shell imposé (souvent /bin/bash ou /bin/zsh selon la culture de la boîte).
- Une option -e pour les profils temporaires, avec calcul automatique de la date.
Couplé à un fichier CSV ou à un inventaire YAML, ce script permet d’industrialiser la gestion utilisateurs Linux sans transformer l’infra en usine à gaz. L’idée n’est pas de réinventer un annuaire d’entreprise complet, mais au moins de s’éviter les créations manuelles incohérentes qui finissent régulièrement par faire dérailler un audit sécurité.
Le dernier maillon à ne pas oublier reste la documentation. La meilleure commande useradd Linux du monde ne sert pas à grand-chose si personne ne sait qu’elle existe dans un script commun. Un simple README dans un dépôt Git interne, assorti d’un exemple de ligne de commande pour chaque type de compte, suffit souvent à ce que tout le monde joue avec les mêmes règles.
Quelle est la différence principale entre useradd et adduser sous Linux ?
useradd est un binaire bas niveau qui se contente d’appliquer les options passées en ligne de commande, sans interaction. adduser est un script qui s’appuie souvent sur useradd, propose un mode interactif et applique des valeurs par défaut plus confortables (création de home, questions sur le mot de passe, etc.). Pour l’automatisation et les environnements normés, useradd reste plus adapté ; pour un ajout ponctuel à la main, adduser est plus confortable.
Pourquoi mon nouvel utilisateur ne peut-il pas se connecter après un useradd ?
useradd ne définit pas de mot de passe par défaut. Après la création du compte, il faut exécuter la commande passwd login pour fixer un mot de passe, ou bien configurer une authentification par clé SSH. Sans cette étape, le compte reste verrouillé pour les connexions interactives classiques. Vérifiez aussi que le shell n’est pas défini sur /usr/sbin/nologin ou un équivalent qui bloque la connexion.
Comment créer un utilisateur Linux avec une date d’expiration automatique ?
Utilisez l’option -e de useradd avec une date au format AAAA-MM-JJ. Par exemple, sudo useradd -m -s /bin/bash -e 2024-12-31 stag_marie crée un compte qui expirera le 31 décembre 2024. Vous pouvez vérifier la configuration avec la commande chage -l stag_marie, qui affichera la date d’expiration du compte ainsi que d’autres paramètres liés au mot de passe.
Comment ajouter un utilisateur à plusieurs groupes Linux lors de la création ?
L’option -g permet de choisir le groupe principal, et -G de lister des groupes supplémentaires séparés par des virgules. Par exemple, sudo useradd -m -s /bin/bash -g devs -G gitlab,sudo alice crée alice avec devs comme groupe principal, et des appartenances secondaires aux groupes gitlab et sudo. Assurez-vous que ces groupes existent déjà, sinon useradd renverra une erreur.
Peut-on créer un utilisateur sans répertoire personnel avec useradd ?
Oui, l’option -M de useradd empêche la création automatique du répertoire personnel. Une commande comme sudo useradd -M -s /usr/sbin/nologin logshipper crée un compte sans home, adapté à certains services techniques. Ce choix doit être réfléchi, car un home inexistant peut surprendre des scripts ou des outils qui s’attendent à trouver un répertoire utilisateur classique.
