useradd vs adduser : Différences Techniques, Cas d’Utilisation et Quand Utiliser Chacun

`useradd` est un utilitaire binaire de bas niveau disponible sur pratiquement toutes les distributions Linux qui crée des comptes utilisateurs en écrivant directement dans `/etc/passwd`, `/etc/shadow`, et `/etc/group`. `adduser` est un script wrapper de plus haut niveau — généralement écrit en Perl sur les systèmes basés sur Debian — qui appelle `useradd` en interne tout en automatisant la création du répertoire personnel, le remplissage des fichiers squelettes, la demande de mot de passe et la collecte des champs GECOS. La différence pratique ne se limite pas à l’ergonomie : choisir le mauvais outil dans un pipeline de provisionnement automatisé ou sur un système non-Debian peut produire silencieusement des comptes utilisateurs incomplets.

Les deux commandes enregistrent finalement un utilisateur dans la base de données d’authentification du système, mais leur comportement diverge significativement en termes de valeurs par défaut, d’interactivité, de portabilité et de scriptabilité. Ce guide couvre chaque distinction technique dont un administrateur a besoin pour prendre une décision éclairée.

Ce que useradd fait réellement en coulisses

`useradd` fait partie du paquet shadow-utils (parfois appelé `passwd` sur les anciennes distributions). Lorsqu’il est invoqué, il effectue une série d’opérations atomiques :

1. Lit `/etc/login.defs` pour déterminer les plages UID par défaut, les politiques de vieillissement des mots de passe, et si un répertoire personnel doit être créé par défaut.
2. Lit `/etc/default/useradd` pour le shell par défaut, le chemin du répertoire squelette et le comportement des groupes.
3. Écrit une nouvelle entrée dans `/etc/passwd` et `/etc/shadow`.
4. Crée optionnellement un répertoire personnel et copie les fichiers depuis `/etc/skel` si `-m` est explicitement passé.
5. Crée optionnellement un groupe privé correspondant au nom d’utilisateur si `USERGROUPS_ENAB` est défini sur `yes` dans `/etc/login.defs`.

Un point critique que beaucoup de guides omettent : sur les distributions basées sur Red Hat (RHEL, CentOS, Rocky Linux, AlmaLinux), `useradd` crée le répertoire personnel par défaut car `/etc/login.defs` définit `CREATE_HOME yes`. Sur Debian et Ubuntu, ce n’est pas le cas — le flag `-m` est obligatoire sauf si vous modifiez `/etc/default/useradd`. Cette asymétrie de comportement est une source fréquente de confusion lorsque les administrateurs migrent entre familles de distributions.

Flags principaux et leur comportement

Exemple pratique de useradd avec toutes les options

“`bash

useradd

-m

-d /srv/appuser

-s /bin/bash

-u 1500

-g developers

-G sudo,docker

-e 2025-12-31

-c "Application Service Account"

appuser

passwd appuser

“`

Aucun mot de passe n’est défini tant que `passwd` n’est pas appelé. Jusqu’alors, le compte existe mais est verrouillé — l’entrée shadow contient `!` comme hachage de mot de passe, empêchant la connexion par authentification par mot de passe. La connexion par clé SSH, cependant, n’est pas affectée par cet état.

Ce que adduser fait réellement en coulisses

Sur Debian et Ubuntu, `adduser` est un script Perl situé à `/usr/sbin/adduser`. Il lit sa propre configuration depuis `/etc/adduser.conf` — un fichier distinct de `/etc/login.defs` — puis appelle `useradd` avec les flags appropriés basés sur cette configuration et les entrées utilisateur.

Le script effectue des étapes supplémentaires que `useradd` seul ne fait pas :

• Demande interactivement un mot de passe et le confirme avec une deuxième saisie.
• Collecte les champs GECOS (nom complet, numéro de chambre, téléphone professionnel, téléphone personnel, autre) via des invites guidées.
• Copie les fichiers squelettes depuis `/etc/skel` automatiquement sans nécessiter `-m`.
• Définit la propriété et les permissions correctes sur le répertoire personnel.
• Ajoute optionnellement l’utilisateur aux groupes supplémentaires définis dans `/etc/adduser.conf`.

Sur les systèmes basés sur Red Hat, `adduser` est généralement un lien symbolique vers `useradd`, ce qui signifie qu’il se comporte de manière identique au binaire de bas niveau — il n’y a pas de wrapper interactif. C’est le problème de portabilité le plus important lors de l’écriture de scripts multi-distributions.

