Administrer utilisateurs et groupes

Créer un compte, le rattacher aux bons groupes, le modifier sans casser les fichiers qu'il possède, puis le désactiver vraiment le jour du départ : c'est le cycle de vie d'un compte Linux. Cette page vous donne les commandes exactes de chaque étape (useradd, usermod, gpasswd, userdel, chage), la commande de vérification qui va avec, et les deux pièges qui coûtent le plus cher en production : le compte « verrouillé » qui garde son accès SSH, et les fichiers orphelins laissés derrière un compte supprimé.

Les notions de base (UID, GID, root, contenu de /etc/passwd et /etc/group) sont détaillées dans Utilisateurs et groupes Linux. Ici, on passe à l'administration : vous agissez sur le système, avec sudo.

Ce que vous allez apprendre

• Lister les comptes et les groupes réellement connus du système
• Créer un utilisateur avec son répertoire personnel et son mot de passe
• Organiser les droits avec des groupes primaires et secondaires
• Modifier et supprimer un compte sans laisser de fichiers orphelins
• Désactiver réellement un accès, y compris par clé SSH
• Vérifier l'état d'un compte avec id, chage -l et passwd -S

À quoi servent les utilisateurs et les groupes

Sous Linux, l'identité est le premier mécanisme de sécurité : le noyau n'autorise une lecture, une écriture ou une exécution qu'en fonction de l'UID (identifiant utilisateur) et des GID (identifiants de groupe) du processus qui demande l'accès.

Un utilisateur représente une identité unique. Il peut correspondre à un humain, ou à un service (nginx, postgres) qui doit tourner avec le moins de droits possible. Chaque compte possède un répertoire personnel, un shell de connexion et une liste de groupes.

Un groupe rassemble des utilisateurs qui partagent les mêmes permissions sur des ressources. C'est ce qui rend une politique d'accès maintenable : vous attribuez les droits une fois au groupe, puis vous gérez uniquement des appartenances.

Le cas typique : une équipe de développement. Vous créez un groupe developpeurs, vous donnez l'écriture au dossier /srv/projets à ce groupe, puis vous y ajoutez chaque nouvel arrivant. Aucune permission de fichier n'est retouchée à l'arrivée d'une personne de plus.

Lister les comptes et les groupes présents

Avant toute manipulation, regardez ce qui existe déjà : un compte que vous croyez absent existe peut-être en local, ou vient d'un annuaire (LDAP, Active Directory via SSSD). Créer un doublon d'UID est une source classique de fichiers accessibles par la mauvaise personne.

La commande de référence est getent : elle interroge toutes les sources déclarées dans /etc/nsswitch.conf (le fichier qui décide où le système va chercher les identités), pas seulement les fichiers locaux.

getent passwd          # tous les comptes connus du système
getent group           # tous les groupes connus du système
getent passwd paul     # la fiche d'un compte précis

Une fiche getent passwd se lit ainsi : nom, mot de passe (le x renvoie vers /etc/shadow), UID, GID principal, commentaire, répertoire personnel, shell.

Pour vous limiter aux comptes humains, filtrez sur l'UID : les distributions réservent les UID inférieurs à 1000 aux comptes système.

awk -F: '$3 >= 1000 && $1 != "nobody" { print $1, $3 }' /etc/passwd

Pour connaître les groupes d'une personne, id est plus complet que groups : il affiche les UID/GID numériques en plus des noms, ce qui permet de repérer tout de suite un décalage d'identifiant.

id paul

Sortie sur un compte fraîchement créé :

uid=1001(paul) gid=1001(paul) groups=1001(paul)

Créer un utilisateur

La commande universelle est useradd, présente sur toutes les distributions. Seule, elle ne crée pas le répertoire personnel : l'option -m est indispensable.

sudo useradd -m paul

Vérifiez immédiatement le résultat, c'est le réflexe à prendre après chaque action :

id paul
ls -ld /home/paul

Le groupe privé homonyme

Regardez la sortie de id paul : le groupe principal s'appelle paul, pas users. C'est le comportement par défaut de Debian, Ubuntu et RHEL modernes, piloté par la directive USERGROUPS_ENAB yes du fichier /etc/login.defs : useradd crée un groupe privé homonyme du compte, avec le même identifiant.

L'intérêt est un cloisonnement par défaut : comme personne d'autre n'est membre du groupe paul, les fichiers créés avec des droits de groupe généreux ne fuitent pas vers les autres comptes du serveur. C'est aussi ce qui rend le umask 002 sans danger sur ces distributions.

