Bug 169409

Summary: PAM user restrictions on SSHD ignored
Product: [Fedora] Fedora Reporter: Lenny G. Arbage <alengarbage>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4Keywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
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:
Cloudforms Team: ---
Attachments:
Description Flags
/etc/pam.d/sshd
none
/etc/pam.d/system-auth none

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.