Quand on administre une machine Linux ou Unix, on croise vite le mot PAM sans toujours comprendre ce qu’il fait réellement. Pourtant, il est là dans des moments très concrets: une connexion SSH, un changement de mot de passe, une ouverture de session locale, parfois même un accès à sudo. PAM, pour Pluggable Authentication Modules, n’est pas un service de plus qu’on lance en arrière-plan. C’est plutôt une couche d’intermédiaire, un cadre commun qui permet aux applications de déléguer l’authentification, la gestion de compte ou des règles de session sans réinventer le sujet à chaque fois.
Dit autrement, PAM évite qu’OpenSSH, login, su, sudo ou un gestionnaire d’affichage aient chacun leur propre logique maison pour vérifier qui a le droit d’entrer. Ce principe paraît discret, mais il simplifie énormément l’administration d’un système et rend les politiques de sécurité plus cohérentes d’un service à l’autre.
Contenu
Pourquoi PAM existe-t-il au juste ?
# exemple courant: pile PAM pour sshd cat /etc/pam.d/sshd # tester un service lié à l'authentification sudo pam-auth-update
Avant PAM, chaque programme pouvait embarquer sa propre façon d’authentifier un utilisateur. C’était pénible à maintenir, difficile à harmoniser et source d’écarts de sécurité. Avec PAM, les développeurs d’applications n’ont plus besoin de coder eux-mêmes toutes les variantes possibles de l’authentification. Ils appellent une interface standard, puis le système décide quels modules appliquer.
C’est ce qui permet, par exemple, de demander un mot de passe classique sur une machine, d’imposer des règles supplémentaires sur une autre, ou encore d’intégrer une authentification centralisée via LDAP, Kerberos ou un second facteur, sans remplacer tous les services un par un. On adapte la politique, pas toute l’architecture.
Si vous vous intéressez plus largement aux mécanismes de sécurité sous Unix, vous pouvez aussi jeter un œil à cet article sur la gestion des accès et des droits, qui complète bien la logique de PAM dans un environnement multi-utilisateur.
Comment PAM s’insère-t-il entre les services et l’authentification ?
Le point clé, c’est que PAM se place entre l’application et la méthode d’authentification. Un service comme SSH ne va pas directement lire /etc/shadow et décider seul du résultat. Il appelle PAM. Ensuite, PAM consulte sa configuration et exécute les modules prévus pour ce service.
En pratique, la chaîne ressemble souvent à ceci: un utilisateur tente de se connecter, le service transmet la demande à PAM, PAM applique une pile de modules, puis renvoie une réponse au service. Cette réponse peut être “oui”, “non”, ou parfois “oui, mais avec des conditions” comme des restrictions horaires, un mot de passe expiré ou l’ouverture d’une session avec certains montages et variables d’environnement.
Les fichiers de configuration se trouvent généralement dans /etc/pam.d/. Chaque service y possède souvent son propre fichier, par exemple sshd, sudo ou login. On y voit des types comme auth, account, password et session. Ce découpage est très utile:
authvérifie l’identité de l’utilisateuraccountcontrôle si le compte est autorisé à accéder au servicepasswordgère le changement de mot de passesessionprépare et ferme le contexte de session
Ce fonctionnement modulaire explique pourquoi PAM est si présent dans l’écosystème Unix: il sert de point d’assemblage entre les services et les règles de sécurité réelles.
Quels sont les cas d’usage les plus courants ?
# extrait typique d'une règle PAM auth required pam_unix.so account required pam_unix.so session required pam_limits.so
Le cas le plus évident reste l’authentification par mot de passe local, mais PAM va beaucoup plus loin. Il peut refuser une connexion si le compte est verrouillé, limiter l’accès à certains groupes, empêcher un mot de passe trop faible, exécuter un montage automatique à l’ouverture de session ou afficher un message légal avant connexion.
Dans une entreprise, PAM est souvent impliqué lorsqu’on relie des machines Linux à un annuaire central. L’utilisateur garde une expérience relativement uniforme, tandis que l’équipe système applique une politique commune. Sur un poste autonome, PAM peut aussi servir à durcir sudo, imposer des règles de complexité de mot de passe ou journaliser plus finement certaines ouvertures de session.
Pour replacer cela dans l’administration quotidienne, on peut faire le lien avec cette ressource sur les bases de l’authentification sous Linux, utile pour comprendre où PAM intervient et où il laisse la main aux autres composants du système.
Quelles précautions prendre avant de modifier sa configuration PAM ?
C’est le point où il faut rester calme. PAM est puissant, mais une mauvaise ligne peut vous bloquer hors de la machine, surtout si vous modifiez l’authentification distante sur un serveur que vous administrez en SSH. Le vrai risque n’est pas seulement de casser une connexion, c’est de casser toutes les suivantes.
La première précaution consiste à garder une session root déjà ouverte avant tout changement. Ainsi, si la nouvelle configuration empêche les connexions normales, vous avez encore une porte de sortie. La deuxième est de sauvegarder les fichiers PAM concernés avant édition. La troisième, souvent négligée, est de tester petit à petit au lieu de réécrire tout un empilement de modules d’un coup.
Il vaut aussi mieux comprendre les indicateurs de contrôle comme required, requisite, sufficient et optional. Ils changent complètement le comportement de la pile. Un module correct au mauvais endroit, avec le mauvais drapeau, peut produire un résultat très différent de celui attendu.
Sur une machine sensible, le bon réflexe est simple: documenter chaque changement, tester depuis une seconde session, prévoir un retour arrière rapide et éviter les modifications “à chaud” sans filet. PAM n’est pas compliqué parce qu’il serait obscur par nature. Il devient délicat parce qu’il est placé exactement à l’endroit où une erreur coupe l’accès.
Une fois qu’on l’a compris comme une couche d’orchestration entre services, comptes et politiques de sécurité, PAM devient beaucoup moins intimidant. On voit mieux pourquoi il est partout, pourquoi il reste central sur les systèmes Unix modernes, et pourquoi les administrateurs le manipulent avec autant de respect.