Deux options permettent de forcer ce comportement dans un sens ou dans l'autre :

• -U, --user-group : créer le groupe homonyme (comportement par défaut) ;
• -N, --no-user-group : ne pas le créer, le compte reçoit alors le groupe principal défini par GROUP dans /etc/default/useradd.

Définir le mot de passe

Un compte fraîchement créé n'a aucun mot de passe utilisable : le champ correspondant dans /etc/shadow contient !. La connexion par mot de passe est donc impossible tant que vous n'en définissez pas un.

sudo passwd paul

La saisie est invisible à l'écran, c'est normal. Vérifiez ensuite l'état du mot de passe, le deuxième champ doit passer de L à P :

sudo passwd -S paul

Créer un compte avec des options précises

En production, vous fixez souvent le shell, l'UID et parfois le groupe principal. L'exemple ci-dessous crée un compte dont le groupe principal est developpeurs, ce qui remplace le groupe privé homonyme :

sudo groupadd developpeurs
sudo useradd -m -s /bin/bash -g developpeurs -u 1050 pierre
id pierre

La sortie confirme les trois choix, shell mis à part :

uid=1050(pierre) gid=1001(developpeurs) groups=1001(developpeurs)

Choisir -g developpeurs signifie que tous les fichiers créés par pierre appartiendront par défaut au groupe developpeurs. C'est pratique pour un dossier partagé, mais cela affaiblit le cloisonnement décrit plus haut : réservez ce montage à des comptes projet, pas au compte d'administration d'une personne.

useradd ou adduser ?

Sur Debian et Ubuntu, adduser est un assistant interactif qui appelle useradd, crée le répertoire personnel et demande le mot de passe. Sur RHEL, adduser n'est qu'un lien vers useradd et ne pose aucune question. Un script qui compte sur le comportement Debian échoue silencieusement sur RHEL : dans un playbook ou un script d'automatisation, utilisez useradd avec ses options explicites.

Organiser les droits avec des groupes

Les groupes évitent la gestion fichier par fichier. Vous créez un groupe fonctionnel, vous lui donnez les droits sur une ressource, puis vous gérez les appartenances. C'est la base d'une politique d'accès auditable.

sudo groupadd developpeurs
getent group developpeurs

Ajouter un utilisateur à un groupe secondaire

Un compte a un seul groupe principal (celui de /etc/passwd) et autant de groupes secondaires que nécessaire. Pour un ajout, l'option -a est obligatoire :

sudo usermod -aG developpeurs paul
id paul

• -a, --append : ajoute sans toucher aux appartenances existantes ;
• -G, --groups : la liste des groupes secondaires.

usermod -G sans -a écrase tout

sudo usermod -G developpeurs paul remplace la liste des groupes secondaires par celle que vous donnez. Si paul était dans sudo, il perd son accès administrateur sur-le-champ. Notez toujours l'état avant (id paul) pour pouvoir revenir en arrière, et n'oubliez jamais le -a.

Un point qui déroute souvent : une session déjà ouverte conserve les groupes qu'elle avait au moment de la connexion. L'utilisateur doit se reconnecter pour que le nouveau groupe soit pris en compte. La vérification se fait avec id dans la nouvelle session, pas dans l'ancienne.

Retirer un utilisateur d'un groupe

gpasswd -d retire une appartenance secondaire. Le groupe principal n'est pas concerné.

sudo gpasswd -d paul developpeurs
id paul

Changer le groupe principal

Le groupe principal se change avec usermod -g. Utile quand le groupe privé homonyme n'a plus de sens, typiquement pour un compte de service qui doit écrire dans une arborescence partagée.

sudo usermod -g developpeurs paul
id paul

Attention : les fichiers déjà créés gardent leur ancien groupe. Un chgrp -R est souvent nécessaire derrière, sinon l'utilisateur ne peut plus écrire dans ses propres anciens dossiers via son nouveau groupe.

Supprimer un groupe

sudo groupdel developpeurs

La commande refuse de supprimer un groupe qui sert de groupe principal à un compte, ce qui est une protection utile :

groupdel: cannot remove the primary group of user 'paul'

Retirez d'abord ces comptes ou changez leur groupe principal. Supprimer un groupe ne supprime aucun utilisateur, mais les fichiers qui portaient ce GID se retrouvent sans groupe nommé : ls -l affichera un numéro brut à la place du nom.

Modifier un compte existant

