Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Warn in syslog and the config file that the 'UsePAM no' is actively unsupported|
|Product:||[Fedora] Fedora||Reporter:||Enrico Scholz <rh-bugzilla>|
|Component:||openssh||Assignee:||Petr Lautrbach <plautrba>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||fche, fry.kun, johannbg, lpoetter, mattias.ellert, metherid, mgrepl, michal, mschmidt, notting, plautrba, rvokal, systemd-maint, tmraz|
|Fixed In Version:||openssh-5.8p2-23.fc16||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-12-14 18:33:09 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Enrico Scholz 2011-11-27 12:23:20 EST
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%
Comment 1 Tomas Mraz 2011-11-28 02:24:05 EST
Please post your /etc/pam.d/sshd and /etc/pam.d/password-auth here.
Comment 2 Enrico Scholz 2011-11-28 04:16:25 EST
[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
Comment 3 Tomas Mraz 2011-11-28 04:37:55 EST
Reassigning to systemd as the configuration is correct and pam_systemd in the session is supposed to prevent this.
Comment 4 Michal Schmidt 2011-11-28 08:02:16 EST
What do these commands show when logged in as root via ssh?: cat /proc/self/cgroup systemctl status sshd.service systemd-logind.service
Comment 5 Enrico Scholz 2011-11-28 09:57:55 EST
[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
Comment 6 Michal Schmidt 2011-11-28 11:01:05 EST
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.
Comment 7 Michal Schmidt 2011-11-28 11:14:45 EST
Do you have "UsePAM yes" in /etc/ssh/sshd_config ?
Comment 8 Enrico Scholz 2011-11-28 12:08:10 EST
no, UsePAM is disabled because only GSSAPI + public key auth is done
Comment 9 Michal Schmidt 2011-11-28 12:32:24 EST
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
Comment 10 Michal Jaegermann 2011-11-28 14:35:24 EST
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.
Comment 11 Michal Jaegermann 2011-11-28 14:59:10 EST
(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
Comment 12 Tomas Mraz 2011-11-28 15:31:34 EST
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.
Comment 13 Michal Jaegermann 2011-11-28 16:55:33 EST
(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.
Comment 14 Bill Nottingham 2011-11-28 17:48:11 EST
We could always patch it to ignore the option if set. That could have other consequences, of course.
Comment 15 Tomas Mraz 2011-11-29 02:30:11 EST
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.
Comment 16 Petr Lautrbach 2011-11-29 09:47:22 EST
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.
Comment 17 Fedora Admin XMLRPC Client 2011-11-30 07:25:41 EST
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Comment 18 Petr Lautrbach 2011-12-01 05:16:09 EST
*** Bug 758535 has been marked as a duplicate of this bug. ***
Comment 19 Fedora Update System 2011-12-07 03:02:06 EST
openssh-5.8p2-23.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/openssh-5.8p2-23.fc16
Comment 20 Fedora Update System 2011-12-10 14:59:38 EST
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).
Comment 21 Frank Ch. Eigler 2011-12-13 09:52:40 EST
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).
Comment 22 Tomas Mraz 2011-12-13 10:28:29 EST
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.
Comment 23 Fedora Update System 2011-12-14 18:33:09 EST
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.