PAM securetty

From Gentoo Wiki
Jump to:navigation Jump to:search

This page goes over restricting root authentication with PAM.

The 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, 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.

FILE /etc/securetty
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 module is:

FILE /etc/pam.d/system-auth
auth    required          
auth    [success=1 default=ignore]         nullok try_first_pass
auth    [default=die]          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:

FILE /var/log/auth.log
Jan  1 00:00:01 hostname service: pam_securetty(service:auth): cannot determine user's tty
Jan  1 00:00:01 hostname unix_chkpwd[11111]: 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 module to skip the checks for that service:

FILE /etc/pam.d/system-auth
auth    [success=1 default=ignore]   quiet_fail service = service
auth    required          
auth    [success=1 default=ignore]         nullok try_first_pass
auth    [default=die]          authfail
This negates the effects of 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 PAM_TTY.

The quiet_fail option means that 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).

See also

  • PAM — allows (third party) services to provide an authentication module for their service which can then be used on PAM enabled systems.
  • YubiKey — a hardware security device that can be used to safely store cryptographic keys, OTP tokens, and challenge response seeds
  • Google Authenticator — describes an easy way to setup two-factor authentication on Gentoo.
  • OATH-Toolkit — toolkit for (OTP) One-Time Password authentication using HOTP/TOTP algorithms.

External resources