Effect of entries in /etc/securetty

security login pam

65,915

Solution 1

/etc/securetty is consulted by pam_securetty module to decide from which virtual terminals (tty*) root is allowed to login from.

In the past, /etc/securetty was consulted by programs like login directly, but now PAM handles that. So changes to /etc/securetty will affect anything using PAM with a configuration file that uses pam_securetty.so. So, only the login program is affected by default.

/etc/pam.d/login is used for local logins and /etc/pam.d/remote is used for remote logins (like telnet).

The primary entry types and their affects are as follows:

If /etc/securetty doesn't exist, root is allowed to login from any tty
If /etc/securetty exist and is empty, root access will be restricted to single user mode or programs that are not restricted by pam_securetty (i.e. su, sudo, ssh, scp, sftp)
If you are using devfs (a deprecated filesystem for handling /dev), adding entries of the form vc/[0-9]* will permit root login from the given virtual console number.
If you are using udev (for dynamic device management and replacement for devfs), adding entries of the form tty[0-9]* will permit root login from the given virtual console number.
Listing console in /etc/securetty normally has no effect since /dev/console points to the current console and is normally only used as the tty filename in single user mode, which is unaffected by /etc/securetty
Adding entries like pts/[0-9]* will allow programs that use pseudo-terminals (pty) and pam_securetty to login into root assuming the allocated pty is one of the ones listed; it's normally a good idea not to include these entries because it's a security risk; it would allow, for instance, someone to login into root via telnet, which sends passwords in plaintext (note that pts/[0-9]* is the format for udev which is used in RHEL 5.5; it will be different if using devfs or some other form of device management).

For single user mode, /etc/securetty is not consulted because the sulogin is used instead of login (see the sulogin man page for more info). Also you can change the login program used in /etc/inittab for each runlevel.

Note that to you should not use /etc/securetty to control root logins via ssh. To do that change the value of PermitRootLogin in /etc/ssh/sshd_config. By default /etc/pam.d/sshd is not configured to consult pam_securetty (and therefore /etc/securetty). You could add a line to do so, but ssh doesn't set the actual tty until sometime after the auth stage, so it doesn't work as expected. During the auth and account stages - at least for openssh - the tty (PAM_TTY) is hardcoded to ssh.

The above answer is based on RHEL 5.5. Much of it will pertain to current distributions of other *nix systems, but there are differences, some of which I noted, but not all.

I answered this myself because the other answers were incomplete and/or inaccurate. Many other forums, blogs, etc online have inaccurate and incomplete information in this topic as well, so I've done extensive research and testing to try to get the correct details. If anything I've said is wrong, please let me know though.

Sources:

Solution 2

vc/X and ttyX are synonyms: different paths to the same devices. The point of the redundancy is to catch various cases so as not to lock you out.

Traditionally, login (and possibly getty, I can't remember for sure) would check /etc/securetty and deny root logins on unlisted terminals. On modern systems, there are other ways to do this and other security measures too. Check out the contents of /etc/login.defs (which also covers securetty's functionality and is recommended by the securetty(5) manpage), and also /etc/pam.d/login, where you can control the behaviour of this feature.

Since securetty is only checked by login, means of logging in that don't use login (e.g. SSH with use_login=no, X display managers, etc) aren't affected.

65,915

deuberger

Updated on September 18, 2022

Comments

deuberger over 1 year
By default on RHEL 5.5 I have
```
[deuberger@saleen trunk]$ sudo cat /etc/securetty 
console
vc/1
vc/2
vc/3
vc/4
vc/5
vc/6
vc/7
vc/8
vc/9
vc/10
vc/11
tty1
tty2
tty3
tty4
tty5
tty6
tty7
tty8
tty9
tty10
tty11
```
What is the difference between each of the entry types (console, vc/*, and tty*)? Specifically, what is the end result of adding and removing each entry type?

My understanding is that they affect how and when you can login, but are there any other effects? And when can you and when can you not login depending on which entries are there?

EDIT 1

What I do know is that tty1-6 correspond to whether you can login from the first 6 consoles that you reach using Ctrl-Alt-F1 through Ctrl-Alt-F6. I always thought those were virtual consoles, so I'm a bit confused. And what does console correspond to?

Thanks.

EDIT 2

What is the effect, if any, in single user mode?
harperville about 8 years

+1 for taking the time to respond in such depth. I'm not sure why there is no accepted answer here. Seems like you've answered the OP's question. I do like @Alexios comment, "vc/X and ttyX are synonym[ous]..."
phk over 7 years

It's worth noting that on busybox-based systems it might still be of use for the simple fact that its login has no /etc/login.defs support.