Red Hat Bugzilla – Bug 169409
PAM user restrictions on SSHD ignored
Last modified: 2007-11-30 17:11:14 EST
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):
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.
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).
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
Also could you try to add the pam_listfile to the /etc/pam.d/login and try to
login on console?
Created attachment 119374 [details]
Created attachment 119375 [details]
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
Sep 28 09:22:33 tr0g sshd: Accepted password for lenny from 220.127.116.11
port 19501 ssh2
Sep 28 09:22:46 tr0g sshd: Accepted password for michael from
18.104.22.168 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.
There should be at least
sshd(pam_unix)[...]: session opened for user ...
Could you please verify that there is UsePAM yes in the /etc/ssh/sshd_config?
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
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
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
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.