Après la théorie de la configuration PAM, vous trouverez ici un exemple pratique, la configuration PAM de sshd :

#%PAM-1.0
auth     include        common-auth
auth     required       pam_nologin.so
account  include        common-account
password include        common-password
session  include        common-session
# Enable the following line to get resmgr support for
# ssh sessions (see /usr/share/doc/packages/resmgr/README.SuSE)
#session  optional      pam_resmgr.so fake_ttyname

La configuration PAM typique d'une application (sshd dans le cas présent) contient quatre déclarations qui font référence aux fichiers de configuration de quatre types de modules : common-auth, common-account, common-password, et common-session. Ces quatre fichiers contiennent la configuration par défaut de chaque type de module. En les incluant plutôt qu'en faisant appel à chaque module séparément pour chaque application PAM, vous obtenez automatiquement une configuration PAM mise à jout si l'administrateur change les paramètres par défaut. Par le passé, vous deviez ajuster tous les fichiers de configuration manuellement pour toutes les applications lorsque des modifications étaient apportées à PAM ou quand une nouvelle application était installée. La configuration PAM et toutes les modifications qui lui sont apportées sont transmis à travers les fichiers de configuration par défaut.

Le premier fichier inclus (common-auth) appelle deux modules du type auth : pam_env et pam_unix2. Voir Exemple 21.2, « Configuration par défaut de la section auth ».

auth    required        pam_env.so
auth    required        pam_unix2.so

Le premier module, pam_env, charge le fichier /ect/security/pam_env.conf pour définir les variables d'environnement telles qu'elles sont spécifiées dans le fichier. Ceci peut être utilisé pour configurer la variable DISPLAY à la bonne valeur, car le module pam_env sait d'où l'utilisateur tente de se connecter. Le second module, pam_unix2, vérifie le login (nom) et le mot de passe de l'utilisateur à l'aide de /etc/passwd et de /etc/shadow.

Une fois que les modules spécifiés dans common-auth ont été appelés avec succès, un troisième module appelé pam_nologin vérifie si le fichier /etc/nologin existe. Dans ce cas, à part root, aucun utilisateur n'a permission d'accès. La « pile » (en anglais stack) complète des modules auth est traitée avant que le démon ssh obtienne une réponse quant à la réussite de l'authentification. Tous les modules portent donc un indicateur de contrôle required et doivent donc être tous traités avant que la réussite soit communiquée à sshd. En cas d'échec d'un de ces modules, le résultat final communiqué sera négatif, mais sshd ne l'apprendra que lorsque tous la pile de modules aura été traitée.

Dès que les modules spécifiés dans auth ont été traités avec succès, une autre déclaration incluse est traitée ; dans le cas présent, celui dans Exemple 21.3, « Configuration par défaut de la section account ». common-account ne contient qu'un module, pam_unix2. Si pam_unix2 informe que l'utilisateur existe, sshd reçoit un message annonçant ce succès et la pile de modules suivante (password) est traitée comme décrit dans Exemple 21.4, « Configuration par défaut de la section password ».

account required        pam_unix2.so

password required       pam_pwcheck.so  nullok
password required       pam_unix2.so    nullok use_first_pass use_authtok
#password required      pam_make.so     /var/yp

Encore une fois, la configuration PAM de sshd n'implique qu'une déclaration faisant référence à la configuration par défaut pour des modules password situés dans common-password. Ces modules doivent être traités avec succès (indicateur de contrôle required) lorsque l'application change les données d'authentification. La modification d'un mot de passe ou d'une autre donnée d'authentification requiert la vérification de la sécurité ce qui est réalisé à l'aide du module PAM pam_pwcheck. Le module pam_unix2, utilisé par la suite, prend les anciens et nouveaux mots de passe de pam_pwcheck. L'utilisateur ne doit donc pas s'identifier à nouveau. De plus, on évite de passer outre les contrôles de pam_pwcheck. Les modules de type password devraient toujours être exécutés dans la mesure où les modules précédents de type account ou auth avertissent d'un mot de passe périmé.

session required        pam_limits.so
session required        pam_unix2.so

Enfin, les modules de type session, rassemblés dans le fichier common-session, sont appelés de manière à configurer la session pour cet utilisateur de la façon prévue. Le module pam_unix2 est appelé à nouveau, sans effet en pratique en raison de l'option none spécifiée dans le fichier de configuration respectif de ce module, pam_unix2.conf. Le module pam_limits charge le fichier /etc/security/limits.conf qui définit les limites d'utilisation de certaines ressources systèmes. Lorsque l'utilisateur se déconnecte, les modules de type session sont à nouveau appelés.