Bug 575398

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

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.

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.

This is probably kerberos bug.

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.

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

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

(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.

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.

(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?

I've double-checked and can confirm what I've said above, that answer if "Yes" to all the questions from the comment #10.

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

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.