Bug 575398 - Kerberos GSSAPI authentication failure: Key table entry not found
Kerberos GSSAPI authentication failure: Key table entry not found
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: krb5 (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-20 10:21 EDT by Roman Kisilenko
Modified: 2010-12-03 12:01 EST (History)
5 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Roman Kisilenko 2010-03-20 10:21:43 EDT
Description of problem:
Attempt to login via ssh using kerberos gssapi authentication method fails. The gssapi error reported by sshd started in debug mode is "Key table entry not found". Kerberos is veirified to be configured correctly both on server and client. DNS A and PTR records are correct. Keytab contains the correct key.

Version-Release number of selected component (if applicable):
openssh-5.2p1-31.f12.x86_64
krb5*1.7.1-2.fc12.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Configure ssh server and client for kerberos authentication
2. Attempt to login to ssh server
  
Actual results:
Login fails. The gssapi error reported by sshd started in debug mode is "Key table entry not found".

Expected results:
Authentication succeeded

Additional info:
After some efforts I've found that adding fully qualified host name to /etc/hosts as a first name for 127.0.0.1 fixes the issue. I.e. instead of 
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
/etc/hosts should contain
127.0.0.1   fully.qualified.hostname localhost localhost.localdomain localhost4 localhost4.localdomain4
Comment 1 Bob Guidinger 2010-03-23 14:37:10 EDT
We experience the same problem.  Playing around with the /etc/hosts file, we found that simply adding a line mapping the IP address to the FQDN also worked.  We are using the following versions.

openssh-5.3p1-19.fc12.i386
krb5*1.7.1-2.fc12.i386
Comment 2 Bob Guidinger 2010-03-26 11:11:42 EDT
After some additional investigation, this is clearly not a bug in Kerberos.  In fact, Kerberos is behaving exactly as it should.  Rather, it was a bug in anaconda which has been fixed in rawhide/F13.  See bug #506384.

This bug can probably be closed.
Comment 3 Roman Kisilenko 2010-03-26 17:07:37 EDT
I think that the missing hostname from /etc/hosts should not break the kerberos auth. If local hostname is set correctly and DNS configured correctly as well and there are no alias in /etc/hosts, why openssl attempts to lookup wrong key name in keytab file?

In fact, I feel like using /etc/hosts is just a workaround, because:
1. It worked just fine without this workaround in Fedora 11.
2. What will happen if the host receives it's hostname via dhcp?
3. Adding fully qualified hostname as last alias looks correct, but does not work.
127.0.0.1   localhost localhost.localdomain localhost4
localhost4.localdomain4 fully.qualified.hostname

Though, I have no deep knowledge about openssh/kerberos internals so my thoughts are probably incomplete.
Comment 4 Jan F. Chadima 2010-06-14 04:03:40 EDT
This is probably kerberos bug.
Comment 5 Nalin Dahyabhai 2010-06-14 10:37:26 EDT
This error message usually indicates that the server's idea of its canonical hostname doesn't match the keys which it has in the keytab.  That usually happens when the local hostname is either set to "localhost", a value which resolves to an alias of "localhost" due to /etc/hosts or DNS misconfiguration.

Roman, Bob, if you could attach the contents of /etc/hosts (both working and not working), we could probably confirm what's going on for your cases.

If the keytab only contains keys for the "host" service (i.e., if it isn't also being used for services other than sshd and other login-like services), turning the GSSAPIStrictAcceptorCheck option off for sshd will tell the server to accept authentication as any name the client believes the server has, which will probably work around any vagaries with the server's name resolution setup.
Comment 6 Roman Kisilenko 2010-06-20 12:31:13 EDT
The hostname is set to the correct value. DNS configured and resolves correctly both from ip address to hostname and from hostname to ip address.

Non-working /etc/hosts:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

Another non-working /etc/hosts:
127.0.0.1   fully.qualified.hostname localhost localhost.localdomain localhost4
localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

Working /etc/hosts:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4 fully.qualified.hostname
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
Comment 7 Roman Kisilenko 2010-06-20 15:54:48 EDT
Sorry, the /etc/hosts files in the previous message assumed to be:

Non-working /etc/hosts:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

WORKING /etc/hosts:
127.0.0.1   fully.qualified.hostname localhost localhost.localdomain localhost4
localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

Another NON-WORKING /etc/hosts:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
fully.qualified.hostname
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
Comment 8 Nalin Dahyabhai 2010-06-21 11:20:32 EDT
(In reply to comment #7)
> Sorry, the /etc/hosts files in the previous message assumed to be:
> 
> Non-working /etc/hosts:
> 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

I want to be sure I understand you.  Do things work as expected with this /etc/hosts file?

> WORKING /etc/hosts:
> 127.0.0.1   fully.qualified.hostname localhost localhost.localdomain localhost4
> localhost4.localdomain4
> ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

This causes name resolution to conclude that 'localhost' is an alias for 'fully.qualified.hostname', so with the system hostname set to either value, when the server process constructs the principal name of the service, it guesses the right value.

> Another NON-WORKING /etc/hosts:
> 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
> fully.qualified.hostname
> ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6    

This causes name resolution to conclude that 'fully.qualified.hostname' is an alias for 'localhost', which is then used to incorrectly guess the principal name of the service.

The presence of the local system's name in /etc/hosts can cause DNS to be bypassed when resolving hosts, so the layout of the file is important if the hostname canonicalization that Kerberos attempts to do is to work properly.
Comment 9 Roman Kisilenko 2010-06-21 13:40:09 EDT
I'll be glad to provide the necessary information. Please let me know if the information below is not relevant to your request.

1. If /etc/hosts is

127.0.0.1   fully.qualified.hostname localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

then authentication starts working fine on Fedora 12.



But if /etc/hosts is 

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

then the GSSAPI authentication does not work on Fedora 12 (it still works fine on Fedora 11). It looks like a problem.
Comment 10 Nalin Dahyabhai 2010-06-21 15:06:23 EDT
(In reply to comment #9)
> But if /etc/hosts is 
> 
> 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
> 
> then the GSSAPI authentication does not work on Fedora 12 (it still works fine
> on Fedora 11). It looks like a problem.    

In this case it looks like it falls to DNS.  Does 'hostname' returns the system's FQDN?  Does it resolve to an IP address?  Does the IP address then resolve back to the FQDN?  Does that match the principal name for which the keytab has keys?
Comment 11 Roman Kisilenko 2010-06-29 13:40:52 EDT
I've double-checked and can confirm what I've said above, that answer if "Yes" to all the questions from the comment #10.
Comment 12 Bug Zapper 2010-11-03 15:05:32 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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 13 Bug Zapper 2010-12-03 12:01:04 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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.