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).
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?
Created attachment 119374 [details] /etc/pam.d/sshd
Created attachment 119375 [details] /etc/pam.d/system-auth
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.
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?
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.
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.