usermod couvre le renommage, le déplacement du répertoire personnel, le changement de shell et d'UID. Ce sont des opérations à faire hors session : demandez à la personne de se déconnecter, sinon les processus en cours gardent l'ancienne identité et écrivent des fichiers avec l'ancien UID.

Objectif	Commande	Vérification
Renommer le compte	sudo usermod -l pierre paul	getent passwd pierre
Déplacer le répertoire personnel	sudo usermod -d /home/pierre -m pierre	ls -ld /home/pierre
Changer le shell	sudo usermod -s /bin/bash pierre	getent passwd pierre
Changer l'UID	sudo usermod -u 1234 pierre	id pierre

Glissez pour voir

Le renommage avec -l ne déplace pas le répertoire personnel : après usermod -l pierre paul, le compte pierre pointe toujours vers /home/paul. C'est l'option -d combinée à -m qui déplace réellement le contenu.

Le piège du changement d'UID

usermod -u réattribue automatiquement les fichiers situés dans le répertoire personnel, mais pas ceux qui se trouvent ailleurs. Après un sudo usermod -u 1234 paul sur un compte qui possédait un fichier dans /srv/app, voici l'état réel :

-rw-r--r-- 1 1234 0 0 /home/paul/notes.txt     <- réattribué
-rw-r--r-- 1 1001 0 0 /srv/app/data.txt        <- resté sur l'ancien UID

Le fichier de /srv/app affiche un UID numérique orphelin. Pire : si un autre compte reçoit un jour l'UID 1001, il héritera de ce fichier sans que personne ne l'ait décidé. Notez donc l'ancien UID avant l'opération et corrigez ce qui reste :

sudo find / -xdev -uid 1001 -exec chown 1234 {} +

Supprimer un compte proprement

La suppression est définitive et se prépare en trois temps : relever l'UID, archiver ce qui doit l'être, puis supprimer et faire le ménage.

Relever l'UID avant toute chose

C'est l'étape que tout le monde saute, et elle conditionne la suite : une fois le compte supprimé, le nom n'existe plus et vous ne pouvez plus faire de recherche par nom.

id -u pierre    # affiche par exemple 1050

Archiver le répertoire personnel

sudo tar czf /var/backups/pierre-home.tar.gz -C /home pierre

Supprimer le compte

userdel seul retire le compte des bases système mais conserve tous ses fichiers, y compris son répertoire personnel :

sudo userdel pierre

L'option -r va plus loin. Son périmètre exact, tel que le décrit son manuel (remove home directory and mail spool), est limité à deux emplacements :

• le répertoire personnel (/home/pierre) et tout son contenu ;
• la boîte mail locale (/var/mail/pierre).

sudo userdel -r pierre

Tout ce que l'utilisateur possédait ailleurs sur le disque (/srv, /var/www, /opt, /tmp) reste en place, avec un UID qui ne correspond plus à personne.

Retrouver les fichiers orphelins

Ici se cache l'erreur la plus fréquente. La recherche par nom échoue une fois le compte supprimé, puisque find doit résoudre le nom en UID :

find / -user pierre

find: 'pierre' is not the name of a known user

Deux méthodes fonctionnent réellement. La première utilise l'UID relevé avant la suppression :

sudo find / -xdev -uid 1050 -ls

La seconde ne demande rien : -nouser sélectionne les fichiers dont l'UID n'existe dans aucune base de comptes. C'est le filet de sécurité quand personne n'a noté l'UID.

sudo find / -xdev -nouser -ls

L'option -xdev limite la recherche au système de fichiers racine et évite de balayer /proc, /sys et les montages réseau, qui produisent du bruit et allongent la recherche. Répétez la commande sur chaque système de fichiers monté que vous voulez couvrir (sudo find /srv -xdev -nouser -ls).

Chaque fichier trouvé doit ensuite être réattribué à son nouveau responsable, ou supprimé si la donnée est morte :

sudo chown -R marie:developpeurs /srv/projets/api-facturation

Et les permissions sur les fichiers ?

Créer les comptes et les groupes ne sert à rien tant que les fichiers ne portent pas les bons droits. Le trio à connaître est chmod (les permissions rwx), chown (le propriétaire) et chgrp (le groupe), avec sa notation octale (750, 640) et sa notation symbolique (u+x, g-w).

Ces commandes ont leur page dédiée dans le parcours, et il n'y a aucune raison de les réapprendre ici :

