> We're generally happy to add shared keys for additional kerberos
> realms if people have additional kerberos realms that they care about.
> Though I think the only shared keys we have now that are actually set
> up correctly are with GRATUITOUS.ORG and ATHENA.MIT.EDU. CYGNUS.COM
> decided they didn't want to set up a shared key with us.
Ick - that sounds extremely unmanagable.
I don't find it unmanageable at all. I created a few shared keys, and
now [EMAIL PROTECTED] can log into all of my accounts that accept
kerberized telnet.
It's *far* more unmanageable when you don't have proper shared keys in
place; Thomas and I (at least) suffered with this until the shared key
between GNU.ORG and ATHENA.MIT.EDU got created.
I've also been hearing noises on occasion about ideas for supporting
public keys in kerberos, but it's not clear to me that the relavent
folks are necessarily going to implement this anytime soon. But
public key support in kerberos might simplify the whole key sharing
mess.
You can also do indirect shared keys in krb5: that is, if
[EMAIL PROTECTED] wants to be able to log into a computer in the
COYOTE.ORG realm, and there is no shared key between ATHENA.MIT.EDU
and COYOTE.ORG, but there is a shared key between ATHENA.MIT.EDU and
GRATUITOUS.ORG and there's another shared key between GRATUITOUS.ORG
and COYOTE.ORG, that is adaquate to allow [EMAIL PROTECTED] to log
into the COYOTE.ORG realm, or so I am told. I have never actually
tried this, and it does apparently require describing which realms to
involve in your krb5.conf
