Description of problem: When trying to upgrade openssh-server over an ssh connection, the yum process is killed in the middle of a transaction. Can be reproduced e.g. by | [ensc@apadana ~]$ ssh root@ensc-virt | [root@ensc-virt ~]# /bin/systemctl try-restart sshd.service | Connection to ensc-virt closed by remote host. | Connection to ensc-virt closed. Worked fine with F15. Version-Release number of selected component (if applicable): openssh-5.8p2-22.fc16.x86_64 systemd-37-3.fc16.x86_64 How reproducible: 100%
Please post your /etc/pam.d/sshd and /etc/pam.d/password-auth here.
[root@ensc-virt ~]# cat /etc/pam.d/sshd #%PAM-1.0 auth required pam_sepermit.so auth substack password-auth auth include postlogin account required pam_nologin.so account include password-auth password include password-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_loginuid.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open env_params session optional pam_keyinit.so force revoke session include password-auth session include postlogin [root@ensc-virt ~]# cat /etc/pam.d/password-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth requisite pam_succeed_if.so uid <= 60000 quiet auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so account required pam_access.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account sufficient pam_succeed_if.so uid >= 60000 quiet account [default=bad success=ok user_unknown=ignore] pam_krb5.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so sha256 shadow nullok try_first_pass use_authtok password sufficient pam_krb5.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_krb5.so session sufficient pam_succeed_if.so uid < 500 quiet session sufficient pam_succeed_if.so uid >= 10000 quiet session optional pam_mkhomedir.so
Reassigning to systemd as the configuration is correct and pam_systemd in the session is supposed to prevent this.
What do these commands show when logged in as root via ssh?: cat /proc/self/cgroup systemctl status sshd.service systemd-logind.service
[root@ensc-virt ~]# cat /proc/self/cgroup 9:perf_event:/ 8:blkio:/ 7:net_cls:/ 6:freezer:/ 5:devices:/ 4:memory:/ 3:cpuacct,cpu:/system/sshd.service 2:cpuset:/ 1:name=systemd:/system/sshd.service [root@ensc-virt ~]# systemctl status sshd.service systemd-logind.service sshd.service - OpenSSH server daemon Loaded: loaded (/lib/systemd/system/sshd.service; enabled) Active: active (running) since Sun, 27 Nov 2011 21:04:53 +0100; 18h ago Process: 14492 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Main PID: 2281 (sshd) CGroup: name=systemd:/system/sshd.service ├ 2281 /usr/sbin/sshd -D ├ 14545 sshd: root@pts/35 ├ 14551 -bash └ 14646 systemctl status sshd.service systemd-logind.service systemd-logind.service - Login Service Loaded: loaded (/lib/systemd/system/systemd-logind.service; static) Active: active (running) since Sun, 27 Nov 2011 21:04:48 +0100; 18h ago Main PID: 1772 (systemd-logind) CGroup: name=systemd:/system/systemd-logind.service └ 1772 /lib/systemd/systemd-logind
For some reason the shell did not get moved to a new cgroup. Check /var/log/messages and /var/log/secure for anything related to systemd- logind or pam_systemd at the time of the ssh login.
Do you have "UsePAM yes" in /etc/ssh/sshd_config ?
no, UsePAM is disabled because only GSSAPI + public key auth is done
The moving to a new cgroup depends on PAM session processing. From sshd_config as shipped by the RPM package: # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. #UsePAM no UsePAM yes
These are replies to questions asked in bug 756503 (now closed). > Michal, do I understand it right that you have password-auth in /etc/pam.d/sshd Indeed I do. Among other lines I have the following in this file: auth substack password-auth account include password-auth password include password-auth session include password-auth > and pam_systemd in /etc/pam.d/password-auth. This is the case. > And still if you do 'systemctl try-restart sshd.service' > it will drop your ssh connection? Yeap! Immediately and every time. That particular box is a small server running on a local network only without X and usually without any local display or a keyboard. That what makes it even more annoying. Luckily sshd is not killed by that command so one can log back right away but yum transactions invoking the above are getting screwed in the process. That installation was moved, via anaconda, from F14 to F16 and I made sure that 'authconfig --update' was run after that. An output from 'cat /proc/self/cgroup' is the same as in comment #5. I do not see anything "unusual" in /var/log/messages. In /var/log/secure I get 'ssh_selinux_change_context: setcon failed with Invalid argument' after every login but I have SELinux set to 'permissive' and no selinux releated complaints elsewhere. In the meantime I brought another installation from F14 to F16. That one more of a "regular desktop" kind. It has another set of troubles but not this one. Boggles.
(In reply to comment #9) > The moving to a new cgroup depends on PAM session processing. Indeed, I had 'UsePAM no' in my sshd_config for reasons which now vanished in a fog of the past. Replacing that with 'UsePAM yes' did solve the issue. If this is suddenly so critical then maybe package scritps, for openssh-server I guess, should make sure that this is the case. Not that difficult. Something like: sconf=/etc/ssh/sshd_config if grep -q '^UsePAM .*no' $sconf 2>/dev/null; then sed -i 's/^UsePAM .*no/UsePAM yes/' $sconf fi
Well UsePAM yes was necessary for multiple other things for a long long time. I wonder if we shouldn't make rather a big fat warning in the default configuration file and also warn in the syslog on the sshd start up when the UsePAM no is set. Reopening and changing the title of the bug.
(In reply to comment #12) > I wonder if we shouldn't make rather a big fat warning in the default > configuration file and also warn in the syslog on the sshd start up when the > UsePAM no is set. That for sure would help to untangle the mystery. Still in this particular case I was first hit by openssh updates and only later was doing .rpmnew cleanups. You can find some who never bother with such details until something stopped working in toto.
We could always patch it to ignore the option if set. That could have other consequences, of course.
Also the problem with distro upgrades would not be solved anyway as the existing session would be already running with UsePAM no and so the session would be killed during the upgrade.
Created attachment 538028 [details] warning about unsupported UsePAM no option I wouldn't ignore any option, it can lead to confusion. Warning users about unsupported configuration should be enough, I think.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
*** Bug 758535 has been marked as a duplicate of this bug. ***
openssh-5.8p2-23.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/openssh-5.8p2-23.fc16
Package openssh-5.8p2-23.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing openssh-5.8p2-23.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16919/openssh-5.8p2-23.fc16 then log in and leave karma (feedback).
FWIW, the warning wording could be more informative: 'UsePAM no' is not supported in Fedora and may cause several problems. should identify the kinds of problems (systemd / cgroup).
No, there might be other problems, the list would not be exhaustive and I do not think the configuration file and/or syslog messages are place for such elaborates.
openssh-5.8p2-23.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.