Red Hat Bugzilla – Bug 8641
/etc/securetty don't understand pts/0
Last modified: 2008-05-01 11:37:53 EDT
in /etc/securetty to allow networked
root logins... but i am still unable to
login as root.
If you want to allow networked root logins (and massive security holes to go
with it), just delete /etc/securetty and that will happen. Remember that when
you're using telnet, the password you type is visible to anybody who runs a
packet sniffer, and a hacker seeing your root password broadcast like that will
assume that Christmas has come early.
A better choice is to use ssh to log in. It encrypts the password, as well as
everything else sent, so they can't be sniffed, and it allows network root login
I received a personal email from the reporter stating that (s)he wanted to be
able to log in across the network directly as root, and thought that the pts/X
notation should be allowed. I'm following up here for general comment, and would
like to make the following points:
1. Let's say that "pts/0" was allowed, and was dropped in /etc/securetty
to enable logins on that port. Ask yourself what this actually means.
As I understand it, it basically says that the person who happens to
be allocated "pts/0" for their telnet connection would be allowed to
log in as root, but other users would not be allowed to.
If so, then that means that the hacker who telnet'd in to your system
two minutes ago can get in, as they were allocated "pts/0", but you,
the rightful owner, can not.
Alternatively, it means that you will still not be able to get in,
except on the random occasions where you happen to get allocated to
"pts/0" when you telnet in.
2. If your intention is to be able to telnet in from anywhere on the
Internet, remember that anybody running a packet sniffer (and even
the lowly `tcpdump` command qualifies) would be able to read your
username and password in plain text, and would thus have unhindered
access to your system.
Given these two points, I still believe that my earlier suggestion to use `ssh`
instead of telnet is the correct one, since `ssh` ignores /etc/securetty in the
first place, and additionally ensures that your password never appears in plain
text to be sniffed.
You are correct that this is insecure, but on a system without Unix'98 pty
support, adding ttyp0, ttyp1, etc. still works. As of pam 0.72 from Raw Hide
or Piglet, pam_securetty will assume the tty is in /dev/pts/ if you just use a
digit for the tty's name:
It's still not a safe thing to do in most if not all cases (for the reasons rhw
outlines), but it works.