Fichier de configuration adduser : /etc/adduser.conf

Directives clés dans `/etc/adduser.conf` qui affectent le comportement :

“`

DSHELL=/bin/bash # Default shell

DHOME=/home # Parent directory for home directories

GROUPHOMES=no # Whether to create group-named subdirectories

LETTERHOMES=no # Whether to use first-letter subdirectories

USERGROUPS=yes # Create a group with the same name as the user

USERS_GID=100 # Default GID if USERGROUPS=no

DIR_MODE=0755 # Permissions on new home directories

SETGID_HOME=no

QUOTAUSER=""

SKEL=/etc/skel

SKEL_IGNORE_REGEX="dpkg-(old|new|dist|tmp)"

“`

Modifier ce fichier vous permet de standardiser la création d’utilisateurs sur un parc de serveurs Debian/Ubuntu sans passer de flags à chaque fois.

Exemple pratique de adduser

“`bash

adduser customuser

“`

La session interactive ressemble à ceci :

“`

Adding user 'customuser' …

Adding new group 'customuser' (1001) …

Adding new user 'customuser' (1001) with group 'customuser' …

Creating home directory '/home/customuser' …

Copying files from '/etc/skel' …

New password:

Retype new password:

passwd: password updated successfully

Changing the user information for customuser

Enter the new value, or press ENTER for the default

Full Name []: Jane Smith

Room Number []:

Work Phone []:

Home Phone []:

Other []:

Is the information correct? [Y/n] Y

“`

Pour ajouter un utilisateur existant à un groupe de manière non interactive avec `adduser` :

“`bash

adduser customuser sudo

“`

C’est une fonctionnalité notable : `adduser` sert également d’outil de gestion des appartenances aux groupes, ce que `useradd` ne reproduit pas en une seule commande.

Comparaison côte à côte

Quand utiliser useradd

Automatisation et Infrastructure-as-Code

`useradd` est le bon choix dans tout contexte non interactif : playbooks Ansible, provisionneurs Terraform, instructions `RUN` Docker, scripts cloud-init et pipelines CI/CD. Il produit une sortie déterministe sans dépendance à stdin.

“`bash

Ansible task equivalent

useradd -m -s /bin/bash -G sudo -c "Deploy User" deployuser

echo "deployuser:$(openssl passwd -6 'securepassword')" | chpasswd

“`

Portabilité multi-distributions

Tout script shell destiné à s’exécuter à la fois sur des systèmes basés sur Debian et RHEL doit utiliser `useradd`. S’appuyer sur le comportement de `adduser` produira des échecs silencieux ou un comportement inattendu sur CentOS, Fedora, Rocky Linux ou Alpine Linux.

Comptes système et de service

La création de comptes de service verrouillés sans shell de connexion pour les démons est une spécialité de `useradd` :

“`bash

useradd -r -s /usr/sbin/nologin -d /var/lib/myservice -m myservice

“`

Le flag `-r` attribue un UID inférieur au seuil des comptes système, signale aux administrateurs qu’il ne s’agit pas d’un compte utilisateur humain, et constitue le modèle standard pour le déploiement d’applications sur les environnements d’hébergement VPS où l’isolation des services est critique.

Contrôle précis des UID/GID

Dans les environnements NFS, l’orchestration de conteneurs, ou lors de la synchronisation des bases de données utilisateurs sur plusieurs serveurs, des UID et GID cohérents sont obligatoires. `useradd -u 1500 -g 1500` le garantit ; `adduser` n’offre pas le même contrôle déterministe sans une configuration significative.

Quand utiliser adduser

Configuration interactive du serveur

Lors du provisionnement manuel d’un nouveau Serveur Dédié et de l’ajout des premiers comptes utilisateurs humains, `adduser` réduit le risque de configuration incomplète. Les invites guidées rendent presque impossible l’oubli de l’étape du mot de passe.

Environnements Debian/Ubuntu avec valeurs par défaut standard

Si toute votre infrastructure fonctionne sous Debian ou Ubuntu et que vous créez des utilisateurs standard avec répertoire personnel, `adduser` produit des résultats corrects plus rapidement avec moins de flags à mémoriser.

Gestion des groupes après création

