Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 113247

Summary: public key authentication fails for ssh using pam_krb5
Product: Red Hat Enterprise Linux 4 Reporter: aleahy
Component: pam_krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: mattdm, m.a.young, mhedemark, tmraz, vgelder
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: 2.1.8-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-25 22:02:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
proposed patch none

Description aleahy 2004-01-10 16:21:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1)
Gecko/20030225

Description of problem:
I am not able to use a public key when connecting to a Fedora Core 1
system (called "leibniz") via ssh.  When attempting to establish a
connection, it fails as follows: 

[aleahy@gregory ~]$ ssh leibniz w
Read from remote host leibniz: Connection reset by peer
[aleahy@gregory ~]$

On closer examination, this problem seems to be limited only to those
who authenticate through the pam_krb5 module.  For instance, if I copy
the authorized_keys file from my account to the root account, I am
able to login to the system as root without a problem:

[aleahy@gregory ~]$ ssh -l root leibniz w
 09:49:52  up 10 days, 23:34,  2 users,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT
root     pts/0    gregory.lab.knet  9:39am  3:10   0.04s  0.04s  -bash
root     pts/1    gregory.lab.knet  9:41am  7:52   0.03s  0.03s  -bash
[aleahy@gregory ~]$

On a Redhat 9 system with identical /etc/pam.d/{sshd,system-auth} and
/etc/krb5.conf files, both of these commands succeed.  

We also use a local LDAP database to hold our UNIX account information
and some authentication information for individuals who do not have
network-wide accounts.  However, I have been able to eliminate this
set-up as a possibility.  'mathlink' is one such account--i.e., it
only exists in the local LDAP directory and does not do any
authentication via kerberos.  When I copy the authorized_keys file
into this account, I am still able to successfully login via ssh:

[aleahy@gregory ~]$ ssh -l mathlink leibniz w
 10:11:09  up 10 days, 23:55,  3 users,  load average: 1.22, 0.93, 0.48
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT
root     pts/0    gregory.lab.knet  9:39am  7.00s  0.11s  0.11s  -bash
root     pts/1    gregory.lab.knet  9:41am 29:09   0.03s  0.03s  -bash
root     pts/2    gregory.lab.knet  9:51am 19:04   0.03s  0.03s  -bash
[aleahy@gregory ~]$

Note that our kerberos server is a Windows Active Directory server. 
I've included a copy of /etc/pam.d/system-auth below.


Version-Release number of selected component (if applicable):
pam_krb5-2.0.4-1

How reproducible:
Always

Steps to Reproduce:
1. create .ssh/authorized_keys in affected system
2. ssh to affected system

    

Actual Results:  "Connection reset by peer" error message as described
above.

Expected Results:  login should have succeeded

Additional info:

Here are the contents of /var/log/secure when a public key login
attempt fails:

Jan 10 09:43:58 leibniz sshd[21859]: PAM rejected by account
configuration[7]: Authentication failure
Jan 10 09:43:58 leibniz sshd[21859]: fatal: monitor_read: unsupported
request: 24

Here are the contents of /etc/pam.d/system-auth:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/$ISA/pam_krb5.so use_first_pass
auth        sufficient    /lib/security/$ISA/pam_ldap.so use_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so
account     [default=bad success=ok user_unknown=ignore
service_err=ignore system_err=ignore] /lib/security/$ISA/pam_ldap.so
account     [default=bad success=ok user_unknown=ignore
service_err=ignore system_err=ignore] /lib/security/$ISA/pam_krb5.so

password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/$ISA/pam_unix.so nullok
use_authtok md5 shadow
password    sufficient    /lib/security/$ISA/pam_krb5.so use_authtok
password    sufficient    /lib/security/$ISA/pam_ldap.so use_authtok
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_krb5.so
session     optional      /lib/security/$ISA/pam_ldap.so

Here are the contents of /etc/pam.d/sshd:

#%PAM-1.0
auth       required     pam_stack.so service=system-auth
auth       required     pam_nologin.so
account    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth
session    required     pam_limits.so
session    optional     pam_console.so

Here are the contents of /etc/krb5.conf:

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 ticket_lifetime = 24000
 default_realm = KNOX.EDU
 dns_lookup_realm = false
 dns_lookup_kdc = false

