> 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?
The first step in the authentication protocol is to exchange information about who is on what side, and the remote side says it is bootes in the domain acm.jhu.edu. Factotum doesn't just try the key blindly; it knows the key is valid. >> > 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. The remote factotum has a bootes key valid for the server role, and the local factotum has a bootes key valid for the speakfor role. You're only supposed to do that when the two machines are in the same authentication domain and share their user id name space. (That's the whole reason speakfor exists.) If you don't want factotum to speak for you, you shouldn't give it bootes's key in the speakfor role. The real problem here is that cpu -k 'user=bootes' has managed to request the key for all roles, not just for the client role. That's the part I don't understand. When it says !adding key, the line describing the key should say "role=client", and if the key is added with that tag, then you shouldn't see the behavior above. That's why I want to see your /mnt/factotum/ctl file. Russ
