This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 57061 - Openssh does not follow /etc/securetty rules
Openssh does not follow /etc/securetty rules
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-12-03 17:13 EST by Bishop Clark
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-12-03 17:13:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bishop Clark 2001-12-03 17:13:15 EST
Description of Problem:

root telnet, as well as rlogin, behaviour is controlled somewhat by a 
/etc/securetty file, a file which claims to control to which terminals root 
may log in.  

OpenSSH uses PAM for authentication, yet does not access this file in the 
same way rlogin and telnet access this file, in order to check for root 
login permission.  

A line is missing from /etc/pam.d/sshd that allows the sshd to check the 
file.

Version-Release number of selected component (if applicable):
2.9p2-11

How Reproducible:
always

Steps to Reproduce:
1. empty your /etc/securetty
2. telnet in as root - no go
3. log in via ssh as root - no problems.

Actual Results:
a remote user may log into a RH72 box, as root, while rlogin and telnet may 
be configured, activated but locked out via /etc/securetty

Expected Results:
remote users who cannot log in as root via rlogin/telnet because of the 
/etc/securetty policy alone should also not be able to log in via ssh.

Additional Information:
security concern?  Maybe.  Maybe not.
Comment 1 Nalin Dahyabhai 2002-03-07 12:09:57 EST
Generally, I take securetty to mean "the tty can't be eavesdropped", which means
that encrypted network connections as root should be allowed in ssh (so long as
the cipher isn't "none", which requires code changes to allow), but not telnet
or rsh/rexec/rlogin, all of which use login.  Others do disagree, however.

This is a configuration issue (you can set PermitRootLogin to "no" in
/etc/ssh/sshd_config to disable access for root), and because I don't intend to
change it for now (though I could always be persuaded otherwise), I'll mark it
as won't fix.

As an aside, pam_securetty can't be used for openssh all the time because (like
rsh) the protocol doesn't always allocate a TTY on the server.  Currently I
believe OpenSSH uses a TTY of "NODEVssh" in this case (rsh uses "rsh", BTW), so
ify you edit /etc/pam.d/sshd to add pam_securetty, you'll want to keep that in mind.

Note You need to log in before you can comment on or make changes to this bug.