La syntaxe `adduser username groupname` pour ajouter un utilisateur existant à un groupe existant est plus propre que `usermod -aG groupname username`, bien que les deux soient valides.

Formation des administrateurs débutants

La nature interactive de `adduser` en fait un meilleur outil pédagogique. Il met en avant les champs importants (mot de passe, nom complet) et masque la complexité des plages UID et des répertoires squelettes jusqu’à ce que l’administrateur soit prêt à les apprendre.

Cas limites critiques et pièges

Le piège du répertoire personnel manquant

Sur Debian/Ubuntu, exécuter `useradd username` sans `-m` crée l’utilisateur mais pas le répertoire personnel. L’utilisateur peut se connecter (une fois qu’un mot de passe est défini), mais `$HOME` n’existera pas, provoquant des échecs dans toute application qui écrit dans le répertoire personnel lors de la première connexion — y compris `.bash_history`, `.ssh/authorized_keys`, et de nombreux répertoires de configuration d’applications.

“`bash

Verify home directory existence after creation

ls -la /home/newuser || echo "Home directory missing — run: mkhomedir_helper newuser"

“`

Verrouillage du fichier shadow

Les deux commandes verrouillent `/etc/shadow` lors des écritures. Dans les scripts de provisionnement à haute concurrence créant des dizaines d’utilisateurs simultanément, cela provoque des conditions de course. Utilisez une file d’attente ou une exécution séquentielle lors de la création d’utilisateurs en masse.

Collision d’UID dans les environnements conteneurisés

Lors du déploiement d’applications sur un VPS avec cPanel ou d’autres environnements de panneaux de contrôle, le panneau lui-même gère l’allocation des UID. Exécuter `useradd` manuellement avec un UID codé en dur peut entrer en collision avec les UID attribués par le panneau, provoquant des erreurs de permission sur plusieurs comptes. Vérifiez toujours `getent passwd | awk -F: '{print $3}' | sort -n` avant de spécifier un UID manuellement.

adduser –disabled-password pour le scripting

Si vous devez utiliser `adduser` dans un script (par exemple, pour exploiter ses valeurs par défaut `/etc/adduser.conf`), supprimez les invites interactives :

“`bash

adduser –disabled-password –gecos "Automated User,,," scriptuser

echo "scriptuser:$(openssl passwd -6 'password')" | chpasswd

“`

Le flag `–gecos` accepte une chaîne séparée par des virgules correspondant aux champs GECOS, éliminant toutes les invites interactives.

Intégration PAM et NSS

Ni `useradd` ni `adduser` ne configure les modules PAM ou les entrées NSS (Name Service Switch) pour LDAP, Active Directory ou d’autres systèmes d’authentification centralisés. Sur les serveurs intégrés avec `sssd` ou `winbind`, la création d’utilisateurs locaux avec l’une ou l’autre commande crée des comptes qui peuvent entrer en conflit avec ou être remplacés par des comptes de services d’annuaire. Vérifiez `/etc/nsswitch.conf` avant de créer des utilisateurs locaux sur des systèmes joints à un domaine.

Personnalisation des fichiers squelettes

Les deux commandes copient depuis `/etc/skel` par défaut. Pour les équipes gérant des environnements d’hébergement web mutualisé où chaque utilisateur a besoin d’un `.bashrc`, `.vimrc`, ou d’une configuration SSH préconfigurée, remplir `/etc/skel` avant d’exécuter l’une ou l’autre commande est la bonne approche — et non modifier les fichiers après la création du compte.

Vérification de la création d’utilisateurs

Quelle que soit la commande utilisée, vérifiez le résultat :

“`bash

Check passwd entry

getent passwd newuser

Check shadow entry (requires root)

getent shadow newuser

Check group memberships

groups newuser

id newuser

Verify home directory and permissions

ls -la /home/newuser

Test login shell

su -s /bin/bash – newuser -c "echo login successful"

“`

Modification et suppression d’utilisateurs

`useradd` et `adduser` créent uniquement des comptes. La gestion post-création utilise des commandes différentes :

• `usermod` — Modifier les attributs d’un utilisateur existant (shell, groupes, répertoire personnel, expiration).
• `userdel` / `deluser` — Supprimer des comptes. `deluser –remove-home username` sur Debian supprime également le répertoire personnel et le spool de courrier.
• `passwd` — Définir ou modifier les mots de passe, verrouiller/déverrouiller les comptes.
• `chage` — Gérer les politiques de vieillissement et d’expiration des mots de passe.

