Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 Description of problem: Either the /etc/security/limits.conf file has incorrect permissions set by the RPM installation, or the associated PAM module is broken, as far as I can tell. Version-Release number of selected component (if applicable): pam-0.77-15 How reproducible: Always Steps to Reproduce: 1. Try to ssh to localhost on default Fedora Core installation This fails, logging fatal: PAM session setup failed[6]: Permission denied to /var/log/secure 2. Change permission on /etc/security/limits.conf to -rw------- This removes read privilegs for everyone but root 3. Now you can connect to localhost using ssh 4. Put back permissions on /etc/security/limits.conf 5. Back to square one, can't ssh to localhost Additional info: This may be a documentation/ permissions bugs for the PAM package, or it might be a symptom of something more serious. Labelling as a security issue until someone examines it and figures out what is actually wrong.
Works fine here, FWIW.
The problem is not present in the standard Fedora Core 1 installation. I can reproduce the problem if I change something in /etc/security/limits.conf By adding the following lines to limits.conf: * soft nofile 2048 * hard nofile 4096 And then trying to login from a remote PC (as a regular user, not root), the problem appears in /var/log/messages: sshd[2161]: fatal: PAM session setup failed[6]: Permission denied The problem disappears as soon at the permissions are set to: -rw------- My version of pam is 0.77-15.
Removing security severity; This is a bug, not a security issue.
This bug seems to exist in Fedora Core 2 as well. If I modify /etc/security/limits.conf, the same message as above will appear from sshd, about pam: PAM session setup failed[6]: Permission denied If I chmod go-r /etc/security/limits.conf, the message in /var/log/secure goes away, but is replaced by a: pam_limits[16469]: can not read settings from /etc/security/limits. conf polaris pam_limits[16469]: error parsing the configuration file I don't think it's a syntax error on my part in limits.conf, since I get the same error message with all of the file being comments. So the work around suggested actually disables limits.conf. What I am trying to achieve: Per user custom limits, such as higher number of open file descriptors for certain users. What I do: Edit /etc/security/limits.conf and add the lines user hard nofile 16384 user soft nofile 8192 What happens: Unable to log in through sshd with that username anymore, error message: fatal: PAM session setup failed[6]: Permission denied This on Fedora Core 2, tested on Fedora Core 1 with the same results.
The problem seems to occur only when trying to *raise* the limits for SSH sessions. See also bug #115442, where a workaround is proposed for sshd. Addition to that: one could create a "/etc/sysconfig/sshd" file, containing "ulimit -n 16384" or something similar..
Same here with FC1 - pam-0.77-15 appear from sshd, about pam: PAM session setup failed[6]: Permission denied I read this http://list.linux-vserver.org/archive/vserver/msg06663.html and applied : comment out pam_limits.so from both /etc/pam.d/sshd and /etc/pam.d/system-auth. seems work better
I've verified this problem persists in Fedora Core 2. openssh-3.6.1p2-34 pam-0.77-40 Also, I run SSH via xinetd. xinetd-2.3.13-2 Typically I include a 'nice' value in the xinetd configuration for ssh. When this value is included, any non-root ssh connection is immediately terminated after authentication and the following error message is added to the /var/log/secure file. sshd[1530]: fatal: PAM session setup failed[6]: Permission denied Removing the 'nice' value from the xinetd configuration file allows me a successful non-root login. Bummer ... what other services does this 'limits' glitch affect ...
OK it seems to me that there are mixed together many different bug reports here. On FC 2 and latest devel I see only the bug as reported in the comments #6 and #7.
I confirm that this exists still in FC2. To summarise in simpler all-in-one-commment terms: - Clean install of FC2 - Add limits to /etc/security/limits.conf - Restart SSHD - SSH login fails with following error: fatal: PAM session setup failed[6]: Permission denied - chmod /etc/security/limits.conf to -rw------ - SSH login works fine. Hope this helps. It'll only be noticable to someone who's tweaked their limits (I did so to get Oracle 10g to work)
Please try latest development packages of openssh and pam. If you chmod the limits file as you write you will effectively disable it's processing and so it won't fail.
*** Bug 113559 has been marked as a duplicate of this bug. ***
I've run into this problem with FC2 at the latest release level. It seems that I increased some of the limits in limits.conf. Now, if I attempt to login as other than root, the session gets killed. Now the interesting part, if I restart sshd, it works fine. I hypothesize that the new feature in sshd that causes new sessions to be run as the user instead of root, is having trouble initiating a new instance because the new instance uses larger limits that what the original process does. When you restart the parent sshd process, it picks up the enlarged limits and everything works fine.
Yes, it's exactly the way you write. But there is nothing we can do with that (at least on the pam side).
Interesting.. I am seeing this problem on a system I just upgraded from FC1 (with all "official" updates applied, and it worked fine) to FC2. On FC2, I can ssh in fine (as a non-root user, and with a modified limits.conf) IF I use the original FC2 kernel: kernel-2.6.5-1.358. However, if I boot into the latest currently available FC2 kernel: kernel-2.6.8-1.521 it fails as you all describe above, with the PAM error. Anyone have any comments as to why this would succeed on the older kernel, and fail on the newer kernel? Can anyone else see if he gets the same difference in behavior?
More information.... for me, the line in limits.conf that was killing my SSH logins was the following: * hard memlock 131072 I did a little testing and here is what was happening. If I logged in on the console, my Hlim (hard limit) would get set to 131072, and my Slim (soft limit) would get set to 32. However, if I try to SSH to the system, the Hlim apparently gets knocked back down to my Slim (so they're both at 32 at this point). Then, per the above setting, it would apparently try (as my unprivileged userid) to increase the hard limit back to 131072; and as we all know, a regular user cannot increase his own Hard limit, he can only increase the Soft limit (up to the Hard limit). How do I know this? Because if I set the Hlim to 32 in limits.conf, I can log in via SSH without any problems. Then, if I do 'ulimit -Ha' in my SSH session, it tells me the hard limit is set to 32 (same as my prior and current Soft limit). So, now the question is: is this an issue with SSHD, or with the kernel? Why does this only occur with the newer kernel, and not with the older? What is responsible for knocking down my Hard Limit (this should never occur throughout this process AFAICT, and IMHO is the cause of the whole problem).
who change the bug for "not a bug" is one of the biggest bug on fedora ... only my solution on #c6 can resolv the situation ignoring limits
I can confirm this is still out in the wild. FC-2 can either be fixed via #c6 or in /etc/ssh/sshd_config changing #UsePrivilegeSeparation yes into UsePrivilegeSeparation no this works too but I don't think either is the best plan.
I just tested this again. I am running openssh via xinetd with a "nice" value. (I posted the bugzilla entry <a href="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111175#c7">#7</a>.) Specifically: <br> kernel-2.6.10-1.766_FC3<br> openssh-server-3.9p1-7<br> pam-0.77-66.2<br> xinetd-2.3.13-4<br> With these updates, this issue appears to have disappeared. I am not using privilege separation in sshd_config and I'm not making limits.conf unreadable. Whereas I believe listing the "resolution" as NOTABUG is a bit misleading, I do think the "status" of CLOSED is appropriate -- at least for FC3.
This is not a bug in PAM, it's a bug in openssh privsep mode how it calls pam (with dropped privileges). This is fixed in openssh >= 3.8p1.