Control Root Console Logins with /etc/securetty

One wrong line in /etc/securetty can lock root out of every terminal on the box, so treat this file with the same care as sudoers. You will create or update it so root can log in only on the terminal names you choose, and leave yourself a tested way back in before you trust it. Allow about 15 minutes, plus a separate recovery window if this is a remote or production machine.

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

1. Check which login stack and file you have

Start without changing anything. The file may be absent, which is a real configuration state, not proof that every root login is allowed. On this host, /etc/securetty is absent; yours 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 binary reads the file. The securetty manual says some versions of login use it, and points shadow-suite users at login.defs(5). PAM systems use pam_securetty(8) instead, when that module is present in the service configuration.

2. Identify the terminal name you intend to permit

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

$ tty
/dev/pts/3

• Strip the /dev/ prefix. For this result, the securetty entry is pts/3, not /dev/pts/3.
• Consoles follow the same rule. A virtual console such as /dev/tty1 becomes tty1; a serial console such as /dev/ttyS0 becomes ttyS0.
• Use exact names only. Do not copy a placeholder into the real file, and do not assume a broad-looking name covers 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; skip 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, so 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, and the command replaces the file outright, 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 sed's own line-ending marker, not part of the configuration. Keep entries plain: one terminal name per line, without /dev/, leading whitespace or shell syntax.

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 does not prove enforcement for that service: it may use a different PAM file, a different authentication path, or rely on the particular login implementation instead. Read the relevant PAM configuration before changing it, and do not add a new PAM line as a quick fix; an ordering error can disrupt every login.

On PAM systems, the module has no effect on non-root users, and it needs the application to hand it 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 assume the file alone governs every kind of root authentication.

6. Test, then recover if necessary

Use a second session for the test and 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.