The module path does not need to be specified explicitly, as long as the module is lo-cated in the default directory /lib/security (for all 64-bit platforms supported bySUSE® Linux Enterprise Server, the directory is /lib64/security). The fourthcolumn may contain an option for the given module, such as debug (enables debugging)or nullok (allows the use of empty passwords).NOTE: 64-Bit and 32-Bit Mixed InstallationsWhen using a 64-Bit operating system, it is possible to also include a runtimeenvironment for 32-Bit applications. In this case, make sure that you installboth versions of the respective pam modules when installing new modules.2.2 The PAM Configuration of sshdTo show how the theory behind PAM works, consider the PAM configuration of sshdas a practical example:Example 2.1 PAM Configuration for sshd#%PAM-1.0auth required pam_nologin.soauth include common-authaccount include common-accountpassword include common-passwordsession required pam_loginuid.sosession include common-session# Enable the following line to get resmgr support for# ssh sessions (see /usr/share/doc/packages/resmgr/README)#session optional pam_resmgr.so fake_ttynameThe first module that is called is pam_nologin. It checks whether the file /etc/nologin exists. If it does, no other user than root may log in.The typical PAM configuration of an application (sshd, in this case) contains four includestatements referring to the configuration files of four module types: common-auth,common-account, common-password, and common-session. These fourfiles hold the default configuration for each module type. By including them instead ofadding each module separately to the respective PAM configuration, you automaticallyget an updated PAM configuration if the administrator changes the defaults. In formertimes, you had to adjust all configuration files manually for all applications whenchanges to PAM occurred or a new application was installed. Now the PAM configura-20 Security Guide
