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)
(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.
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?
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?
(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): 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): 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
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
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.