Home / Alt manpages / securetty(5)

  • securetty(5)
  • File format
  • linux

Control Root Console Logins with /etc/securetty

You will create or update /etc/securetty so that root is allowed to log in only on the terminal names you choose. Each entry is a terminal name without the /dev/ prefix. Allow about 15 minutes, plus a separate recovery window if this is a remote or production machine.

This guide describes the installed Linux man-pages 6.7 documentation. The local manpages package is version 6.7-2. The file is only one part of the decision: an older or differently configured login stack may not consult it, and PAM services must actually include pam_securetty for that module to enforce its rule.

1. Check which login stack and file you have

Start without changing anything. The file may be absent, which is a real configuration state rather than proof that all root logins are allowed. On this host, /etc/securetty is absent. Your machine may differ.

$ command -v login
/usr/bin/login
$ if [ -e /etc/securetty ]; then
>     ls -l /etc/securetty
>     sed -n '1,120p' /etc/securetty
> else
>     echo '/etc/securetty is absent'
> fi
/etc/securetty is absent

The output from command -v confirms which login program you are about to investigate. It does not prove that this binary reads the file. The securetty manual says that some versions of login use it, and points shadow-suite users at login.defs(5). PAM systems use pam_securetty(8) when that module is present in the service configuration.

Checkpoint

Record whether the file exists, and keep an already-open root shell or console session available before making a change.

2. Identify the terminal name you intend to permit

Open the session that should remain usable and ask the shell for its terminal. This is an ordinary, unprivileged command.

$ tty
/dev/pts/3

For this result, the securetty entry would be pts/3, not /dev/pts/3. The same rule applies to a virtual console such as /dev/tty1: the entry is tty1. A serial console such as /dev/ttyS0 would be written as ttyS0.

Do not copy a placeholder into the real file. If you need several terminals, put one exact name on each line. Do not assume that a broad-looking name represents every related device; the file is a list of terminal names, not a pattern language.

3. Back up the existing policy

This step needs elevated privileges if the file exists. The backup gives you a direct undo path if a terminal is rejected. It is safe to omit the copy only when the file is genuinely absent.

$ if [ -e /etc/securetty ]; then
>     sudo cp -p /etc/securetty /etc/securetty.bak
>     sudo ls -l /etc/securetty /etc/securetty.bak
> else
>     echo 'No existing file to back up'
> fi
No existing file to back up

If the command prints a backup, do not overwrite or delete it until a separate login test has passed. The backup is sensitive configuration data: keep its ownership and permissions intact.

4. Install a minimal allow-list

Replace pts/3 with the terminal name from your own tty output. This example uses sudo because /etc/securetty is owned by root. The command replaces the file, so check the name before pressing Enter.

$ printf '%s\n' 'pts/3' | sudo tee /etc/securetty >/dev/null
$ sudo chown root:root /etc/securetty
$ sudo chmod 0644 /etc/securetty
$ sudo sed -n 'l' /etc/securetty
pts/3$

The sed -n 'l' check makes trailing spaces visible. The final $ shown above is the line ending marker printed by sed, not part of the configuration. Keep entries plain: one terminal name per line, without /dev/, leading whitespace or shell syntax.

Security warning

Do not close your known-good root session yet. A typo, an entry for the wrong terminal, or a service that reports a different terminal can prevent the next root login. This setting controls authentication policy; it is not a replacement for SSH key policy, sudo policy or a properly tested emergency console.

5. Check the permissions and active PAM configuration

The PAM module rejects a securetty file that is world-writable or not a normal file. Check the file as root, then inspect the PAM service that performs the login. The service name varies by distribution and by login method.

$ stat -c '%A %U:%G %n' /etc/securetty
-rw-r--r-- root:root /etc/securetty
$ sudo rg -n 'pam_securetty' /etc/pam.d /etc/pam.conf 2>/dev/null
/etc/pam.d/login:12:auth required pam_securetty.so

An empty search result means you have not proved enforcement for that service. It may use a different PAM file, use a different authentication path, or rely on the particular login implementation instead. Read the relevant PAM configuration before changing it. Do not add a new PAM line as a quick fix: an ordering error can disrupt all logins.

On PAM systems, the module has no effect on non-root users and requires the application to provide the terminal in the PAM item it checks. Its documented purpose is to allow root only on an acceptable device. The securetty manual also describes a PAM use related to empty passwords, so do not infer that the file alone governs every kind of root authentication.

6. Test, then recover if necessary

Use a second session for the test. Leave the first root shell untouched until you have confirmed the result. Test the exact login path you care about, such as the local console or the service that invokes login. A successful ordinary-user login does not test the root restriction.

If root is rejected from the intended terminal, return to the retained root session or an out-of-band console and restore the backup:

$ sudo cp -p /etc/securetty.bak /etc/securetty
$ sudo stat -c '%A %U:%G %n' /etc/securetty
-rw-r--r-- root:root /etc/securetty

If there was no previous file, remove the file only after confirming the local implementation's documented behaviour and your recovery access. Removing it changes policy and may not restore the same behaviour on a PAM system. Prefer restoring a known-good copy over improvising during a lockout.

Done means

  • You know whether /etc/securetty exists and which login path is relevant.
  • Every entry is an exact terminal name without the /dev/ prefix.
  • The file is owned by root, is not world-writable and contains one name per line.
  • You checked whether the relevant PAM service includes pam_securetty.
  • You tested the intended root login while a working recovery session remained open.
  • You kept a backup or documented the safe recovery path before closing the original session.