Dopo una introduzione teoretica ecco un esempio pratico riferito alla configurazione PAM di sshd:
Example 21.1. Configurazione PAM per sshd
#%PAM-1.0 auth required pam_unix2.so # set_secrpc auth required pam_nologin.so auth required pam_env.so account required pam_unix2.so account required pam_nologin.so password required pam_pwcheck.so password required pam_unix2.so use_first_pass use_authtok session required pam_unix2.so none # trace or debug session required pam_limits.so # 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
Innanzitutto sshd invoca i tre moduli del tipo auth. Il primo modulo, pam_unix2 verifica login e password dell'utente in base a /etc/passwd e /etc/shadow. Il prossimo modulo (pam_nologin) verifica se vi è il file /etc/nologin. In caso affermativo nessun utente fatta eccezione per root vi ha accesso. Il terzo modulo pam_env legge il file /etc/security/pam_env.conf ed imposta le variabili di ambienti qui stabilite. Qui ad esempio potete impostare il valore corretto per la variabile DISPLAY, visto che pam_env contiene delle informazioni riguardanti la postazione dalla quale un utente tenta di eseguire il login. La “pila” (ingl. stack) dei moduli auth viene elaborata prima che il demone ssh riceva una risposta riguardante il risultato del tentativo di login (riuscito o meno). Tutti i moduli presentano qui il flag di controllo required e devono essere stati elaborati in modo corretto prima che sshd riceva il messaggio di riuscita. Se un modulo non viene elaborato correttamente si ha un esito negativo, ciò viene comunicato a sshd solo dopo che tutti i moduli di questo tipo sono stati elaborati.
Nella prossima pila di modulo vengono elaborati tutti i moduli del tipo account, i quali verificano che l'utente in questione abbia il permesso di eseguire il servizio richiesto. A tal dovranno essere elaborati correttamente i moduli pam_unix2 e pam_nologin (required). Se pam_unix2 conferma l'esistenza dell'utente in questione e pam_nologin verifica che l'utente non è escluso dal login, l'esito positivo viene comunicato a sshd e proseguito con l'elaborazione del prossimo gruppo di moduli.
Entrambi i moduli che seguono appartengono al tipo password e devono essere elaborati correttamente (flag di controllo: required), se l'applicazione modifica il cosiddetto token di autenticazione. Quando si intende modificare una password o altro token di autenticazione viene eseguita una verifica della sicurezza. Il modulo PAM pam_pwcheck assicura che la libreria CrackLib verifica il livello di sicurezza della password, ed eventualmente l'utente viene avvisato se la password è poco sicura, ovvero troppo breve o troppo semplice. Il già menzionato modulo pam_unix2 assume le vecchie e nuove password da pam_pwcheck. Così l'utente non dovrà autenticarsi nuovamente. Inoltre in tal modo si evita che si aggirino le verifiche di pam_pwcheck. I moduli del tipo password vanno invocati se i moduli preposti a account o auth segnalano una password scaduta.
Infine vengono inizializzati i moduli di tipo session per configurare la sessione dell'utente in base alle impostazioni previste. Il modulo pam_unix2 viene invocato nuovamente ma a causa dell'opzione none questa chiamata non produce alcun effetto. Il modulo pam_limits legge il file /etc/security/limits.conf in cui possono essere stabiliti dei limiti riguardanti l'utilizzo delle risorse di sistema. Quando l'utente esegue il logout vengono invocate nuovamente i moduli session.