On Thu, May 08, 2008 at 10:02:18AM -0400, Russ Cox wrote: > > 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.
OK, so how does my factotum know that bootes is the remote host owner, or does it just try to authenticate with that key despite that it doesn't match the keyspec user=nwf and see what happens? > > 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. OK. This is, to me, counterintuitive behavior; if I have sufficient credentials it's not really "lying". It seems bizarre that factotum would volunteer my terminal's user id, which is totally disjoint from the user id namespace of the cpu server. > 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. I may be out of date, let me replica/pull and get back to you. > Russ Thanks for your answers. --nwf;
pgpFesB0AbVyX.pgp
Description: PGP signature
