> Therefore the example in ssh(1) for generating a key should say: > > auth/rsagen -t 'service=sshserve owner=*' >/mnt/factotum/ctl
This is the stuff that my literal mind copes poorly with :-) I would never have picked this up. If you don't mind, there's more clarification I need on this issue: how is the sshserver process running as "none" going to upgrade to, say, user "lucio"? Is this a result of the exchange of credentials, using the "capabilities" driver? If it is, there's a depth of cleverness in the new Plan 9 security model that I had missed until now, namely the elimination of the intermediate "superuser" step required by the Unix paradigm. I guess I ought to have figured it out before now... And another equally silly question, maybe there's someone else out there that can learn from my mistakes and/or ignorance: the factotum on the CPU server does not contain all the keys "eve" is entitled to, in fact, it only contained a key that could be constructed from the NVRAM contents (what does the !hex=? entry represent?). It's possible that the secstore was not accessible to "eve" on boot (I've extended the expiry date as soon as I discovered it had lapsed), is it a given that the CPU server's factotum is invoked with the "S" option or should I check somewhere to make sure before I reboot the server? ++L
