[OpenAFS-devel] token passing in modern ssh?
Harald Barth
haba@pdc.kth.se
Mon, 13 Dec 2004 18:16:05 +0100 (MET)
> you are not providing enough information.
Guilty.
>From
Server: krbtgt/NADA.KTH.SE@NADA.KTH.SE
Ticket etype: des3-cbc-sha1, kvno 4
Auth time: Dec 13 10:23:01 2004
End time: Dec 13 20:23:01 2004
Renew till: Jan 12 10:23:01 2005
Ticket flags: forwardable, renewable, initial
Addresses:
i got
Server: afs@NADA.KTH.SE
Ticket etype: des-cbc-crc, kvno 12
Auth time: Dec 13 10:23:01 2004
Start time: Dec 13 10:23:02 2004
End time: Dec 13 20:23:01 2004
Ticket flags: transited-policy-checked
Addresses:
From
Server: krbtgt/STACKEN.KTH.SE@STACKEN.KTH.SE
Ticket etype: des3-cbc-sha1, kvno 1
Auth time: Dec 13 15:50:09 2004
End time: Dec 14 01:50:09 2004
Renew till: Jan 12 15:50:09 2005
Ticket flags: renewable, initial
Addresses:
i got
Server: afs@NADA.KTH.SE
Ticket etype: des-cbc-crc, kvno 12
Auth time: Dec 13 15:50:09 2004
Start time: Dec 13 15:50:10 2004
End time: Dec 14 01:50:09 2004
Ticket flags: transited-policy-checked
Addresses:
The question is, will both afs@NADA.KTH.SE work the same way
(apart from date) when I afslog to get a token. If both work
the same way, an token program (as afslog) could just pick
the newest. If they are more different because there is some data
that klist does not show, we loose.
> Using a file cache you can certainly force more then one principal's
> tickets into the file. The behavior will not longer be well defined
> if you do.
The question is if the tickets are still uniquely identified or if two
afs@NADA.KTH.SE derived from different krbtgt differ enough to matter.
> A CCAPI cache as used on Mac and Windows will not let you do this.
I can't speak for KFW or KFM, but thn's heimdal derived ktelnet (for
Windows) might let you do this.
Harald.