Red Hat Bugzilla – Bug 163445
sshd interacts badly with pam_limits.so
Last modified: 2007-04-18 13:29:26 EDT
Description of problem:
When we upgraded from openssh*-3.6.1p2-19 to the recent
patch openssh*-3.6.1p2-19.2.legacy we were no longer
able to use SSH to login, except as root.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Apply the stated patch to Fedora Core 1
2. Try to login using ssh.
Connection closed by remote host after entering my password.
Normally would expect to login and receive a shell prompt.
Problem occurs because sshd version 3.6.1p2-19 did not run
"niced", whereas sshd version 3.6.1p2-19.2.legacy does run
"niced" to level 10. This interacts badly with the
I did an strace on the sshd process to try and figure out what was
going on. What I discovered was that the system call
setpriority (PRIO_PROCESS, 0, 0);
(apparently called from the pam_limits.so module in order to set
the default "nice" priority of zero) was failing because the
sshd process now runs at a "nice" value of 10 instead of 0,
and only the superuser can decrease the priority of a process.
This apparently causes the pam_limits.so module to return an
error code. Our PAM configuration provides this configuration
for sshd (completely vanilla Fedora Core 1, I believe):
auth required pam_stack.so service=system-auth
auth required pam_nologin.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
session required pam_limits.so
session optional pam_console.so
Changing the pam_limits line from "required" to "optional"
restored our ability to login. This might have other
adverse effects, however.
Although I have worked around this problem, I am reporting it
because others who install the same patch might find
themselves being locked out from logging in via SSH.
If you are going to make sshd run "niced", then you should
probably "unnice" child processes as they are created -- or
at least "unnice" them before invoking pam_open_session().
Is it an initscript that is setting the nice level? Check /etc/init.d/sshd or
/etc/sysconfig/ssh or something like that. Strange that this would change....
I just checked the SSH source code, and could not find anywhere that
called "nice()" or "setpriority()". I then looked at the sshd process
that was actually running -- it had a nice value of zero -- NOT niced.
When I initially started my investigation, sshd definitely had a
"nice" value of 10. Furthermore, sshd was actually running at the
time I launched the "up2date" process to apply the patched version
of ssh. Once the patch was applied (I assume that applying the
patch caused the existing sshd process to be stopped and restarted),
I was no longer able to login with ssh. To the best of my knowledge,
this process was not stopped or restarted until well into my
investigations (i.e., I suspect that the "nice" of 10 was applied
by the patch logic (as invoked from the up2date GUI app).
Once I discovered what was going on, I modified the /etc/pam.d/sshd
file and re-tried the login. It was still failing. So I did an
"sh /etc/rc.d/init.d/sshd restart", and it started working again.
The new sshd process had a "nice" value of zero again! Setting
the /etc/pam.d/sshd "pam_limits" line back to "required" is no
I suspect that the "nice 10" sshd process occurred because of the
environment inherited from the "up2date" GUI app. Care to wager
25 cents or so?
Ooops -- let me correct that:
Once I restarted sshd, it is no longer necessary for the
pam_limits line in /etc/pam.d/sshd to say "optional" -- it
seems to work fine in the original state of "required".
Strange, however I can't see how this is a bug in SSH. Perhaps up2date, which
we aren't supporting.