04 - Utilisateurs, groupes et sudo
Ce que tu vas apprendre
- Creer et gerer des utilisateurs (adduser, useradd, passwd)
- Les fichiers /etc/passwd et /etc/shadow
- Les groupes et pourquoi ils comptent
- sudo vs su et le fichier sudoers
- Pourquoi ne jamais bosser en root
Prerequisites
Comprendre les permissions. Voir l'article sur les permissions.
Le jour ou j'ai casse un serveur en root
Il y a quelques annees, je bossais sur un serveur de staging. Pour aller plus vite, j'avais fait su - pour passer root et éviter de taper sudo toutes les deux secondes. J'etais en train de nettoyer des vieux logs, et j'ai tape rm -rf /var/log/ au lieu de rm -rf /var/log/old/. En root, pas de confirmation, pas de filet. Les logs de tous les services, partis. Le monitoring s'est affole, le serveur est devenu impossible a debugger. Depuis ce jour, je ne bosse plus jamais en root.
Creer un utilisateur
Deux commandes existent. adduser est la version interactive (Debian/Ubuntu), useradd est la version bas niveau :
bash# adduser : interactif, cree le home, demande le mot de passe
sudo adduser nicolas
# Adding user 'nicolas' ...
# Adding new group 'nicolas' (1001) ...
# Adding new user 'nicolas' (1001) with group 'nicolas' ...
# Creating home directory '/home/nicolas' ...
# New password:
# useradd : bas niveau, il faut tout specifier
sudo useradd -m -s /bin/bash -G sudo,docker deployer
# -m : cree le home directory
# -s : shell par defaut
# -G : groupes supplementaires
# Definir/changer un mot de passe
sudo passwd nicolas
# Supprimer un utilisateur
sudo userdel nicolas # Supprime l'utilisateur (garde le home)
sudo userdel -r nicolas # Supprime l'utilisateur ET son home
Mon conseil : utilise adduser sur Debian/Ubuntu, c'est plus simple. useradd est utile dans les scripts ou les Dockerfiles.
/etc/passwd et /etc/shadow
Tous les utilisateurs sont listes dans /etc/passwd :
bash$ cat /etc/passwd | grep nicolas
nicolas:x:1000:1000:Nicolas Nguyen,,,:/home/nicolas:/bin/bash
Le format est : login:password:UID:GID:commentaire:home:shell
Le x dans le champ password signifie que le mot de passe est dans /etc/shadow (fichier lisible uniquement par root) :
bash$ sudo cat /etc/shadow | grep nicolas
nicolas:$6$xyz...hashlong...:19815:0:99999:7:::
Le hash commence par $6$ (SHA-512) ou $y$ (yescrypt). Tu ne verras jamais le mot de passe en clair.
Quelques utilisateurs système que tu croiseras souvent :
bashroot:x:0:0:root:/root:/bin/bash # UID 0 = dieu
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin # Serveur web
postgres:x:108:117:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
Note le /usr/sbin/nologin : ces comptes ne peuvent pas se connecter en interactif. C'est voulu.
Les groupes
Les groupes permettent de partager des permissions entre utilisateurs :
bash# Voir tes groupes
$ id
uid=1000(nicolas) gid=1000(nicolas) groups=1000(nicolas),27(sudo),998(docker),1001(dev)
$ groups
nicolas sudo docker dev
# Voir tous les groupes du systeme
cat /etc/group
# Creer un groupe
sudo groupadd devteam
# Ajouter un utilisateur a un groupe
sudo usermod -aG docker nicolas
# -a : append (ajouter, ne pas remplacer)
# -G : groupe supplementaire
# ATTENTION : sans -a, ca remplace TOUS les groupes
# Verifier
$ id nicolas
uid=1000(nicolas) gid=1000(nicolas) groups=1000(nicolas),27(sudo),998(docker)
# Retirer d'un groupe
sudo gpasswd -d nicolas docker
L'erreur classique : oublier le -a dans usermod -aG. Sans -a, ca remplace tous les groupes supplementaires par celui que tu specifies. Tu retires l'utilisateur de sudo, docker, et tout le reste. J'ai vu un admin se retirer ses propres droits sudo comme ca. La seule solution etait de rebooter en mode recovery.
Autre point : les changements de groupe ne prennent effet qu'a la prochaine connexion. Soit tu te deconnectes/reconnectes, soit tu utilises newgrp docker pour activer le groupe dans la session courante.
sudo : le pouvoir sans le risque
sudo exécuté une commande en tant que root (ou un autre utilisateur), ponctuellement :
bash# Executer une commande en root
sudo apt update
sudo systemctl restart nginx
# Executer en tant qu'un autre utilisateur
sudo -u postgres psql
# Ouvrir un shell root (a eviter)
sudo -i # Shell login root
sudo -s # Shell root (garde tes variables d'env)
su vs sudo : la différence qui compte
bash# su : Switch User (tu deviens l'autre utilisateur)
su - nicolas # Demande le mot de passe de nicolas
su - # Devenir root (demande le mot de passe root)
# sudo : Execute une commande avec les privileges root
sudo commande # Demande TON mot de passe
# La difference fondamentale :
# - su : il faut connaitre le mot de passe de l'utilisateur cible
# - sudo : il faut etre dans le groupe sudo et connaitre TON mot de passe
sudo est préférable a su pour trois raisons :
- Pas besoin de partager le mot de passe root
- Chaque commande sudo est loguee dans
/var/log/auth.log - Les privileges expirent apres quelques minutes
Le fichier sudoers
La configuration de sudo est dans /etc/sudoers. Tu ne dois JAMAIS éditer ce fichier directement. Utilise visudo qui vérifié la syntaxe avant de sauvegarder :
bash# Editer la config sudo (avec verification de syntaxe)
sudo visudo
# Contenu typique
root ALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL
# Le % signifie que c'est un groupe
# Ajouter un utilisateur qui peut tout faire sans mot de passe (deploiement CI/CD)
deployer ALL=(ALL) NOPASSWD: ALL
# Plus restrictif : seulement certaines commandes sans mot de passe
deployer ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/docker compose up -d
# Fichiers custom dans /etc/sudoers.d/ (plus propre)
sudo visudo -f /etc/sudoers.d/deployer
Qui est connecte ?
bash# Qui est connecte en ce moment
$ who
nicolas pts/0 2026-03-29 08:00 (192.168.1.10)
deploy pts/1 2026-03-29 09:30 (10.0.0.5)
# Plus de details
$ w
10:30:45 up 42 days, 3:15, 2 users, load average: 0.15, 0.10, 0.08
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
nicolas pts/0 192.168.1.10 08:00 1.00s 0.10s 0.01s w
deploy pts/1 10.0.0.5 09:30 30:00 0.05s 0.02s tail -f app.log
# Voir les dernieres connexions
last -10
# Voir les tentatives de connexion echouees
sudo lastb -10
Pourquoi ne pas bosser en root
Je l'ai dit en introduction, mais ca merite d'etre répété :
- Pas de filet de sécurité :
rm -rf /fonctionne sans broncher - Pas de trace : impossible de savoir qui a fait quoi si tout le monde est root
- Risque de sécurité : un processus lance en root qui est compromis donne acces a tout
- Mauvaises habitudes : tu ne te poses plus la question "ai-je besoin de ces droits ?"
Dans Docker, c'est pareil. Ajoute un USER dans ton Dockerfile :
dockerfileFROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci --production
# Ne PAS tourner en root
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
CMD ["node", "server.js"]
Les comptes de service
Les comptes de service sont des utilisateurs système créés pour faire tourner des applications. Ils n'ont pas de mot de passe et ne peuvent pas se connecter :
bash# Creer un compte de service
sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
# Donner la propriete des fichiers de l'app
sudo chown -R myapp:myapp /opt/myapp/
# Le service systemd tournera sous cet utilisateur
# [Service]
# User=myapp
# Group=myapp
C'est la bonne pratique : un service = un utilisateur dédié avec le minimum de permissions. Si l'application est compromise, l'attaquant n'a acces qu'aux fichiers de cette application, pas au système entier.
Pour des guides sur la securisation des comptes dans un environnement de déploiement, paltemps.fr propose des articles complémentaires.
Résumé
adduserpour créer un utilisateur facilement,useraddpour les scriptsusermod -aGpour ajouter a un groupe (ne jamais oublier le-a)sudoest préférable asu: traces, pas de partage de mot de passe- Ne jamais bosser en root, meme sur un serveur de dev
- Un service = un compte de service dédié avec
/usr/sbin/nologin
Precedent : Permissions | Suivant : Editeurs (nano, vim, sed, awk)