From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7c1427995df1b87ae465a79ab9efda18@proxima.alt.za> To: 9fans@hamnavoe.com, 9fans@9fans.net Date: Fri, 27 Nov 2009 12:30:43 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] SSH server Topicbox-Message-UUID: a4150ebe-ead5-11e9-9d60-3106f5b1d025 > 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