fbsd8_stable nfsv3 sys=krb5 issue [resolved]

[Rick Macklem]

> Rick, I found the problem once I followed your suggestion to kinit -k
> fbsdclient.ee.auth.gr on the server; the output was "wrong password"
> or
> something like that.
> 
> On both server and client I have two keys stored in their
> /etc/krb5.keytab files: one nfs/blabla and one host/blabla (due to
> other
> services I was testing on them). On the server, the first key stored
> in
> the keytab file was the host/ key and not the nfs/ key. Hence it
> wouldn't accept it (even though the kdc.log wouldn't complain...this I
> still haven't understood so far). Once I placed a single
> /etc/krb5.keytab file containing only the nfs/ key, everything worked
> as
> should.
> 
> Which yields the (natural?) question: Why am I unable to kinit to both
> keys stored in my keytab (I am able to kinit only to the *first* key
> stored in the keytab), even though I have the right to store more than
> one keys in a keytab?
> 
Well, if it can only use the first entry in the keytab file, I would
think that's a bug. (I have used a case where the entry wasn't the first
one in the keytab file before and had it work, but I was using an older
version of Heimdal in the BSD machine and an MIT KDC that generated the
keytab file.)

I have screwed up keytab entries in the past. A couple of my favourite
ways to do so are:
- creating another keytab entry for the same principal, which makes the
  old one invalid, due to the change in version#.
- created the keytab entry with the wrong encryption type.

Oh, and I'm not volunteering to go bug hunting in Kerberos:-) rick