Très souvent sur GNU/Linux, il est nécessaire de connaître à quelle personne le compte est associé, quel est le profil de cette personne, de quel(s) droit(s) le compte en question dispose-t-il. Je vous propose ici de détailler l’ensemble des moyens permettant d’identifier l’ensemble de ces informations. Au cours de ce tutoriel, nous verrons les techniques suivantes permettant de :

• Lister les comptes
• Lister les caractéristiques d’un compte en particulier
• Vérifier les délégations d’un compte en particulier
• Lister les autorisations d’accès SSH de ce même compte

II. Les bases internes de comptes

Le système GNU/Linux possède un certain nombre de bases internes de référence, permettant de connaître à la fois les comptes utilisateurs, les groupes associés ainsi que leurs droits respectifs. Ces bases peuvent être facilement interrogées grâce à la commande getent.

Cette dernière permet de rechercher au sein de la base de référence correspondante : /etc/passwd, /etc/group ou /etc/shadow les caractéristique d’un ou plusieurs comptes.

a) Liste des utilisateurs : /etc/passwd

liste des champs du fichier /etc/passwd :

• identifiant (ou login), par exemple ipaiair2
• password: le mot de passe est chiffré par une une fonction à sens unique (crypt), s’appuyant sur les algorithmes de chiffrage DES, MD5, SHA-256 or SHA-512. La valeur spéciale “x” indique que le mot de passe chiffré est stocké dans le fichier /etc/shadow
• uid : numéro unique identifiant l’utilisateur
• gid : numéro unique du groupe principal de l’utilisateur (Debian crée par défaut un groupe spécifique à chacun)
• GECOS : champ de renseignements qui contient habituellement le nom complet de l’utilisateur
• répertoire de connexion, attribué à l’utilisateur pour qu’il y stocke ses fichiers personnels (la variable d’environnement $HOME y pointe habituellement)
• programme à exécuter après la connexion. Il s’agit généralement d’un interpréteur de commandes (shell), donnant libre cours à l’utilisateur. Si l’on précise /bin/false (programme qui ne fait rien et rend la main immédiatement), l’utilisateur ne pourra pas se connecter.

b) Le fichier des mots de passe chiffrés et cachés : /etc/shadow

Le fichier /etc/shadow contient les champs suivants :

• dentifiant (ou login)
• mot de passe chiffré
• plusieurs champs de gestion de l’expiration du mot de passe

ATTENTION : l’interrogation de la base /etc/shadow ne peut fonctionner que depuis le compte root. Il est notamment possible de consulter les comptes dont le mot de passe n’a pas été défini. Il s’agit des enregistrements s’affichant avec le caractère ‘ !’ au niveau du champ du mot de passe.

Par exemple, l’interrogation du fichier /etc/passwd fournit la liste des enregistrements de ce fichier (et donc, des comptes existants sur le système), sous la forme suivante :

ipadair2@vmi000000:~$ sudo cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:101:101:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
systemd-network:x:102:103:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:104:110::/nonexistent:/usr/sbin/nologin
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
remi:x:1000:1000:,,,:/home/remi:/bin/bash
mysql:x:106:113:MySQL Server,,,:/nonexistent:/bin/false
Debian-exim:x:107:114::/var/spool/exim4:/usr/sbin/nologin
postfix:x:108:115::/var/spool/postfix:/usr/sbin/nologin
ipadair2:x:1001:1001:,,,:/home/ipadair2:/bin/bash

Bien évidemment, il est à tout à fait possible de faire afficher uniquement les caractéristiques d’un compte ou d’un utilisateur en particulier :

SÉCURITÉ Sûreté du fichier /etc/shadow /etc/shadow, contrairement à son alter ego /etc/passwd, est inaccessible en lecture aux utilisateurs. Tout mot de passe haché stocké dans /etc/passwd est lisible par tous ; un indélicat peut alors entreprendre de le « casser » par une méthode de force brute, consistant simplement à chiffrer successivement tous les mots de passe simples pour tenter de le découvrir. Cette attaque, dite « du dictionnaire », qui dévoile les mots de passe mal choisis, n’est plus possible avec le fichier /etc/shadow.

c) Modifier un compte ou mot de passe existant

Les commandes suivantes permettent de modifier les informations stockées dans des champs spécifiques des bases de données utilisateur :

