> term% echo delkey > /mnt/factotum/ctl > term% cpu -h sea.cs.jhu.edu -k 'user=bootes' > [add key dance] > sea# > term% cpu -h sea.cs.jhu.edu -k 'user=nwf' > [no key dance is necessary] > cpu% > term% cpu -h sea.cs.jhu.edu -k 'user=me' > !Adding key: dom=acm.jhu.edu proto=p9sk1 user=me > [I don't know me@'s password, so I abort by pressing Del.]
> My username on my terminal is nwf. > The question is: why don't I have to present a password > to log in as nwf@ after I have logged in as bootes? Because bootes is the remote host owner. If factotum knows that key, it will use it to vouch for you. This is why you can still mount things from a cpu server that you connected to using ssh or cron or rx or any other non-factotum-supplying method. > Why doesn't this explanation hold for [EMAIL PROTECTED] Your user name on the terminal is nwf. Factotum will vouch for you, not lie for you. All that said, the first cpu should not be adding the bootes key for use in the speakfor role: it should be adding it with role=client only, and then factotum won't use it to authenticate as nwf. I thought it already did that. Please send the output of cat /mnt/factotum/ctl after the above sequence. Thanks. Russ
