[OpenAFS-port-darwin] Tokens on login via ssh?

[hays@ibiblio.org]

--On Thursday, May 4, 2006 10:31 AM -0700 "Henry B. Hotz" 
<hotz@jpl.nasa.gov> wrote:

>
> On May 4, 2006, at 7:57 AM, hays@ibiblio.org wrote:
>
>>
...
>>
>> We've got an AD K5 realm named CS.UNC.EDU, and the AFS cell is also
>> named cs.unc.edu. There's no trust relationship that I know of
>> between the K5 and K4 systems. The AD realm has service records in
>> DNS, the afs cell does not, but I have the afs servers listed as K4
>> realms in the edu.mit.kerberos file.
>
> Ah, yes.  Jeffrey Altman set up a mailing list for us to discuss AD
> renaming to remove this conflict.  We needed to upgrade from W2K to  W2K3
> first, and we won't finish that for another couple of weeks.   (You can't
> tell JPL.NASA.GOV to trust JPL.NASA.GOV and have any sane  code
> understand that they aren't the same to begin with. ;-)

Not to mention there's no way to keep them separate in the DNS service 
records.

...

>> But, if I when I come in from a remote computer via ssh, I only get
>> the K5 tickets from AD (and the cache location is different).
>>
>> gilgamesh:~ hays$ klist
>> Kerberos 5 ticket cache: 'FILE:/tmp/krb5cc_502_T5CbvTHAdW'
>> Default principal: hays@CS.UNC.EDU
>>
>> Valid Starting     Expires            Service Principal
>> 05/04/06 10:48:16  05/04/06 20:48:17  krbtgt/CS.UNC.EDU@CS.UNC.EDU
>>        renew until 05/05/06 10:48:16
>>
>> klist: No Kerberos 4 tickets in credentials cache
>>
>>
>> This surprises me a bit, I would have expected the behavior to be
>> the same, but then I'm easy to surprise since I don't really
>> understand kerberos.
>
> Interesting.
>
> First question:  Do you type a password when you ssh in?  In other
> words, is that tgt a forwarded one or a locally requested one?

Locally requested--I've been trying to avoid the issue of forwarding 
tickets for now, since we don't use kerberos as kerberos for anything on 
the unix side of the house.

>
> Second, is your script using programs linked against Heimdal?  If so  you
> can put
>
> [libdefaults]
> 	default_cc_name = API:
>
> in your krb5.conf and probably force it to use the in-memory ccache.   As
> long as KRB5CCACHE (or whatever it is) is set properly it  shouldn't
> matter much.  What you really care most about is that the  ccache be
> different for each ssh session and from the console.

That I can't answer, since it the old aklog_tiger binary from CMU. I asked 
Chaskiel about the source code last week, but he couldn't remember which 
source he based it on.

> Actually, it looks like that ccache name is being generated by ssh
> itself, so that trumps what I just said.

Yes, a friend suggested I look at ssh's source, since he thought the ccache 
location was specified there. Sure enough, it looks like sshd is generating 
the entry.

So, just for grins I hacked openssh-4.3p2's auth-krb5.c file, changing:
	    "FILE:/tmp/krb5cc_%d_XXXXXXXXXX", geteuid());
to:
	    "API:Initial default ccache", geteuid());

With sshd in debug mode, that seems to have fixed the problem I had getting 
k4/afs tokens via the system.login.tty key. But I think I've just fallen 
down the same old rabbit hole, since it doesn't work with ssh in regular 
mode--I'm guessing that this goes to the same changes in sshd that broke 
the pam modules in the first place....

Thanks in advance for patience in going over what must be old ground for 
most of you.


--

________________________
bil hays
Network Manager
Computer Science, UNC CH