Bug 169409
Summary: | PAM user restrictions on SSHD ignored | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Lenny G. Arbage <alengarbage> | ||||||
Component: | openssh | Assignee: | Tomas Mraz <tmraz> | ||||||
Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 4 | Keywords: | 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 20:19:07 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Lenny G. Arbage
2005-09-27 22:17:41 UTC
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. |