Bug 509026 - execution of the pam stack stops after failed auth via pam_krb5
execution of the pam stack stops after failed auth via pam_krb5
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pam_krb5 (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-30 18:09 EDT by Christian Krause
Modified: 2009-12-18 04:36 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 04:36:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Christian Krause 2009-06-30 18:09:23 EDT
Description of problem:
The last update of pam_krb5 breaks the the following use case of pam_krb5:

If the pam stack (type "auth") consists of the pam_krb5 module marked as "sufficient" followed by pam_unix and the kerberos authentication fails, the execution of the pam stack immediately stops after the failed auth of the krb5 module instead of trying the pam_unix auth.

Most likely the problem was introduced by the fix for #502602, since downgrading to the previous version makes the problem go away.


Version-Release number of selected component (if applicable):
pam_krb5-2.3.5-1.fc10.i386


How reproducible:
100%

Steps to Reproduce:
1. configure a pam stack like this (please note that this may break your ability to log in to the machine, so make sure you have e.g. another shell open...):

system-auth:
auth        required      pam_env.so
auth        sufficient    pam_krb5.so use_first_pass minimum_uid=500 ignore_afs
auth        sufficient    pam_unix.so try_first_pass nullok
auth        required      pam_deny.so

[...]

2. try to log in to the machine (e.g. using ssh) without having kerberos credentials
  
Actual results:

# ssh chkr@myhost
chkr@myhost's password:
Connection closed by 192.168.x.x
# 


Expected results:
- since pam_krb5 is marked as "sufficient", a failed authentication should not stop the execution of the whole pam stack (man 5 pam.conf)
- the pam_unix module should be executed afterwards and the login should be successful (given the user has a local account and the password is correct)


Additional info:
1. the following appears in myhost's /var/log/secure:
------------------------------
Jun 30 22:20:10 myhost sshd[29395]: pam_krb5[29395]: authentication fails for 'chkr' (chkr@MYDOMAIN): Authentication failure (Cannot read password)
Jun 30 22:20:10 myhost sshd[29395]: pam_krb5[29395]: account checks fail for 'chkr': unknown reason -1765328254 (Cannot read password)
Jun 30 22:20:10 myhost sshd[29396]: fatal: Access denied for user chkr by PAM account configuration
Jun 30 22:20:10 myhost sshd[29395]: Failed password for chkr from 192.168.x.x port 51079 ssh2
------------------------------
That the kerberos auth itself fails is intended as required by the steps to reproduce....


2. after installing the previous version of pam_krb5:
rpm -U pam_krb5-2.3.2-1.fc10.i386.rpm --oldpackage
a login via the pam_unix works again without any problems


3. login with kerberos credentials works with the old as well as with the new pam_krb5 package


4. most likely the problem exists also in F9, F10, F11 and rawhide (since pam_krb5 was updated for all releases)
Comment 1 Nalin Dahyabhai 2009-06-30 18:21:58 EDT
(In reply to comment #0)
> system-auth:
> auth        required      pam_env.so
> auth        sufficient    pam_krb5.so use_first_pass minimum_uid=500 ignore_afs
> auth        sufficient    pam_unix.so try_first_pass nullok
> auth        required      pam_deny.so

That's a buggy configuration -- it's expected to break because pam_krb5's been configured to not prompt for a password.  When pam_krb5 is subsequently called to perform account management, it's not ignoring the previous error.  That's a bug, but you're only managing to hit it because of the configuration problem.  Switch the order of try_first_pass/use_first_pass so that it looks more like this:

  auth        required      pam_env.so
  auth        sufficient    pam_krb5.so try_first_pass minimum_uid=500 ignore_afs
  auth        sufficient    pam_unix.so use_first_pass nullok
  auth        required      pam_deny.so

and you should be fine.
Comment 2 Eduardo Habkost 2009-08-21 14:18:28 EDT
I am getting the same error here, and the pam_krb5 error prevents me from logging in using a ssh rsa key. The config file generated by authconfig is:

#%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        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 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 md5 shadow nis 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     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_krb5.so


/etc/sysconfig/authconfig is:

USEWINBINDAUTH=no
USEKERBEROS=yes
USESYSNETAUTH=no
USEPAMACCESS=no
FORCESMARTCARD=no
USESMBAUTH=no
USESMARTCARD=no
USELDAPAUTH=no
USELOCAUTHORIZE=yes
USEWINBIND=no
USESHADOW=yes
USEDB=no
USEMD5=yes
USEHESIOD=no
USELDAP=yes
USEPASSWDQC=no
USECRACKLIB=yes
USENIS=no

Installed packages:
authconfig-5.4.4-1.fc10.x86_64
pam_krb5-2.3.5-1.fc10.x86_64
pam-1.0.4-4.fc10.x86_64


If I set USEKERBEROS=no on /etc/sysconfig/authconfig, I can log in again using a ssh key.

Is this an authconfig bug, or a feature?
Comment 3 Nalin Dahyabhai 2009-08-21 16:48:09 EDT
The module shouldn't be preventing key-based login via ssh.  What error is logged when access is denied?  Is Kerberos configured correctly on the ssh server?
Comment 4 Eduardo Habkost 2009-08-22 09:16:30 EDT
(In reply to comment #3)
> The module shouldn't be preventing key-based login via ssh.  What error is
> logged when access is denied?  Is Kerberos configured correctly on the ssh
> server?  

This is what I get if kerberos is enabled on authconfig:

Aug 22 09:08:22 XXX sshd[30886]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=XXXXXXXXXX  user=ehabkost
Aug 22 09:08:22 XXX sshd[30886]: pam_krb5[30886]: authentication fails for 'ehabkost' (ehabkost@REDHAT.COM): Authentication failure (Cannot read password)
Aug 22 09:08:24 XXX sshd[30887]: Connection closed by 10.11.12.24
Aug 22 09:08:27 XXX sshd[30888]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=XXXXXXXXXX  user=ehabkost
Aug 22 09:08:27 XXX sshd[30888]: pam_krb5[30888]: authentication fails for 'ehabkost' (ehabkost@REDHAT.COM): Authentication failure (Cannot read password)
Aug 22 09:08:30 XXX sshd[30888]: pam_krb5[30888]: account checks fail for 'ehabkost': unknown reason -1765328254 (Cannot read password)
Aug 22 09:08:30 XXX sshd[30889]: fatal: Access denied for user ehabkost by PAM account configuration


I didn't check the sshd kerberos configuration, but it was working before a upgrade of many Fedora 10 packages, then it stopped working.


On the client side, I see:

debug1: Connection established.
debug1: identity file /home/ehabkost/.ssh/identity type -1
debug1: identity file /home/ehabkost/.ssh/id_rsa type 1
debug1: identity file /home/ehabkost/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'XXX' is known and matches the RSA host key.
debug1: Found key in /home/ehabkost/.ssh/known_hosts:198
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/ehabkost/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 533
Connection closed by XX.YY.XX.YY
Comment 5 Bug Zapper 2009-11-18 07:08:20 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Bug Zapper 2009-12-18 04:36:25 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.