Wrong principal in request

[Jeffrey Altman]

On 1/4/2010 8:42 PM, Russ Allbery wrote:
> Jeff Blaine <jblaine at kickflop.net> writes:
>
>> I happened to notice this (note the missing realm) after a
>> failed GSSAPI attempt to the SSH server (mega):
>
>> [root at mega ~]# klist
>> Ticket cache: FILE:/tmp/krb5cc_0
>> Default principal: jblaine at FOO
>
>> Valid starting     Expires            Service principal
>> 01/04/10 16:14:51  01/11/10 16:14:51  krbtgt/FOO at FOO
>>          renew until 01/18/10 16:14:51
>> 01/04/10 16:15:08  01/11/10 16:14:51  host/mega@
>>          renew until 01/18/10 16:14:51
>
> Ah, that means that the client doesn't know what the local realm is and is
> therefore trying to ask the server via referrals, but the server isn't
> answering that question.
Unfortunately this is not a correct interpretation of what is happening.
  The host/mega@ does indicate that referrals are being used.  However,
when referrals are in use the client application has no idea what the
realm should be and so the resulting ticket is stored without the realm
in the name.  This was done in order to ensure that the service ticket
could be found in the cache the next time an application seeks a service
ticket for such a service principal via referrals (which is represented
by specifying the NUL realm name.)

What may be going on for the version of Putty that you are using is that
it is calling krb5_get_host_realm in order to try to obtain the realm
name for the server up front.  If there is no host to realm mapping in
the krb5 profile then this function will always return the NUL realm
name indicating that referrals will be used.   Specifying the host to
realm mapping in the krb5 profile results in the referrals logic being
disabled.

Jeffrey Altman