• Permissions Linux : lire et comprendre les droits pour décoder ls -l, le sens de rwx sur un fichier et sur un dossier, et le umask.
• Modifier les droits avec chmod, chown et chgrp pour la notation octale, les changements récursifs et le partage d'un dossier avec un groupe.
• Affiner avec les ACL quand un seul groupe propriétaire ne suffit plus à exprimer le besoin.

Verrouiller ou désactiver un compte

Supprimer n'est pas toujours la bonne réponse. Un départ en congé longue durée, une suspension, une enquête interne : vous voulez bloquer l'accès sans perdre les fichiers ni les réglages. C'est là que la distinction entre verrouiller un mot de passe et désactiver un compte devient critique.

Verrouiller le mot de passe

sudo passwd -l paul

La commande place un ! devant le hash du mot de passe dans /etc/shadow : aucun mot de passe saisi ne peut plus correspondre. Le compte existe toujours, le répertoire personnel est conservé, et le hash d'origine est préservé, ce qui permet un retour en arrière immédiat avec passwd -u.

sudo usermod -L paul fait exactement la même chose : les deux commandes posent le même ! dans /etc/shadow. Il n'y a pas de « verrouillage global » plus fort d'un côté que de l'autre.

Verrouiller un mot de passe ne ferme pas l'accès SSH

C'est le piège classique, et le manuel de passwd le dit explicitement : le verrouillage ne désactive pas le compte. L'utilisateur peut toujours se connecter par un autre moyen d'authentification, en particulier une clé SSH déposée dans son ~/.ssh/authorized_keys.

Verrouiller le mot de passe d'un prestataire qui quitte la mission, en croyant lui avoir coupé l'accès, lui laisse en réalité son accès SSH intact.

Désactiver réellement un compte

Pour fermer un compte quel que soit le moyen d'authentification, il faut l'expirer :

sudo usermod --expiredate 1 paul

La date d'expiration est fixée au 2 janvier 1970, donc dans le passé : le compte est expiré, et toutes les connexions sont refusées, y compris par clé SSH. sudo chage -E 0 paul produit le même effet.

Une désactivation complète combine les trois gestes, dans cet ordre :

sudo usermod --expiredate 1 paul          # expirer le compte
sudo passwd -l paul                       # verrouiller le mot de passe
sudo pkill -KILL -u paul                  # fermer les sessions déjà ouvertes

Le pkill n'est pas décoratif : l'expiration bloque les nouvelles connexions, elle ne tue pas une session SSH en cours. Sans lui, la personne reste sur le serveur jusqu'à ce qu'elle se déconnecte d'elle-même.

Pour réactiver le compte, on lève l'expiration puis on déverrouille le mot de passe :

sudo usermod --expiredate "" paul
sudo passwd -u paul

Vérifier l'état d'un compte

Il faut deux commandes, car aucune ne dit tout. chage -l affiche l'expiration du compte, que passwd -S ignore complètement :

sudo chage -l paul

Account expires            : Jan 02, 1970

La ligne Account expires doit afficher une date passée pour un compte désactivé, ou never pour un compte actif. Pour l'état du mot de passe :

sudo passwd -S paul

Le deuxième champ vaut L, P ou NP. Attention à leur sens exact, car il recouvre l'écriture du champ mot de passe dans /etc/shadow :

État	Champ dans /etc/shadow	Signification
P	un hash ($y$j9T$...)	Mot de passe utilisable
L	! devant le hash	Verrouillé, le hash est conservé, passwd -u le rétablit
L	* seul	Jamais de mot de passe utilisable : cas normal des comptes de service
NP	champ vide	Aucun mot de passe : connexion possible sans en saisir, à corriger d'urgence

Glissez pour voir

Le * n'est donc pas la marque d'un verrouillage : c'est l'état d'origine d'un compte système qui n'a jamais eu de mot de passe, et il n'y a rien à « déverrouiller » derrière. Seul le ! signale une action de verrouillage.

Un compte expiré garde un mot de passe parfaitement valide : passwd -S affiche toujours P. C'est bien chage -l qui fait foi pour savoir si un accès est réellement fermé.

Sécurité et moindre privilège

La gestion des comptes est la première surface d'attaque d'un serveur : un compte oublié, c'est une porte ouverte qui ne déclenche aucune alerte. Quatre règles couvrent l'essentiel du risque.

Un compte par personne, jamais de compte partagé. Un compte admin utilisé par cinq personnes rend la traçabilité impossible : les journaux ne diront jamais qui a lancé la commande destructrice, et le départ d'une seule personne oblige à changer le secret pour tout le monde.