[realms]
 EXAMPLE.COM = {
  kdc = kerberos.example.com:88
  admin_server = kerberos.example.com:749
  default_domain = example.com
 }

 KNOX.EDU = {
  kdc = pugsly.knox.edu:88
  kdc = leibniz.lab.knet.edu
  admin_server = pugsly.knox.edu:749
 }

[domain_realm]
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM
 .lab.knet.edu = KNOX.EDU
 lab.knet.edu = KNOX.EDU

[kdc]
 profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 86500
   forwardable = true
   krb4_convert = false
 }

Comment 1 Magnus Hedemark 2004-02-20 12:08:49 UTC
I'm getting the same thing on RH9 but only on certain accounts.  

Feb 19 20:21:13 fstpkoplnx02 sshd[17697]: Connection from
151.204.201.101 port 50059
Feb 19 20:21:16 fstpkoplnx02 sshd[17697]: Found matching RSA key:
38:63:c7:01:20:b1:9b:e1:55:4f:f1:88:7b:30:a4:e1
Feb 19 20:21:17 fstpkoplnx02 sshd[17697]: Found matching RSA key:
38:63:c7:01:20:b1:9b:e1:55:4f:f1:88:7b:30:a4:e1
Feb 19 20:21:17 fstpkoplnx02 sshd[17697]: PAM rejected by account
configuration[13]: User account has expired
Feb 19 20:21:17 fstpkoplnx02 sshd[17697]: Failed publickey for turie
from 151.204.201.101 port 50059 ssh2
Feb 19 20:21:17 fstpkoplnx02 sshd[17697]: fatal: monitor_read:
unsupported request: 24


But if I "chage -l turie", the account is not expired.

Comment 2 Maarten van Gelder 2004-06-09 15:30:12 UTC
I have the same problem on Fedora Core 2

Comment 3 Maarten van Gelder 2004-06-10 15:04:20 UTC
After upgrading Fedora 2 with up2date authconfig is version 4.6.2-1. 
That writes a different /etc/pam.d/system-auth file. It is better, 
but prohibits normal login to users with uid>100. After changing this 
threshold to 10000 I was able to login with my Kerberos password.

On another system we have installed Fedora 1.92. That had the same 
problem. But after copying the ultimate pam file from Fedora 2 
Kerberos login was possible also.


Comment 4 Michael Young 2004-06-11 15:44:21 UTC
I think the problem occurs whenever pam_krb5 is called in the account
phase but not in the auth phase (due to some previous auth method
succeeding).
Before line 141 in src/acct.c there is a credential check to check for
an expired key, but the call to the kerberos library is returning
KRB5KDC_ERR_PREAUTH_FAILED rather than KRB5KRB_AP_ERR_BAD_INTEGRITY
which is expected by the code.
#1 looks to me to be a separate problem, #3 is avoiding the issue by
never checking if the krb5 account is valid at all.

Comment 5 Michael Young 2004-06-14 13:28:46 UTC
Created attachment 101104 [details]
proposed patch

After a bit more experimentation, I think the return code from the kerberos
libraries has changed for an invalid password. I believe the attached patch
fixes the problem.

Comment 6 Michael Young 2005-02-01 16:08:36 UTC
Any chance of a fix for this problem please? I have noticed this
problem is still there in FC3, as you get a "password incorrect" error
when you try to su from root to another account. My guess is that it
will also be broken in RHEL4. The patch I posted previously still
seems to work.

Comment 7 Brian Smith 2005-02-24 16:42:17 UTC
It's broken in RHEL4.  Think we should open a bugzilla for that OS?

Comment 8 Michael Young 2005-02-25 14:24:27 UTC
It is probably worth a try. This bug doesn't seem to be getting us anywhere.

Comment 9 Matthew Miller 2006-07-11 17:47:27 UTC
Fedora Core 1 is maintained by the Fedora Legacy project for security updates
only. If this problem is a security issue, please reopen and reassign to the
Fedora Legacy product. If it is not a security issue and hasn't been resolved in
the current FC5 updates or in the FC6 test release, reopen and change the
version to match.

Thanks!

NOTE: Fedora Core 1 is reaching the final end of support even by the Legacy
project. After Fedora Core 6 Test 2 is released (currently scheduled for July
26th), there will be no more security updates for FC1. Please use these next two
weeks to upgrade any remaining FC1 systems to a current release.



Comment 10 Nalin Dahyabhai 2006-10-25 22:02:20 UTC
This should have been fixed in 2.1.8.  Sorry about leaving this one open.