• passwd permet à un utilisateur régulier de changer son mot de passe, ce qui à son tour met à jour le fichier /etc/shadow (chpasswd permet aux administrateurs de mettre à jour les mots de passe pour une liste d’utilisateurs en mode batch)
• chfn (CHange Full Name), réservé au super-utilisateur (root), modifie le champ GECOS. chsh (CHange SHell) permet à l’utilisateur de changer son shell de connexion ; cependant, les choix disponibles seront limités à ceux listés dans /etc/shells ; l’administrateur, d’autre part, n’est pas lié par cette restriction et peut paramétrer le shell à n’importe quel programme de son programme en choisissant.
• Enfin, la commande change (CHange AGE) confirme à l’administrateur la possibilité de modifier les conditions d’expiration du mot de passe (l’option -l utilisateur listant la configuration actuelle). On pourra d’ailleurs forcer l’expiration d’un mot de passe grâce à la commande passwd -e utilisateur, qui obligera l’utilisateur à changer son mot de passe à la prochaine connexion.

En plus de ces outils, la commande usermod permet de modifier tous les détails mentionnés ci-dessus.

On peut facilement modifier ces propriétés grâce à la commande usermod et les options associées à cette commande :

Options	Observations
-g	pour changer le groupe primaire
-G	pour ajouter des groupes secondaires
-c	pour modifier le commentaire associé au compte
-s	pour modifier le type de Shell utilisé
-u	pour modifier le n° de compte

RAPPEL : le champ /bin/bash correspond au type de Shell utilisé. Celui-ci doit être défini dans le fichier /etc/shells pour pouvoir être mentionné au sein du fichier /etc/passwd. Le séparateur de champ au sein des fichiers de comptes est le caractère ‘ :’ et le second champ correspond au champ du mot de passe. Le ‘x’ signifie que celui-ci est chiffré et stocké dans le fichier /etc/shadow.

c) Bloquer un compte

Vous pourriez avoir besoin de « désactiver un compte » (verrouiller un utilisateur), à titre de mesure disciplinaire, aux fins d’une enquête, ou simplement en cas d’absence prolongée ou définitive d’un utilisateur. Un compte désactivé signifie que l’utilisateur ne peut pas se connecter ou accéder à la machine. Le compte reste intact sur la machine et aucun fichier ou donnée n’est supprimé ; il est tout simplement inaccessible. Pour ce faire, utilisez la commande passwd -l user (lock). La réactivation du compte s’effectue de la même manière, avec l’option -u (déverrouiller). Ceci, cependant, empêche seulement les connexions basées sur un mot de passe par l’utilisateur. L’utilisateur peut toujours accéder au système à l’aide d’une clé SSH (si elle est configurée). Pour empêcher même cette possibilité, vous devez faire expirer le compte aussi bien en utilisant change -E 1user ou usermod -e 1 user (donner une valeur de -1 dans l’une de ces commandes réinitialisera la date d’expiration à jamais). Pour désactiver (temporairement) tous les comptes d’utilisateurs, il suffit de créer le fichier /etc/nologin.

Vous pouvez désactiver un compte d’utilisateur non seulement en le verrouillant comme décrit ci-dessus, mais aussi en changeant son shell de connexion par défaut (chsh -s shell user). Lorsque ce dernier est remplacé par /usr/sbin/nologin, un utilisateur reçoit un message poli l’informant qu’une connexion n’est pas possible, alors que /bin/false se ferme tout simplement en retournant false. Il n’y a pas de commutateur pour restaurer le shell précédent. Vous devez obtenir et conserver ces informations avant de modifier le paramètre. Ces interpréteurs de commandes sont souvent utilisés pour les utilisateurs du système qui ne nécessitent aucune disponibilité de connexion.

d) Liste des groupes : /etc/group

La liste des groupes est stockée dans le fichier /etc/group, simple base de données textuelle au format comparable à celui de /etc/passwd, qui utilise les champs suivants :

