On 1/4/2010 8:42 PM, Russ Allbery wrote: > Jeff Blaine <[email protected]> writes: > >> I happened to notice this (note the missing realm) after a >> failed GSSAPI attempt to the SSH server (mega): > >> [r...@mega ~]# klist >> Ticket cache: FILE:/tmp/krb5cc_0 >> Default principal: jbla...@foo > >> Valid starting Expires Service principal >> 01/04/10 16:14:51 01/11/10 16:14:51 krbtgt/f...@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
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