Les comptes de service n'ont pas de shell. Un service n'a aucune raison de pouvoir ouvrir une session interactive. Créez-le avec -r (compte système, UID inférieur à 1000) et un shell qui refuse la connexion :

sudo useradd -r -s /usr/sbin/nologin -M exportateur-metriques

Le chemin du shell diffère selon la distribution : /usr/sbin/nologin sur Debian et Ubuntu, /sbin/nologin sur RHEL. L'option -M évite de créer un répertoire personnel inutile.

Passez par sudo, pas par root. Donnez les droits nécessaires via sudo et limitez les commandes autorisées, au lieu de distribuer un accès root complet. Un accès root partagé présente le même défaut de traçabilité qu'un compte partagé.

Auditez régulièrement. Deux commandes suffisent à repérer les dérives : la première liste l'état du mot de passe de tous les comptes, la seconde montre qui ne s'est jamais connecté.

sudo passwd -Sa | awk '$2 == "NP" { print "SANS MOT DE PASSE:", $1 }'
lastlog | grep -i "never logged in"

Tout compte humain qui ressort en NP, ou qui ne s'est jamais connecté depuis des mois, doit être expiré puis supprimé après archivage. Le rollback est simple tant que vous n'avez pas supprimé : usermod --expiredate "" <compte> remet l'accès en service.

Dépannage

Les erreurs de gestion de comptes se ressemblent toutes : l'action semble avoir réussi, mais l'accès ou les droits ne suivent pas. Voici les symptômes les plus fréquents et leur cause réelle.

Symptôme	Cause probable	Solution
L'ancien salarié se connecte encore en SSH	Mot de passe verrouillé, mais compte non expiré	sudo usermod --expiredate 1 <compte> puis sudo pkill -KILL -u <compte>
find: '<nom>' is not the name of a known user	Le compte a été supprimé, find -user ne peut plus résoudre le nom	sudo find / -xdev -nouser -ls
L'utilisateur ajouté à un groupe n'a toujours pas les droits	Sa session date d'avant l'ajout	Déconnexion/reconnexion, puis contrôle avec id
ls -l affiche un nombre à la place du propriétaire	Fichier orphelin après userdel ou usermod -u	sudo chown <nouveau_proprietaire> <fichier>
groupdel: cannot remove the primary group of user	Le groupe est le groupe principal d'un compte	Changer ce groupe principal (usermod -g) avant de supprimer
useradd: UID 1050 is not unique	L'UID est déjà pris par un autre compte	Choisir un autre UID, ou laisser le système l'attribuer

Glissez pour voir

Bonnes pratiques

Ces habitudes coûtent quelques secondes à la création d'un compte et évitent des heures d'archéologie six mois plus tard.

Adoptez une convention de nommage. Minuscules, sans accent ni espace, format cohérent (prenom.nom). Pour les groupes, nommez l'activité (dev, infra, compta), pas la personne ni le serveur : un groupe survit à ceux qui le composent.

N'éditez jamais /etc/passwd, /etc/group ou /etc/shadow à la main. Un caractère de travers dans ces fichiers peut empêcher toute connexion, y compris celle de root. Utilisez usermod, groupmod, gpasswd, ou les éditeurs vipw et vigr qui posent un verrou et contrôlent la syntaxe avant d'écrire.

Forcez le changement de mot de passe à la première connexion. Le mot de passe initial transite forcément par un canal imparfait : il ne doit pas survivre à la première session.

sudo chage -d 0 paul

Générez ce mot de passe initial avec un outil, pas avec votre imagination : openssl rand -base64 18, ou pwgen -s 16 1 si vous installez le paquet pwgen.

Gérez des groupes, pas des permissions individuelles. Un droit posé directement sur un compte est invisible dans une revue d'accès. Un droit posé sur un groupe se lit d'un coup d'oeil avec getent group, et se retire avec un seul gpasswd -d.

Documentez les mouvements. Qui a été créé, dans quels groupes, par qui, et pourquoi. Le jour de l'audit, ou le jour où un accès inexpliqué apparaît, cette trace vaut tous les outils.

Mettre en pratique

Le cycle de vie d'un compte s'apprend les mains sur le clavier. Deux labs prolongent ce guide : le premier vous fait créer un compte avec un UID, un shell et des groupes imposés, en vérifiant chaque choix avec id ; le second vous fait poser une politique d'expiration et de complexité des mots de passe, puis prouver qu'elle s'applique réellement.

Lab pratique

Créer un compte local avec UID, shell et groupes précis

$ dsoxlab run l2-user-lifecycle

