>> That would be because (a) Kerberos V4 doesn't have ticket forwarding, and >> (b) these things likely predate AFS's use of Kerberos. > >Then how does this work (sshd_config): > KerberosAuthentication yes > KerberosOrLocalPasswd yes > AFSTokenPassing yes > KerberosTicketCleanup no >for [Open]SSH's --with-kerberos4 / --with-afs ?
I believe that it passes the secret bits of the token over, but at least it's doing it over an encrypted pipe (and hopefully after it's verified the remote end). >When you say Kerberos V4 doesn't have ticket forwarding, do you mean that >Kerberos can only do authentication with one's TGT, and then one would >have to manually obtain other Kerberos tickets? Or do you mean no TGT >passing either? Here's the basic problem. "Forwarding" really means two things - passing the ticket plus session key to a remote machine, and changing the IP address in the ticket to match that of the remote machine. The first isn't that hard to do (but requires support from the protocol); the second is not possible in V4. It just so happens that AFS is an application that ignores the IP address in the V4 ticket, so that happens to work. But no other V4 services will. >If one used klog.krb, and the kerberized (V4) r* utilities, and afslog on >the other end, would this be more secure than the AFS r* utilities? Well ... you couldn't run afslog on the remote end, because the TGT wouldn't cross the V4 r* connection. You'd have to kinit/klog.krb again. At that point ... hell, why don't you just run V5? You'll get everything you want, and you'll be glad you did it in the long run. --Ken _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
