Vue d’ensemble
Garantir la sécurité d’un serveur Linux repose avant tout sur une gestion rigoureuse des accès et un cloisonnement strict des privilèges accordés à chaque intervenant. Dans l’écosystème Ubuntu, l’utilitaire adduser s’impose comme la solution de référence pour approvisionner de nouveaux profils sans risquer d’erreurs de configuration manuelle. Ce tutoriel détaille les cas d’usage concrets de cette commande, met en lumière ses distinctions fondamentales face à l’utilitaire bas niveau useradd, et aborde les réglages indispensables pour verrouiller les permissions des répertoires personnels.
Prise en main de adduser : automatisation et déploiement interactif ou scripté
Avant d’initier la configuration des comptes, assurons-nous que le système dispose des utilitaires d’administration et de gestion des mots de passe dans leurs versions les plus récentes.
Conçu comme une surcouche conviviale en Perl au-dessus des commandes UNIX traditionnelles, adduser configure automatiquement l’environnement de travail de l’utilisateur, de l’arborescence personnelle à l’interpréteur de commandes par défaut.
L’utilisation conjointe des paramètres --disabled-password et --gecos permet de contourner les invites interactives, une approche particulièrement adaptée aux scripts d’automatisation et aux pipelines CI/CD.
⚙️ [Options essentielles]
--home DIR : Définit un emplacement personnalisé pour le répertoire personnel au lieu de l’arborescence standard.--shell SHELL : Attribue un shell de connexion spécifique à la place de l’interpréteur défini par défaut.--gecos GECOS : Renseigne en une seule passe les métadonnées de l’utilisateur (nom complet, bureau, coordonnées téléphoniques) sans déclencher le questionnaire interactif.--disabled-password : Initialise le compte sans mot de passe défini, bloquant temporairement les connexions directes tant qu’un secret n’a pas été configuré.--disabled-login : Crée l’identifiant tout en interdisant formellement l’accès au shell interactif.--ingroup GROUP : Associe immédiatement le nouvel arrivant à un groupe primaire déjà déclaré sur le système.--system : Génère un profil réservé aux démons et services d’arrière-plan, sans attribution de droits utilisateur standard.
L’utilitaire chpasswd lit les couples identifiant:mot de passe depuis l’entrée standard, ce qui élimine toute saisie manuelle lors des phases de déploiement en masse.
Nous pouvons ainsi définir de manière totalement sécurisée le mot de passe du profil testuser préparé à l’étape précédente.
La commande id extrait les métriques fondamentales rattachées au profil : son identifiant numérique unique (UID), son groupe principal (GID) ainsi que l’ensemble des affiliations secondaires.
L’examen de cette sortie valide la cohérence des paramètres appliqués lors de la création de testuser.
Une inspection détaillée du répertoire personnel au moyen de ls -la confirme que l’environnement utilisateur a été correctement initialisé.
On y retrouve les fichiers d’initialisation cachés (.bashrc, .profile), dupliqués depuis le modèle système /etc/skel avec des droits de propriété parfaitement calqués sur le nouvel utilisateur.
Gestion des groupes secondaires et élévation de privilèges (sudo)
Pour organiser les droits d’accès au sein de nos équipes techniques, nous préparons un groupe dédié à l’aide de l’instruction sudo groupadd -f devops.
Grâce au commutateur -f, la commande s’exécute de façon idempotente, ignorant l’opération si le groupe existe déjà sans renvoyer de code d’erreur.
L’intégration d’un compte au sein d’une équipe existante s’effectue avec une syntaxe élémentaire : il suffit de fournir le nom de l’utilisateur suivi du groupe cible.
Sous Ubuntu, cette approche évite de manipuler les options complexes de usermod, garantissant une gestion des appartenances fluide et sans risque d’écrasement involontaire.
L’octroi des droits d’administration système s’opère naturellement en intégrant testuser au groupe privilégié sudo.
Tout membre inscrit dans cette délégation bénéficie de la faculté d’exécuter des opérations à haute responsabilité avec les prérogatives du superutilisateur.
Pour faire un état des lieux complet des affiliations d’un compte, la commande groups reste l’outil le plus direct.
Le résultat confirme l’appartenance effective du compte tant à son groupe initial qu’aux groupes complémentaires devops et sudo.
L’invocation de sudo -l -U permet d’auditer précisément le périmètre d’action concédé à l’utilisateur dans les règles du fichier sudoers.
La mention (ALL : ALL) ALL atteste que le compte dispose désormais d’une latitude d’administration totale sur la machine hôte.
Configuration de comptes de service pour démons système (–system)
L’exécution sécurisée d’applications en arrière-plan exige l’emploi de profils dédiés : l’instruction sudo adduser --system --no-create-home --group appservice crée simultanément le compte applicatif et son groupe associé.
Le drapeau --system cantonne l’identifiant dans une plage réservée (UID/GID inférieurs à 1000), tandis que --no-create-home restreint la surface d’attaque en évitant d’allouer un dossier utilisateur non nécessaire.
En interrogeant la base des comptes locaux via getent passwd appservice, on visualise les restrictions de sécurité mises en place.
Le système a redirigé le dossier personnel vers /nonexistent et assigné /usr/sbin/nologin en guise de shell, neutralisant d’office toute tentative d’ouverture de session interactive.
Un coup d’œil dans le registre des groupes permet d’attester de la bonne configuration du groupe système correspondant.
L’option --group a bien généré une entité appservice dotée d’un GID dédié (ici 103), garantissant l’isolation des processus applicatifs.
L’appel à id appservice vient certifier la cohérence de l’allocation d’identifiants effectuée par l’OS.
On vérifie immédiatement que l’UID 102 et le GID 103 se situent bien dans le segment technique du système, loin des plages attribuées aux utilisateurs humains (commençant conventionnellement à 1000).
Différences clés avec useradd et suppression propre des comptes via deluser
Le comportement prévisible de adduser découle des directives centralisées dans /etc/adduser.conf, notamment la politique de masquage des répertoires (DIR_MODE) et l’interpréteur par défaut (DSHELL).
À l’inverse de la commande bas niveau useradd qui omet fréquemment la création du dossier utilisateur sans option explicite, adduser applique ces standards rigoureux (permissions strictes en 0750 ou 0700, shell /bin/bash) pour offrir un environnement immédiatement sécurisé.
Lorsque le cycle de vie d’un compte s’achève, l’instruction sudo deluser --remove-home testuser purge l’identifiant tout en effaçant l’ensemble de ses fichiers personnels et ses boîtes aux lettres locales.
Omettre la suppression de ces dossiers créerait des fichiers orphelins sur le système de fichiers, susceptibles d’être réappropriés par inadvertance si un futur utilisateur hérite du même UID.
Pour démanteler un composant applicatif, l’option --system passée à deluser sécurise la procédure de nettoyage.
Ce garde-fou technique vérifie expressément la nature du compte avant sa suppression, empêchant toute destruction accidentelle d’un profil humain ordinaire.
La maintenance d’une infrastructure saine implique également d’épurer les groupes secondaires devenus obsolètes via sudo groupdel devops 2>/dev/null || true.
Ce geste d’assainissement élimine les résidus de configuration qui encombrent inutilement la base d’administration des accès.
Enfin, exécuter id testuser || true permet de valider avec certitude l’absence définitive du compte au sein du système.
Si des données devaient encore subsister, cela indiquerait qu’un processus résiduel est en cours d’exécution sous cette identité ou qu’un verrouillage d’annuaire bloque la finalisation du retrait.
Vous maîtrisez à présent les patterns indispensables pour intégrer, segmenter et purger des utilisateurs sous Ubuntu avec un haut niveau de sécurité opérationnelle.
Appliquez ces bonnes pratiques au quotidien pour préserver l’intégrité de vos environnements de production et faciliter l’automatisation de vos serveurs.