Bug 757545

Summary: Warn in syslog and the config file that the 'UsePAM no' is actively unsupported
Product: [Fedora] Fedora Reporter: Enrico Scholz <rh-bugzilla>
Component: opensshAssignee: Petr Lautrbach <plautrba>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: fche, fry.kun, johannbg, lpoetter, mattias.ellert, metherid, mgrepl, michal, mschmidt, notting, plautrba, rvokal, systemd-maint, tmraz
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openssh-5.8p2-23.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-14 18:33:09 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
warning about unsupported UsePAM no option none

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.