Environnement : VM·Durée : ~20 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run l2-user-lifecycle
dsoxlab check l2-user-lifecycle

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Lab pratique

Imposer une politique d'expiration et de complexité des mots de passe

$ dsoxlab run l2-password-policy

Environnement : VM·Durée : ~25 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run l2-password-policy
dsoxlab check l2-password-policy

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• useradd -m crée un groupe privé homonyme, pas un groupe users : c'est le comportement par défaut sur Debian, Ubuntu et RHEL, piloté par USERGROUPS_ENAB yes dans /etc/login.defs.
• usermod -aG sans le -a écrase toutes les appartenances secondaires existantes, y compris sudo. Et un nouveau groupe n'est actif qu'après reconnexion.
• passwd -l et usermod -L font la même chose : ils posent un ! devant le hash et ne bloquent pas les clés SSH. Seule l'expiration (usermod --expiredate 1) ferme réellement un compte.
• chage -l fait foi, pas passwd -S : un compte expiré affiche toujours un mot de passe P. La ligne Account expires est la seule preuve.
• Dans /etc/shadow, ! = verrouillé, * = jamais de mot de passe (comptes de service), champ vide = aucun mot de passe, donc à corriger d'urgence.
• userdel -r ne supprime que le répertoire personnel et la boîte mail. Tout ce que le compte possédait dans /srv, /var/www ou /opt reste en place.
• Relevez l'UID avec id -u avant de supprimer : après coup, find -user échoue et il ne reste que sudo find / -xdev -nouser -ls pour retrouver les fichiers orphelins.
• Un compte de service n'a pas de shell : useradd -r -s /usr/sbin/nologin (/sbin/nologin sur RHEL), et les humains passent par sudo, jamais par root.

FAQ : Questions fréquentes

Qu'est-ce qu'un utilisateur sous Linux ?

Un utilisateur sous Linux est une entité qui dispose d'un compte permettant d'accéder au système. Chaque utilisateur est identifié par un nom unique (login) et un identifiant numérique (UID). Il existe plusieurs types d'utilisateurs : le superutilisateur (root) qui a tous les droits, les comptes systèmes utilisés par les services, et les comptes standards destinés aux humains.

Quel est le rôle des groupes sous Linux ?

Les groupes sous Linux permettent de gérer collectivement les droits d'accès aux fichiers et ressources. Chaque groupe a un nom et un identifiant (GID). Les utilisateurs appartiennent à un groupe principal et peuvent faire partie de groupes secondaires pour obtenir des accès supplémentaires aux ressources partagées.

Quels sont les fichiers importants pour la gestion des utilisateurs et groupes sous Linux ?

Les principaux fichiers sont : /etc/passwd (informations de base des utilisateurs), /etc/shadow (mots de passe chiffrés), /etc/group (informations sur les groupes) et /etc/gshadow (informations sensibles sur les groupes). Ces fichiers permettent de gérer l'authentification et les permissions.

Comment créer et gérer un utilisateur sous Linux ?

Pour créer un utilisateur, la commande useradd est utilisée ; elle ajoute une ligne dans /etc/passwd, crée un répertoire personnel et l'associe à un groupe principal. Pour modifier un utilisateur (changer de shell, ajouter à des groupes), on utilise usermod. Pour supprimer un utilisateur, on utilise userdel, avec possibilité de conserver ou non ses fichiers.

Comment fonctionne la gestion des groupes sous Linux ?

La gestion des groupes se fait avec des commandes comme groupadd (création), groupmod (modification) et groupdel (suppression). Les groupes permettent d’attribuer des permissions à plusieurs utilisateurs simultanément, ce qui facilite l’administration des droits d’accès aux ressources partagées.

Qu'est-ce que l'élévation de privilèges sous Linux ?

L'élévation de privilèges permet à un utilisateur d'exécuter des commandes avec des droits supérieurs, généralement ceux de root. L'outil sudo est principalement utilisé pour cela, en permettant d'accorder temporairement ces droits à des utilisateurs autorisés. Les règles sont définies dans le fichier /etc/sudoers.

Quelles sont les bonnes pratiques pour sécuriser la gestion des utilisateurs sous Linux ?

Il est recommandé de créer des comptes distincts pour chaque utilisateur, de limiter l'usage du compte root, d'utiliser sudo avec parcimonie, de surveiller les fichiers /etc/passwd et /etc/shadow, et de revoir régulièrement les droits des utilisateurs et des groupes pour appliquer le principe du moindre privilège.

×

📖 Voir la documentation →