Sur un serveur Linux qui tourne en production, la création utilisateur ne devrait jamais se résumer à une commande tapée à la va-vite dans un terminal. Entre les stagiaires qui arrivent tous les étés, les prestataires à durée limitée et les comptes de service qui alimentent les applications, la moindre erreur finit tôt ou tard par se payer en droits bancals, accès oubliés ou migrations douloureuses. La commande useradd se retrouve alors au centre du jeu : binaire bas niveau, silencieux, mais redoutablement efficace pour qui sait s’en servir. Elle ne pose pas de questions, ne devine rien et ne corrige pas les décisions prises, ce qui en fait à la fois son principal atout et la source de nombreux pièges.
Dans une petite structure comme la société fictive « NetCorrèze », avec quelques serveurs Linux pour le code, les tickets et deux applications métiers, la situation est typique. Le premier admin a tout configuré à la main, souvent avec adduser, parfois directement avec useradd, sans politique de gestion utilisateurs écrite. Quelques années plus tard, un deuxième admin arrive, automatise, écrit des playbooks Ansible et s’appuie exclusivement sur useradd Linux. Résultat : deux générations de comptes cohabitent, avec des conventions différentes, des UIDs discordants et des répertoires personnels disséminés. L’objectif de ce mode d’emploi détaillé est de reprendre la main sur cet outil, en posant un cadre clair : comment fonctionne useradd, quelles options useradd utiliser vraiment, quels exemples useradd adapter au quotidien, et comment éviter que la ligne de commande devienne une source de dette technique.
- useradd est un outil bas niveau, idéal pour l’automatisation et les environnements normés, mais il ne fait rien de « confortable » sans options explicites.
- Un compte utilisateur créé avec useradd est inactif tant qu’aucun mot de passe ou mécanisme d’authentification n’a été configuré.
- Les options useradd clés à maîtriser : -m/-d (répertoire personnel), -s (shell), -u (UID), -g/-G (groupes), -e/-f (durée de vie du compte et du mot de passe), -c (description).
- Distinguer clairement les usages de useradd et adduser évite des incohérences de gestion utilisateurs et des audits pénibles.
- Standardiser la création utilisateur via scripts et conventions est plus rentable que de corriger en urgence des comptes mal définis.
useradd Linux : mode d’emploi clair pour la création utilisateur en ligne de commande
Sur n’importe quelle distribution moderne de la famille GNU/Linux, useradd reste l’outil de base pour créer un compte utilisateur via la ligne de commande. C’est un binaire système, lancé avec les droits administrateur, qui met à jour les fichiers comme /etc/passwd et /etc/shadow. Contrairement à des scripts plus conviviaux, il n’entre pas en dialogue avec l’admin : tout ce qu’il doit faire est exprimé dans la commande.
La syntaxe générique ressemble à ceci :
sudo useradd identifiant_utilisateur [options]
Le point clé à intégrer dès le départ : un compte créé avec useradd est, au départ, sans mot de passe et parfois sans répertoire personnel exploitable. Tant que la commande passwd n’a pas été appelée, aucune ouverture de session classique n’est possible. C’est la première erreur que l’on retrouve chez les admins pressés, surtout lorsqu’ils découvrent l’outil en production.
Différence entre useradd et adduser dans l’administration Linux réelle
Les documentations parlent souvent de useradd et adduser comme de simples variantes. Dans les faits, les rôles sont assez distincts. Sur Debian, Ubuntu et dérivés, adduser est un script shell qui s’appuie sur useradd, pose des questions interactives (nom complet, mot de passe, etc.) et applique des valeurs par défaut confortables comme la création du home et la copie de /etc/skel.
useradd Linux, lui, ne fait qu’appliquer les paramètres explicitement passés. Aucun dialogue, aucun garde-fou, pas d’« assistants ». Pour un script d’onboarding ou une configuration Ansible, c’est ce qu’il faut : un comportement constant, prévisible, que l’on peut rejouer des dizaines de fois. Pour une création ponctuelle à la main, certains admins préfèrent garder adduser pour la rapidité d’exécution.
Chez NetCorrèze, la décision a fini par être tranchée après un audit interne : tous les comptes de service et les comptes techniques sont désormais créés via useradd dans des playbooks, tandis que les rares comptes interactifs ajoutés manuellement passent encore parfois par adduser. Le point important reste de documenter la règle, pas de débattre sans fin de l’outil « parfait ».
Sous le capot : fichiers système, UIDs et cohérence des comptes Linux
Dès qu’un compte utilisateur est ajouté avec useradd, plusieurs couches du système bougent. Le fichier /etc/passwd stocke les informations de base : identifiant, UID, GID principal, chemin du répertoire personnel, shell. Les données sensibles, notamment les mots de passe hachés, résident dans /etc/shadow, réservé aux comptes privilégiés.
La plupart des incidents subtils viennent des écarts entre ces fichiers et le contenu réel des répertoires. Un administrateur qui supprime un répertoire /home à coups de rm -rf sans passer par userdel laisse derrière lui des entrées actives dans /etc/passwd. Un jour, un autre compte réutilise le même identifiant ou le même UID, et les droits fichiers se mélangent. Pour les accès NFS ou les ACL sur un NAS, ces collisions font perdre un temps précieux au diagnostic.
Syntaxe useradd de base et premiers exemples useradd concrets
La forme la plus simple de la commande se résume à un identifiant d’utilisateur :
sudo useradd jane
Dans cette version minimaliste, selon la distribution Linux et la configuration de /etc/login.defs, le compte peut se retrouver sans répertoire personnel créé ou avec un shell par défaut assez austère. Pour une utilisation interactive standard, elle reste insuffisante. Une séquence plus réaliste, adaptée à un utilisateur humain, prend plutôt cette forme :
- sudo useradd -m -s /bin/bash jane
- sudo passwd jane
La première commande crée le compte avec un home à /home/jane et définit /bin/bash comme shell. La seconde attribue un mot de passe et active réellement la possibilité de connexion. Chez NetCorrèze, cette séquence est devenue le minimum syndical pour tout nouvel arrivant en développement.
Options useradd essentielles pour maîtriser la gestion utilisateurs
Une fois cette base intégrée, la valeur de useradd Linux se joue dans ses options. Certaines sont anecdotiques, d’autres structurent vraiment la gestion utilisateurs sur la durée. Les plus utiles tournent autour des groupes, du répertoire personnel, du shell et de la durée de vie des comptes.
Un point de vue assez ferme ressort de l’expérience : un compte qui n’a pas besoin d’un shell interactif ne devrait pas hériter de /bin/bash « par habitude ». Pour des comptes techniques ou des services, un shell comme /usr/sbin/nologin ou équivalent coupe une porte d’entrée potentielle, sans gêner le fonctionnement des démons lancés par systemd ou cron.
| Option useradd | Rôle principal | Exemple | Effet pratique |
|---|---|---|---|
| -m / –create-home | Créer automatiquement le répertoire personnel | sudo useradd -m alice | Garantit un home sous /home/alice |
| -d / –home | Définir un chemin de home personnalisé | sudo useradd -m -d /srv/app/web webapp | Isoler les comptes techniques en dehors de /home |
| -s / –shell | Choisir le shell de connexion | sudo useradd -m -s /bin/bash devapi | Adapter l’environnement de travail ou bloquer l’interactif |
| -u / –uid | Forcer un UID spécifique | sudo useradd -m -u 1500 devlegacy | Aligner les UIDs entre plusieurs serveurs ou après migration |
| -g / –gid | Définir le groupe principal | sudo useradd -m -g devs alice | Contrôler les permissions par défaut sur les fichiers créés |
| -G / –groups | Ajouter des groupes secondaires | sudo useradd -m -G gitlab,sudo alice | Donner des droits complémentaires (Git, sudo, etc.) |
| -e | Fixer la date d’expiration du compte | sudo useradd -m -e 2026-09-30 prest_ext | Supprimer automatiquement des accès temporaires |
| -f | Définir un délai de grâce après expiration du mot de passe | sudo useradd -m -f 7 projet_temp | Limiter le temps pendant lequel un mot de passe expiré reste acceptable |
| -c | Ajouter un commentaire ou une description | sudo useradd -m -c « Dev front-end projet X » devpx | Documenter le rôle du compte directement dans /etc/passwd |
UID, fichiers de config et organisation des homes
Les identifiants numériques (UID) sont souvent laissés en mode automatique, ce qui suffit pour un serveur isolé. Dès qu’un stockage partagé ou un cluster entre en jeu, l’alignement des UIDs devient pourtant critique. Sinon, le même login peut représenter des utilisateurs différents d’un serveur à l’autre, avec des droits fichiers incohérents.
Dans une migration réalisée chez NetCorrèze, la solution a consisté à exporter les UIDs existants, puis à reconstruire les comptes avec useradd -u sur les nouvelles machines. Les données ont ensuite été synchronisées via rsync en conservant les propriétaires. Le temps passé à analyser /etc/passwd et /etc/group en amont a évité une chasse aux « Permission denied » pendant des jours.
Exemples useradd pour des comptes interactifs : devs, admins, stagiaires
Du point de vue pratique, le plus utile reste de disposer de quelques exemples useradd prêts à l’emploi, adaptés à différents profils. Pour un développeur ou un admin, l’objectif est simple : un compte interactif capable de se connecter en SSH, avec un environnement proche de ce qu’il a sur sa machine locale.
Un modèle fréquemment utilisé pour un développeur dans une PME ressemble à ceci :
sudo useradd -m -s /bin/bash -g devs -G gitlab,sudo john.d
sudo passwd john.d
Le groupe principal devs gère les permissions partagées sur les répertoires de code, tandis que les groupes secondaires gitlab et sudo ouvrent respectivement l’accès à la forge et aux privilèges d’administration. Le choix de placer un dev dans sudo doit rester encadré ; dans certaines équipes, seuls les admins système y ont droit, ce qui se défend tout autant.
Comptes temporaires et date d’expiration automatique
Les stagiaires et prestataires méritent une attention particulière. Sans processus clair, leurs comptes restent souvent actifs longtemps après leur départ, parfois toujours capables de passer en sudo. L’option -e de useradd sert précisément à couper ce risque à la source, avec une date d’expiration au format AAAA-MM-JJ.
Pour un stagiaire présent jusqu’au 31 août, une commande propre serait :
sudo useradd -m -s /bin/bash -g devs -e 2026-08-31 stag_jules
sudo passwd stag_jules
Le compte sera désactivé automatiquement à la date prévue, sans intervention manuelle. Pour garder une trace contextuelle, certains admins ajoutent en plus un commentaire précis via -c, par exemple :
sudo useradd -m -s /bin/bash -g devs -e 2026-08-31 -c « Stagiaire back-end été 2026 » stag_jules
useradd pour comptes de service : sécurité, shells et répertoires dédiés
Les comptes de service sont souvent les grands oubliés de la sécurité. Ils tournent en arrière-plan, ne se connectent jamais « à la main », mais héritent parfois des mêmes paramètres qu’un utilisateur humain. Avec useradd Linux, il est possible d’être plus rigoureux sans complexifier la vie des développeurs.
Pour un service web, par exemple, une commande raisonnable pourrait ressembler à ceci :
sudo useradd -m -d /srv/app/webapp -s /usr/sbin/nologin -g web webapp
Le répertoire personnel se situe clairement dans /srv/app, ce qui le distingue des homes utilisateurs. Le shell /usr/sbin/nologin interdit toute ouverture de session interactive : le compte ne sert qu’à exécuter des processus lancés par systemd ou un équivalent. C’est une ligne de défense simple, mais souvent négligée par habitude.
Création d’un compte sans mot de passe via mkpasswd
Dans certaines équipes, la politique exige que les mots de passe soient générés et appliqués de manière non interactive, par exemple lors de déploiements automatisés. L’outil mkpasswd, souvent fourni par le paquet whois, permet de préparer un mot de passe chiffré à passer directement à useradd avec l’option -p.
Une séquence typique pourrait être :
sudo apt install whois
sudo useradd -m Mowgli -p $(mkpasswd Sonnette1893)
Ici, le mot de passe en clair « Sonnette1893 » est transformé en hachage par mkpasswd, puis injecté directement dans la création du compte. L’utilisation de la substitution de commande $(…) évite les problèmes liés au caractère $ souvent présent dans les hachages. Il faut simplement garder en tête que cette méthode contourne parfois les politiques de complexité de passwd : sa place se trouve plutôt dans des environnements bien surveillés que dans des serveurs exposés et mal suivis.
Dépannage useradd : erreurs fréquentes et réflexes utiles
Quand un useradd tourne mal, c’est rarement pour des raisons obscures. La plupart des cas se résument à des groupes manquants, à un oubli d’option ou à des droits insuffisants. Avoir quelques réflexes de diagnostic sous la main fait gagner du temps, surtout quand un utilisateur appelle en disant « je ne peux pas me connecter » sans plus de détails.
NetCorrèze a par exemple vu passer un cas où un compte avait bien été créé, mais son groupe principal n’existait pas. La commande avait utilisé -g avec une faute de frappe dans le nom du groupe. Résultat : message d’erreur, commande avortée, mais doc interne mise à jour à la hâte d’après un copier-coller erroné. Une simple vérification via getent group nom_groupe aurait évité cette confusion.
Checklist pratique pour la création utilisateur Linux avec useradd
Pour transformer tout cela en réflexe, une courte checklist opérationnelle suffit souvent. Elle tient en quelques points, mais couvre l’essentiel :
- Vérifier les groupes cibles avec getent group avant d’utiliser -g ou -G.
- Décider du shell : /bin/bash pour un humain, /usr/sbin/nologin pour un service.
- Choisir l’emplacement du home : /home pour les utilisateurs, /srv ou similaire pour les services.
- Fixer une date d’expiration pour tout compte utilisateur temporaire avec -e.
- Documenter le rôle du compte via -c pour faciliter les audits ultérieurs.
Appliquée systématiquement, cette grille simple réduit nettement la probabilité de se retrouver avec un « zoo » de comptes incohérents après quelques années de vie du système.
Comment activer un compte créé avec useradd qui semble inutilisable ?
Un compte créé via useradd n’a, par défaut, aucun mot de passe défini et peut parfois être associé à un shell non interactif. Pour l’activer, commencez par lui attribuer un mot de passe avec la commande sudo passwd login (en remplaçant login par l’identifiant réel). Vérifiez ensuite le shell via getent passwd login : si le champ final contient /usr/sbin/nologin ou un équivalent, redéfinissez-le avec sudo usermod -s /bin/bash login. Après ces deux étapes, le compte peut se connecter en SSH ou en console, selon la configuration du serveur.
Pourquoi choisir useradd plutôt que adduser pour l’automatisation ?
useradd est un binaire bas niveau qui ne fait que ce qu’on lui demande en ligne de commande, sans interaction ni valeurs par défaut implicites. Dans un script bash, un playbook Ansible ou tout autre outil d’industrialisation, cette prévisibilité est précieuse. adduser, qui est un script interactif sur de nombreuses distributions, attend des réponses à des questions et applique des conventions qui peuvent varier d’une version à l’autre. Pour des environnements reproductibles, useradd reste plus adapté que adduser.
Comment vérifier rapidement la configuration d’un utilisateur Linux après un useradd ?
Pour contrôler un compte après sa création, commencez par consulter ses informations dans /etc/passwd avec getent passwd login. Vous y verrez l’UID, le GID principal, le home et le shell. Vérifiez la présence du répertoire personnel avec ls -ld /home/login (ou le chemin défini avec -d). Pour le mot de passe, la commande sudo passwd -S login indique s’il est défini ou verrouillé. Enfin, la commande id login liste les groupes auxquels appartient le compte, ce qui permet de confirmer l’effet des options -g et -G.
Est-il possible de créer un utilisateur Linux sans répertoire personnel ?
Oui, c’est un scénario courant pour certains comptes de service. L’option -M de useradd empêche la création automatique du répertoire personnel, même si la configuration par défaut le prévoit. Une commande comme sudo useradd -M -s /usr/sbin/nologin logshipper crée un compte sans home et sans shell interactif. Il faut simplement s’assurer que les scripts ou services qui utilisent ce compte n’attendent pas l’existence d’un répertoire personnel classique.
Comment gérer les UIDs lors d’une migration de serveurs Linux ?
Lors d’une migration, la cohérence des UIDs est essentielle pour conserver les droits sur les fichiers, surtout si un stockage partagé (NFS, NAS) est en jeu. La méthode consiste à exporter les fichiers /etc/passwd et /etc/group de l’ancien serveur, à identifier les UIDs utilisés et à recréer les comptes sur le nouveau système avec useradd -u UID pour conserver ces identifiants. Une fois les comptes alignés, un transfert de données via rsync en préservant les propriétaires et permissions permet de retrouver un environnement fonctionnel sans devoir réappliquer toutes les ACL à la main.
