Red Hat Bugzilla – Bug 110944
ssh ignores values in limits.conf
Last modified: 2007-11-30 17:06:59 EST
Description of problem: when logging into a system via ssh, any settings configured via /pam_limits.so (in /etc/security/limits.conf) are ignored Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1.configure ssh or system-auth to use pam_limits.so in a session 2.log in via ssh 3.observe the limits are not changed Actual results: Expected results: Additional info:
ssh + pam_limits is working for me... What specific limits are not working?
Specifically, nofiles was not working when I tested.
Please also note, that this is with privledge seperation on and uselogin no
Via another problem report, I just realized the underlying problem here, and now I'm not quite certain its a bug. As it turns out, this is another issue involving unintended side effectect of the UsePrivlidgeSeparation setting in ssh. When enabled the authentication process in ssh is run as the user id attempting to log in. This means all the code in the pam libraries is executed as that user ID. When executing pam_limits.so, this implies that any limits set which increase soft limits beyond thier hard settings, or increase hard settings at all will fail (as they can only be modified by uid 0). It seems to me that this is simply a limitation of the PrivlidgeSeparation feature in ssh, and as such isn't a bug.
Sorry, the more I think about the less I think this is a bug, but rather a limitation of the UsePrivlidgeSeparation Mode of ssh. This is really a dup of 115442 *** This bug has been marked as a duplicate of 115442 ***
I think you've got it mixed up. The unprivilged portion of ssh handles the network traffic, the privilged portion does the authentication and calls pam. It has to have root access; how else would it access /etc/shadow for example?
Sorry, it was me mis-speaking. Limits are set during session set up (a session directive in the pam configuration), which is part of the user owned process.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.