From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from duke.felloff.net ([216.126.196.34]) by ur; Sat Jun  4 10:13:51 EDT 2016
Message-ID: <262cd60a53bcb365c275b3153c090ba8@felloff.net>
Date: Sat, 4 Jun 2016 16:13:43 +0200
From: cinap_lenrek@felloff.net
To: 9front@9front.org
Subject: RE: [9front] The last CD distribution
In-Reply-To: <201606040559.u545xkD6026946@mailmsa12.mozu.eo.k-opti.ad.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: abstract webscale enhancement-based JSON over YAML realtime STM-scale engine method 

> Yes, I`ve read that document, but still fails.
> When I dispatched the command on my pc64 auth server(=file/cpu server) of
> passwd like:
> titan: passwd kokamoto
> then I got
> Plan9 password: <password input>
> Passwd: AS protocol botch.

what command did you dispatch here?

lets break it down systematically please.

authentication with p9sk1 or dp9ik have 3 parties involved:

- the client
- the server
- the AS (authentication server)

the server has its hostowner key, which is derived from
hostowner user name and the password. it is loaded into
factotum from nvram on boot or secstore or manually entered
when it boots.

the client is the same, it has its own hostowner user
and password but usually dosnt prompt for it on boot.
when you need to authenticate, factotum will prompt for
username and password if it doesnt have the key already.

the client doesnt need to know the servers key, and
the server doesnt need to know the clients key.

the authentication server needs to have the keys for
both client and server in its keydb.

nothing has changed between p9sk1 and dp9ik in that
regard. what changed is that dp9ik uses new 128 bit
aes key instead of 56 bit des key.

nvram and keydb can store both keys at the same time.

keydb however needs to be converted to aes format to
be able to store the new keys. auth/convkeys will just
change the format, but will not set valid aes keys for
the users.

so the first step is to convert keydb on the auth server
to the aes format.

if your auth server uses nvram to decrypt the keydb, you
should also use auth/wrkey so it will be able to decrypt
the new keydb after reboot.

keyfs needs to be restarted after converstion... reboot
the AS.

then, set new passwords with eigther auth/changeuser
or passwd.

the passwd method will fail when the -N flag to authsrv
is set but there are no aes keys set for the user yet!
maybe this is causing the trouble. in that case, you can
use auth/changeuser on the authserver directly with /mnt/keys
in your namespace or temporarily remove the -N flag from
/rc/bin/service.auth/tcp567

once the authserver has both keys for the client and the
server, you can attempt updating nvrams and secstores of
your file and cpu servers and terminals.

--
cinap