Utilisateurs Linux : les commandes utiles pour lister les comptes et repérer les accès

Quand vous reprenez un serveur Linux, la première question n’est pas toujours “qui est connecté maintenant ?”. La vraie question, c’est souvent : quels comptes existent encore, lesquels peuvent ouvrir une session, et lesquels disposent de droits sensibles.

Dans ce guide, on va lister les utilisateurs proprement, sans paniquer devant /etc/passwd, puis repérer les comptes à contrôler en priorité. Je vous le dis tout de suite : ne supprimez rien uniquement parce qu’un nom vous semble bizarre. Sous Linux, beaucoup de comptes sont là pour les services.

Lire /etc/passwd sans confondre compte système et utilisateur humain

Le fichier /etc/passwd liste les comptes connus localement. Il ne contient pas les mots de passe en clair, mais il donne des informations utiles : nom du compte, UID, GID, dossier personnel et shell.

cat /etc/passwd

Une ligne ressemble à ceci :

nathan:x:1000:1000:Nathan Martin:/home/nathan:/bin/bash

Les champs sont séparés par des deux-points. Pour une première lecture, concentrez-vous sur le nom, l’UID, le dossier personnel et le shell :

cut -d: -f1,3,6,7 /etc/passwd

Sur beaucoup de distributions, les comptes utilisateurs commencent autour de l’UID 1000. Les comptes système ont souvent un UID plus bas, ou un shell comme /usr/sbin/nologin ou /bin/false. Ce n’est pas une règle universelle, mais c’est un bon premier filtre.

awk -F: '$3 >= 1000 && $3 < 60000 {print $1, $3, $6, $7}' /etc/passwd

La page de manuel de passwd(5) détaille le format exact du fichier. Gardez-la sous la main si vous devez auditer un vieux serveur ou une distribution un peu particulière.

Préférez getent quand les comptes ne sont pas seulement locaux

Sur un poste simple, /etc/passwd suffit souvent. Sur un serveur intégré à LDAP, Active Directory, SSSD ou un autre annuaire, il peut être incomplet. Dans ce cas, utilisez getent, qui interroge les bases configurées par le système.

getent passwd

Pour vérifier un compte précis :

getent passwd nathan

Et pour sortir une liste plus lisible des comptes avec UID utilisateur :

getent passwd | awk -F: '$3 >= 1000 && $3 < 60000 {print $1, $3, $6, $7}'

Je préfère cette méthode sur les machines d’entreprise, parce qu’elle évite de croire qu’un compte n’existe pas juste parce qu’il n’est pas écrit dans le fichier local. La commande est documentée dans getent(1).

Vérifier les groupes et les droits sensibles

Lister les comptes, c’est bien. Savoir lesquels peuvent faire des dégâts, c’est mieux. Commencez par un utilisateur précis avec id :

id nathan
groups nathan

Vous verrez l’UID, le groupe principal et les groupes secondaires. Les groupes à regarder de près dépendent de la distribution, mais sudo, wheel, adm, docker ou certains groupes applicatifs peuvent donner beaucoup plus qu’un simple accès utilisateur.

getent group sudo
getent group wheel
getent group docker
getent group adm

Si un compte apparaît dans sudo ou wheel, vérifiez aussi la configuration sudoers. Un vieux compte oublié avec un accès admin, c’est exactement le genre de détail qui revient vous mordre plus tard. Sur ce point, notre guide pour maîtriser sudo sous Linux complète bien cette première vérification.

Les commandes id(1) et groups(1) restent simples, mais elles donnent rapidement une idée du périmètre réel d’un compte.

Repérer les comptes qui peuvent ouvrir une session

Tous les comptes listés ne sont pas faits pour se connecter. Pour isoler ceux qui ont un shell interactif courant, vous pouvez filtrer les shells :

getent passwd | grep -E '/bin/(bash|sh|zsh|fish)$'

Ce filtre n’est pas parfait, mais il donne une première liste à relire. Vérifiez ensuite si les comptes disposent d’un dossier personnel :

getent passwd | awk -F: '$6 ~ /^\/home/ {print $1, $6, $7}'
ls -1 /home

Si vous auditez un serveur exposé en SSH, regardez aussi les clés présentes dans les dossiers utilisateur :

sudo find /home -maxdepth 3 -path '*/.ssh/authorized_keys' -type f -ls

Une clé SSH dans le mauvais compte peut suffire à maintenir un accès. Si vous devez remettre l’authentification au propre, relisez aussi notre article sur la génération d’une clé SSH sur Ubuntu.

Contrôler les dernières connexions sans tirer de conclusion trop vite

Pour voir qui est connecté maintenant :

who
w

Pour l’historique récent :

last -a | head
sudo lastlog | head -30

lastlog peut indiquer qu’un compte ne s’est jamais connecté, mais cela ne suffit pas à prouver qu’il est inutile. Un compte peut servir à un service, à une tâche planifiée, à une application, ou avoir été créé pour une procédure de secours. Utilisez ces commandes comme des signaux, pas comme une décision automatique. La page lastlog(8) précise les options disponibles.

Si vous cherchez une anomalie après une connexion suspecte, complétez avec les journaux système :

sudo journalctl -u ssh -b
sudo journalctl -p warning..alert -b

Notre guide sur journalctl et les logs du dernier démarrage peut aider à cadrer cette partie sans fouiller au hasard.

La petite checklist que j’utiliserais avant de nettoyer

• Slug exact du compte : notez le nom, l’UID, le dossier personnel et le shell.
• Groupes sensibles : contrôlez sudo, wheel, docker, adm et les groupes applicatifs.
• Accès SSH : cherchez les fichiers authorized_keys et gardez une copie avant modification.
• Dernière activité : croisez last, lastlog et les journaux, sans supprimer sur un seul indice.
• Service associé : vérifiez si le compte appartient à un service ou une application avant de le désactiver.

Si un compte vous semble vraiment inutile, commencez par le verrouiller ou désactiver sa connexion, pas par supprimer son dossier. Sur un serveur, je préfère toujours garder une trace, tester les services, puis seulement nettoyer. C’est moins spectaculaire, mais ça évite de casser une application parce qu’un compte “inconnu” était en fait utilisé tous les jours.

sudo passwd -l ancien_compte
sudo systemctl --failed
sudo journalctl -p warning..alert -b

Après ce contrôle, vous aurez une vue beaucoup plus claire : comptes humains, comptes système, droits admin, accès SSH et activité récente. Pour relier cette vérification aux services actifs, vous pouvez ensuite passer par la liste des services systemctl et regarder ce qui tourne vraiment sur la machine.

sudo apt update && sudo apt upgrade