Bug 169409 - PAM user restrictions on SSHD ignored
PAM user restrictions on SSHD ignored
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-27 18:17 EDT by Lenny G. Arbage
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-28 16:19:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/etc/pam.d/sshd (448 bytes, text/plain)
2005-09-28 11:27 EDT, Lenny G. Arbage
no flags Details
/etc/pam.d/system-auth (688 bytes, text/plain)
2005-09-28 11:28 EDT, Lenny G. Arbage
no flags Details

  None (edit)
Description Lenny G. Arbage 2005-09-27 18:17:41 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 SUSE/1.0.4-1.1

Description of problem:
Adding a line to /etc/pam.d/sshd like:

auth       required     pam_listfile.so onerr=fail item=user sense=allow file=/etc/sshd.allow

Seems to have no effect -- all users can still login via ssh, regardless of whether they are listed in /etc/sshd.allow

Version-Release number of selected component (if applicable):
openssh-4.2p1-fc4.1, pam-0.79-9.5

How reproducible:
Always

Steps to Reproduce:
1. Modify /etc/pam.d/sshd as above
2. Edit /etc/sshd.allow with only selected users
3. Attempt to login to the box with an account not listed in /etc/sshd.allow
  

Actual Results:  login attempt was successful.

Expected Results:  login attempt should be denied.

Additional info:

These settings, unchanged, worked beautifully in FC3.

I consider this a major security issue -- hackers were launching rootkit/portscans from an account on my box with a weak password.  Granted, having a known weak password is bad -- but my box is behind a firewall with only a hole punched for ssh (22), and I was relying on pam preventing logins for all accounts except those with known-strong passwords (in my case, only my user account).
Comment 1 Tomas Mraz 2005-09-28 08:16:23 EDT
I'm sorry, but I cannot reproduce your problem with exactly the same versions of
pam and openssh.

Could you please attach your /etc/pam.d/sshd, system-auth and also messages from
/var/log/messages and /var/log/secure when you try to login allowed and
disallowed user?

Also could you try to add the pam_listfile to the /etc/pam.d/login and try to
login on console?
Comment 2 Lenny G. Arbage 2005-09-28 11:27:32 EDT
Created attachment 119374 [details]
/etc/pam.d/sshd
Comment 3 Lenny G. Arbage 2005-09-28 11:28:09 EDT
Created attachment 119375 [details]
/etc/pam.d/system-auth
Comment 4 Lenny G. Arbage 2005-09-28 11:29:30 EDT
Attached /etc/pam.d/sshd and /etc/pam.d/system-auth.

No messages appear in /var/log/messages when I login either allowed or disallowed.

/var/log/secure has identical entries for allowed (lenny) and disallowed
(michael) users:
Sep 28 09:22:33 tr0g sshd[14253]: Accepted password for lenny from 113.65.202.9
port 19501 ssh2
Sep 28 09:22:46 tr0g sshd[14285]: Accepted password for michael from
113.65.202.9 port 19502 ssh2

I don't have physical access to the machine right now, but will try console
login with pam_listfile this afternoon.

It does appear that pam is working otherwise -- /var/log/messages has entries
from pam_unix sprinkled throughout.

Thanks for looking into this.
Comment 5 Tomas Mraz 2005-09-28 15:21:04 EDT
There should be at least 
sshd(pam_unix)[...]: session opened for user ...
in /var/log/messages

Could you please verify that there is UsePAM yes in the /etc/ssh/sshd_config?
Comment 6 Lenny G. Arbage 2005-09-28 15:38:44 EDT
I think you've got it!  'UsePAM yes' was not in /etc/ssh/sshd_config, but was in
/etc/ssh/sshd_config.rpmnew.  Adding this in and restarting sshd now correctly
allows/disallows users.

I suppose this looks a lot like user/config error, but it was introduced by
upgrading (not sure if the old sshd_config came from FC3, or an earlier openssh
version in FC4).  Is there any way to alert the user that an option that used to
be default on is now default off?  If the user misses a message to this effect
while upgrading, that's one thing, but if security features that used to be
enabled by default get disabled by default, that's something else entirely -- in
my humble opinion, something very very bad.  Or could the package move
sshd_config to sshd_config.rpmold and force default usage of the default
packaged sshd_config with 'UsePAM yes'?  Could there be other users out there
who think pam is protecting their sshd configs, but because of an upgrade lost
all protection?

At any rate, thank you very much for solving my problem.  If I can be of any
assistance in determining if this problem is more extensive than just me, let me
know.
Comment 7 Tomas Mraz 2005-09-28 16:19:07 EDT
The 'UsePAM yes' was added to the default sshd_config already in FC3 so your
sshd_config must be even older (FC2 or older).

Generaly admins MUST always verify the changes in .rpmnew files after upgrading
packages and adjust their config files appropriately. There is open bugzilla
request (I don't remember the number) to signal that there are .rpmnew/.rpmorig
files after upgrading to user even if he uses graphical tools for upgrades.

Using the .rpmorig instead of .rpmsave wouldn't change anything as it could
remove additional security settings which were setup by the admin itself. So it
wouldn't help either.

Also note that this concrete problem happened because of upgrade from one FC
release to another which is not recommended and admin must be even more careful
about these .rpmorig and .rpmsave files.

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