Bug 756503
Summary: | Restarting sshd kills active connections | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ben Webb <ben> |
Component: | openssh | Assignee: | Jan F. Chadima <jchadima> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 16 | CC: | jchadima, mattias.ellert, mgrepl, michal, plautrba, tmraz |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-11-28 09:39:24 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: |
Description
Ben Webb
2011-11-23 19:25:42 UTC
This happens only when there is no pam_systemd in the /etc/pam.d/password-auth. What's in your /etc/pam.d/password-auth? (In reply to comment #1) > This happens only when there is no pam_systemd in the /etc/pam.d/password-auth. Ah, that's it, thanks. Our configuration files were inherited from pre-systemd days. With pam_systemd added in, sshd restarts work successfully now. (In reply to comment #1) > This happens only when there is no pam_systemd in the /etc/pam.d/password-auth. > What's in your /etc/pam.d/password-auth? Apparently this is only a part of a story. On a system I just switched from F14 to F16 I do have '-session optional pam_systemd.so' in /etc/pam.d/password-auth. Still '/bin/systemctl try-restart sshd.service' immediately drops all connections. Moreover this left me with the following after the last updates: Nov 27 11:02:08 Updated: glibc-common-2.14.90-19.x86_64 Nov 27 11:02:13 Updated: glibc-2.14.90-19.x86_64 Nov 27 11:02:13 Updated: openssh-5.8p2-22.fc16.x86_64 Nov 27 11:02:15 Updated: glibc-headers-2.14.90-19.x86_64 Nov 27 11:02:16 Updated: glibc-devel-2.14.90-19.x86_64 Nov 27 11:02:17 Updated: openssh-server-5.8p2-22.fc16.x86_64 Nov 27 11:02:17 Updated: openssh-clients-5.8p2-22.fc16.x86_64 and no transaction cleanup so all these are now duplicates with a strange exception of glibc-devel. To an added attraction an attempt to run yum-complete-transaction to cleanup that mess ended up with: Transaction size changed - this means we are not doing the same transaction as we were before. Aborting and disabling this transaction. Very nice, indeed! It does not matter if in /etc/pam.d/password-auth I have -session optional pam_systemd.so or session optional pam_systemd.so Effects if "try-restart" are exactly the same. BTW - I tried to find out in pam documentation what "-session" may mean, as opposed to "session" and I am still in a dark. Curiously enough my rawhide installation, continuously updated for a very long time, and with a similar password-auth, is NOT killing ssh connection on this "try-restart". Hm, on rawhide openssh happens to be now openssh-server-5.9p1-13.fc17 while the one updated on F16 is openssh-5.8p2-22.fc16. OTOH I do not remember this problem on rawhide for a long, long time. To make it even more annoying it is also impossible to run 'package-cleanup --cleandupes' on a remote machine as this not only drops connections but also abandons a transaction so 'rpm -e --noscripts ...' is required. I do not see any real differences between password-auth from rawhide (no problems with sshd restarts) and F16. Michal, do I understand it right that you have password-auth in /etc/pam.d/sshd and pam_systemd in /etc/pam.d/password-auth. And still if you do 'systemctl try-restart sshd.service' it will drop your ssh connection? That would be a bug in the systemd or pam_systemd then. Also the '-' before the pam entry means that if the module is missing on the system the pam library will not report it in the syslog. It is documented in the pam.conf(5) manpage. Let's track this in bug 757545 as the original reporter of this bug did not have the pam_systemd in the configuration. (In reply to comment #7) > Let's track this in bug 757545 As this was closed then I will put replies to comment #5 in comments to bug 757545. |