Options	Observations
identifiant	nom du groupe
password	il ne sert qu’à intégrer un groupe dont on n’est pas habituellement membre (avec la commande newgrp ou sg – voir encadré (travailler avec plusieurs groupes)
gid	numéro unique identifiant le groupe
liste des membres	liste des identifiants d’utilisateurs membres du groupe, séparés par des virgules

Chaque utilisateur peut donc faire partie de plusieurs groupes ; l’un d’entre eux est son « groupe principal » ; le groupe principal par défaut est mis en place lors de la connexion. Par défaut, chaque fichier qu’il crée lui appartient, ainsi qu’au groupe principal. Cela n’est pas toujours souhaitable : c’est par exemple le cas lors d’un travail dans un répertoire partagé grâce à un groupe différent de son groupe principal. Dans ce cas, l’utilisateur a intérêt à changer temporairement de groupe principal grâce aux commandes newgrp — qui démarre un nouveau shell — ou sg — qui se contente d’exécuter une commande. Ces commandes permettent aussi de rejoindre un groupe dont on ne fait pas partie si le groupe est protégé par un mot de passe connu.
Une alternative consiste à positionner le bit setgid sur le répertoire, ce qui permet aux fichiers créés dans ce répertoire d’appartenir automatiquement au bon groupe. On se référera pour les détails à l’encadré SÉCURITÉ Répertoire setgid et sticky bit.
La commande id permet de vérifier à tout instant son identifiant personnel (variable uid), le groupe principal actuel (variable gid) et la liste des groupes dont on fait partie (variable groupes).

Les commandes addgroup et delgroup permettent respectivement de créer et de supprimer un groupe. La commande groupmod modifie les informations d’un groupe (son gid ou son identifiant). La commande gpasswd <em>groupe</em> modifiera le mot de passe d’un groupe, tandis que la commande gpasswd -r <em>groupe</em> le supprimera.

III. Lister les caractéristiques d’un compte particulier

Maintenant que l’on sait interroger les bases de comptes internes, on peut également chercher à préciser les caractéristiques d’un compte en particulier. Pour se faire, on utilisera alors l’instruction id. Sans aucune option, cette commande permet de lister l’ensemble des caractéristiques d’un compte, de son uid, de son gid ainsi que de ses groupes primaires et secondaires. Cela revient à interroger la base de comptes internes /etc/passwd avec la commande getent précédente, mais avec une présentation différente :

$ id phil

uid=1000 (phil) gid=1000 (phil) groupes=1000 (phil), 120 (users)

Cet ensemble d’informations vient conforter celles que l’on a pu visualiser précédemment en interrogeant la ou les bases de comptes NSS, au travers des fichiers /etc/passwd, /etc/group ou /etc/shadow.RAPPEL : on peut également vérifier la cohérence des déclarations de comptes du fichier /etc/passwd en exécutant la commande pwck.

IMAGE IMAGE IMAGE IMAGE IMAGE IMAGE IMAGE IMAGE IMAGE IMAGE IMAGE IMAGE

IV. Vérifier les délégations d’un compte

Sur des systèmes un tant soit peu protégé, en général, le compte root est désactivé (à l’instar des distributions Debian et Ubuntu like) et on utilise alors les comptes utilisateurs avec des délégations d’accès, aussi appelées sudoers. Le fichier de configuration s’édite grâce à la commande visudo.

Dès lors qu’un utilisateur possède une ou plusieurs délégations d’accès à des commandes privilégiées, on peut bien sûr éditer le fichier de règles (via la commande visudo) ou simplement se connecter sous le compte utilisateur en question et exécuter la commande suivante :

$ sudo -l

Entrées par défaut pour phil sur mysrv01 :

  Insults

L’utilisateur phil peut utiliser les commandes suivantes sur mysrv01 :

(root) NOPASSWD : /usr/bin/tee -a /etc/hosts, /usr/local/scripts/manage_dsh.sh,/usr/bin/vi -Z /etc/dhcp/dhcpd.conf

(ALL) NOPASSWD: ALL

Bien évidemment, on constate ici que l’utilisateur phil peut se connecter sans saisie de mot de passe (règle (ALL) NOPASSWD : ALL). Mais, la plupart du temps, si l’on souhaite sécuriser son système, il est fortement conseillé de forcer la saisie du mot de passe de l’utilisateur.

V. Lister les autorisations d’accès SSH

Enfin, on peut aussi interroger les différents accès autorisés sur des serveurs distants pour le compte de l’utilisateur concerné, au travers du protocole SSH. Pour se faire, on doit se placer sur le répertoire $HOME/.ssh du compte de l’utilisateur, et exécuter l’instruction suivante :

$ ssh-keygen -lf authorized_keys

En tout état de cause, cela devrait nous retourner l’ensemble des clés publiques (placées dans le fichier $HOME/.ssh/authorized_keys), pour lesquelles l’accès distant du compte en question est autorisé à se connecter aux serveurs associés à la clé publique mentionnée sous la forme ci-dessous :

$ ssh-keygen -lf authorized_keys

2048 SHA256: BHylkdmlskdfYK4987JF+MPdfj476… no comment (RSA)

2048 SHA256: VYh4876+XcrZ098Nn0746+peszXX… no comment (RSA)

…

En résumé, pour autoriser un compte à accéder en SSH à une machine particulière, il suffit de créer ce compte sur cette même machine et d’y placer la clé publique (récupérée lors d’une création via ssh-keygen d’une paire de clés {privée, publique}, ou via la copie de sa clé publique à l’aide de la commande ssh-copy-id), dans le fichier authorized_keys du compte à accréditer.

VI. Conclusion

Ces techniques que nous venons de lister ne sont bien sûr pas exhaustives et peuvent être complétées par de nombreuses autres méthodes d’interrogation de comptes et de leurs propriétés. Mais, cela a le mérite de permettre de récupérer les principales fonctions et autorisations d’un compte utilisateur sans trop d’effort ni de commandes compliquées.