Bug 113247 - public key authentication fails for ssh using pam_krb5
Summary: public key authentication fails for ssh using pam_krb5
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: pam_krb5   
(Show other bugs)
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Nalin Dahyabhai
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-01-10 16:21 UTC by aleahy
Modified: 2007-11-30 22:07 UTC (History)
5 users (show)

Fixed In Version: 2.1.8-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-25 22:02:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
proposed patch (393 bytes, patch)
2004-06-14 13:28 UTC, Michael Young
no flags Details | Diff

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)

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):

How reproducible:

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

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:

# 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:

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:

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

 ticket_lifetime = 24000
 default_realm = KNOX.EDU
 dns_lookup_realm = false
 dns_lookup_kdc = false

  kdc = kerberos.example.com:88
  admin_server = kerberos.example.com:749
  default_domain = example.com

  kdc = pugsly.knox.edu:88
  kdc = leibniz.lab.knet.edu
  admin_server = pugsly.knox.edu:749

 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM
 .lab.knet.edu = KNOX.EDU
 lab.knet.edu = KNOX.EDU

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

 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 port 50059
Feb 19 20:21:16 fstpkoplnx02 sshd[17697]: Found matching RSA key:
Feb 19 20:21:17 fstpkoplnx02 sshd[17697]: Found matching RSA key:
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 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
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
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.


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.

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