This page goes over restricting root authentication with PAM.
The pam_securetty.so module allows the system administrator to restrict the TTYs that root is able to authenticate on. The module first checks if a plaintext file /etc/securetty exists and is not world writable. If the file exists and the tests pass, the contents will be used as a list of "secure" TTYs.
This module only affects root. If enabled, pam_securetty.so will always return
PAM_SUCCESS for authentication attempts by non-root users.
The format of /etc/securetty is one device name per line, without the /dev prefix. The following example states that /dev/tty1 and /dev/tty2, as well as the implicit kernel console device, are secure. Authentication attempts on any other TTYs will be rejected.
This file must must not be world writable.
/etc/pam.d/system-auth is used to configure the rules that PAM follows whenever system authentication needs to be done. This applies to physical logins as well as su and anything else which utilizes PAM's authentication capabilities. Taking a backup of the current PAM configuration will make it easy to revert changes if needed.
A broken PAM configuration can result in every user (including root) being locked out of the system. Leaving a spare root login session open (such as in a TTY) while editing the configuration files will save having to boot from a live USB or through single-user mode to fix PAM.
An example PAM configuration snippet which uses the pam_securetty.so module is:
auth required pam_securetty.so auth [success=1 default=ignore] pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail
The module also provides an option,
noconsole, which rejects authentication attempts on the kernel console unless that device is also specified in /etc/securetty.
Can't determine the TTY
If /var/log/auth.log contains an entry, such as the following, then PAM is unable to determine the TTY that an authenticating service is running on and will reject the authentication attempt:
Jan 1 00:00:01 hostname service: pam_securetty(service:auth): cannot determine user's tty Jan 1 00:00:01 hostname unix_chkpwd: password check failed for user (root) Jan 1 00:00:01 hostname service: pam_unix(service:auth): authentication failure; logname= uid= euid= tty= ruser= rhost= user=root
A likely cause is that service is either not setting the
PAM_TTY variable correctly or is otherwise unable to set it reliably. A workaround is to use the pam_succeed_if.so module to skip the pam_securetty.so checks for that service:
auth [success=1 default=ignore] pam_succeed_if.so quiet_fail service = service auth required pam_securetty.so auth [success=1 default=ignore] pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail
This negates the effects of pam_securetty.so. Only use if there isn't another option available and service is trusted. A better solution would be to see if service can be updated/improved to support
quiet_fail option means that pam_succeed_if.so will not log failed tests. Without it, every PAM authentication attempt not originating from service would contain a line stating the test failed. To not log successes or failures, use the
quiet option instead. These options help keep /var/log/auth.log a bit tidier.
Can't log in
If no user can log in, then the PAM configuration is likely broken. If there is still an active root login session available, then simply edit the current configuration or revert to the backup mentioned above. See here for instructions on how to fix it if no root login sessions are available (e.g. after a reboot).
- PAM — allows (third party) services to provide an authentication module for their service which can then be used on PAM enabled systems.
- YubiKey — how to setup a YubiKey for authenticating with PAM.
- Google Authenticator — describes an easy way to setup two-factor authentication on Gentoo.