“`bash

Lock an account without deleting it

usermod -L username

Unlock

usermod -U username

Force password change on next login

chage -d 0 username

“`

Matrice de décision pratique

Utilisez cette liste de contrôle pour sélectionner la bonne commande :

• Le script s’exécute-t-il sur un système non-Debian ou doit-il être portable ? Utilisez `useradd`.
• S’agit-il d’un environnement automatisé et non interactif (CI/CD, Ansible, Docker) ? Utilisez `useradd`.
• Avez-vous besoin d’un UID/GID spécifique pour la cohérence NFS ou des conteneurs ? Utilisez `useradd -u -g`.
• Créez-vous un compte système/service sans shell de connexion ? Utilisez `useradd -r -s /usr/sbin/nologin`.
• Êtes-vous sur Debian/Ubuntu, en train de créer un compte utilisateur humain standard de manière interactive ? Utilisez `adduser`.
• Voulez-vous ajouter un utilisateur existant à un groupe avec une commande simple ? Utilisez `adduser username groupname`.
• Rédigez-vous de la documentation ou formez-vous des administrateurs débutants sur Debian ? Utilisez `adduser`.
• Avez-vous besoin de personnaliser l’emplacement du répertoire personnel, l’expiration ou le shell de manière non interactive à grande échelle ? Utilisez `useradd` avec des flags explicites.

Une bonne hygiène des comptes utilisateurs est fondamentale pour la sécurité des serveurs. Que vous gériez un seul VPS ou un parc de Serveurs Dédiés, comprendre exactement ce que chaque commande écrit sur le disque — et ce qu’elle laisse non défini — prévient la classe d’escalades de privilèges et d’échecs d’authentification qui résultent d’un provisionnement de comptes incomplet.

—

FAQ

Est-ce que useradd crée un répertoire personnel par défaut ?

Cela dépend de la distribution. Sur les systèmes basés sur Red Hat (RHEL, CentOS, Rocky Linux), `CREATE_HOME yes` dans `/etc/login.defs` amène `useradd` à créer automatiquement le répertoire personnel. Sur Debian et Ubuntu, aucun répertoire personnel n’est créé sauf si vous passez explicitement le flag `-m`.

Est-ce que adduser est disponible sur CentOS ou Rocky Linux ?

Sur les distributions basées sur RHEL, `adduser` est un lien symbolique vers `useradd`, et non le wrapper Perl interactif trouvé sur Debian/Ubuntu. Exécuter `adduser username` sur CentOS se comporte de manière identique à `useradd username` — pas d’invites, pas de répertoire personnel automatique selon les valeurs par défaut de style Debian.

Comment utiliser adduser de manière non interactive dans un script ?

Passez `–disabled-password` pour ignorer l’invite de mot de passe et `–gecos ""` pour ignorer les invites de champs GECOS : `adduser –disabled-password –gecos "" username`. Définissez le mot de passe ensuite avec `echo "username:password" | chpasswd` ou en injectant un hachage `openssl passwd -6`.

Quelle est la différence entre /etc/login.defs et /etc/adduser.conf ?

`/etc/login.defs` est le fichier de configuration système lu par `useradd`, `userdel`, et `usermod` — il contrôle les plages UID/GID, les valeurs par défaut de vieillissement des mots de passe et le comportement de création des répertoires personnels. `/etc/adduser.conf` est lu exclusivement par les scripts Perl `adduser` et `deluser` sur les systèmes basés sur Debian et contrôle des valeurs par défaut de plus haut niveau comme le shell par défaut, le chemin parent du répertoire personnel et le répertoire squelette.

Puis-je mélanger useradd et adduser en toute sécurité sur le même serveur Debian ?

Oui. Les deux écrivent finalement dans les mêmes fichiers `/etc/passwd`, `/etc/shadow`, et `/etc/group`. Les comptes créés avec l’une ou l’autre commande sont indiscernables au niveau système. La seule préoccupation pratique est la cohérence : si votre équipe utilise `adduser` de manière interactive et qu’un script d’automatisation utilise `useradd` sans `-m`, vous pourriez vous retrouver avec certains utilisateurs sans répertoires personnels. Standardisez sur une approche par environnement et documentez-la.