Bug 163445
| Summary: | sshd interacts badly with pam_limits.so | ||
|---|---|---|---|
| Product: | [Retired] Fedora Legacy | Reporter: | David Warme <a039dmw> |
| Component: | openssh | Assignee: | Fedora Legacy Bugs <bugs> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | ||
| 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-07-16 22:15:21 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: | |||
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 longer required. 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. |
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): How reproducible: Steps to Reproduce: 1. Apply the stated patch to Fedora Core 1 2. Try to login using ssh. 3. Actual results: Connection closed by remote host after entering my password. Expected results: Normally would expect to login and receive a shell prompt. Additional info: 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 pam_limits.so module. 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): #%PAM-1.0 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().