The last CD distribution

The last CD distribution

[岡本健二]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

Now writing from win10 machine, because I cann’t use terminhal on the
File/auth sever build from the sources of the last CDROM iso image.

The error message is like:
Mount: auth_proxy: auth_proxy rpc write: AS protocol botch
Mount: mount /root: phase error protocol phase error:
Read in state SneedTicket

Then, I re-entered password, and kill the secstored on the auth server.
The /mnt/factotum/ctl shows two lines of:
key proto=p9sk1 user=glenda dom=…..
key proto=dp9ik user=glenda dom=…

I was asked dp9ik password from the terminal, and failed by password
Missmatch.
Any suggestions?

Kenji

Windows 10 版のメールから送信


[-- Attachment #2: Type: text/html, Size: 3429 bytes --]

Re: [9front] The last CD distribution

[cinap_lenrek]

des tickets have been disabled (2016/04/08) on the auth server to prevent
password bruteforce attack with the -N flag to authsrv in /rc/bin/service.auth/tcp567.
removing that flag would make p9sk1 work again but will get you hacked.

the prefered way is to update your keydb. if your keydb is not already
in aes format (needed to store new aes keys) you have to convert it
with auth/convkeys -pa.

then you have to set new passwords.

then update the nvrams on your servers to match the new hostowner
passwords.

finally, you might update your secstore file and delete the p9sk1 key
and replace them with dp9ik keys.

--
cinap

Re: [9front] The last CD distribution

[cinap_lenrek]

i'v posted a mail to 9front mailinglist in 6th Jan 2016 describing the
procedure to update the auth infrastructure to the new aes keys and
dp9ik here:

http://felloff.net/usr/cinap_lenrek/authupdate.txt

from then on, we where in transition, that means both p9sk1 and dp9ik
where allowed in parallel by the auth server. which doesnt add any
security until p9sk1 is disabled.

on 7th Apr, des tickets where disabled because drawterm finally
got dp9ik support and there was no more reason to run vulnerable
system and new installed systems will go to use dp9ik only.

--
cinap

Re: [9front] The last CD distribution

[stanley lieber]

http://fqa.9front.org/fqa7.html#7.4.3.2

RE: [9front] The last CD distribution

[岡本健二]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

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.

When I try to login from a terminal, I got
Post…

!Adding key: dom=xxxx proto=dp9ik
User[kokamoto]: <just CR>
Password: <my password same as above>

Back to user[kokamoto] lines

Any hints?

Kenji
Windows 10 版のメールから送信

差出人: stanley lieber
送信日時: 2016年6月3日 23:49
宛先: 9front@9front.org
件名: Re: [9front] The last CD distribution

http://fqa.9front.org/fqa7.html#7.4.3.2


[-- Attachment #2: Type: text/html, Size: 4667 bytes --]

RE: [9front] The last CD distribution

[岡本健二]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

By the way, how I can know which encription method is used,
P9sk1 or dp9ik?
I doubt I’m using p9sk1, even I’ve deleted p9sk1 line from 
/mnt/factotum/ctl.

Kenji

Windows 10 版のメールから送信

差出人: 岡本健二
送信日時: 2016年6月4日 14:59
宛先: 9front@9front.org
件名: RE: [9front] The last CD distribution

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.

When I try to login from a terminal, I got
Post…

!Adding key: dom=xxxx proto=dp9ik
User[kokamoto]: <just CR>
Password: <my password same as above>

Back to user[kokamoto] lines

Any hints?

Kenji
Windows 10 版のメールから送信

差出人: stanley lieber
送信日時: 2016年6月3日 23:49
宛先: 9front@9front.org
件名: Re: [9front] The last CD distribution

http://fqa.9front.org/fqa7.html#7.4.3.2



[-- Attachment #2: Type: text/html, Size: 6253 bytes --]

RE: [9front] The last CD distribution

[cinap_lenrek]

> 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

RE: [9front] The last CD distribution

[岡本健二]

[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]


>what command did you dispatch here?
As I wrote, it’s passwd command for kokamoto

>lets break it down systematically please.
Sorry, however, if I could do it, I’ll never face this problem, I think.

>then, set new passwords with eigther auth/changeuser
or passwd.
I tried both.

>the passwd method will fail when the -N flag to authsrv
is set but there are no aes keys set for the user yet!

Yes, I think this the problem I faqcing.
When I see /mnt/keys/kokamoto, there are several files, however,
Which file sizes are all zero.

>temporarily remove the -N flag from
/rc/bin/service.auth/tcp567

I tried this.
1) remove -N frag from /rc/bin/service.auth/tcp567
2) reboot the auth/file/cpu server
3) auth/changeuser comman for kokamoto
4) of course, now I can login from a terminal, I tested.
5) Now add -N flag on tcp567 above
6) reboot the auth/file/cpu server
7) tried to login myselef from a terminal
8) the terminal says
	….
	Post…
	!Adding key: dom=xxxxx proto=dp9ik
	User[kokamoto]
9) then, I input password of myself
10) CONGRATULATIONS!
	 yes, I can login to the terminal
11) However, when I see /mnt/keys/kokamoto on the auth server
	I see several files, however the sizes are all zero yet

Yes, your advice solved my problem, although I still have ? on (11).

Thanks a lot!
I can now work on my purpose.

Kenji


[-- Attachment #2: Type: text/html, Size: 10414 bytes --]

RE: [9front] The last CD distribution

[岡本健二]

[-- Attachment #1: Type: text/plain, Size: 144 bytes --]

If the process was expected one.
We have to reboot the auth/file/cpu server whenever we add
a user onto this system.
Am I wrong?

Kenji


[-- Attachment #2: Type: text/html, Size: 6062 bytes --]

RE: [9front] The last CD distribution

[kokamoto]

Hehehe
I'm now writing this email from a plan9 terminal!

Kenji

RE: [9front] The last CD distribution

[cinap_lenrek]

> If the process was expected one.
> We have to reboot the auth/file/cpu server whenever we add
> a user onto this system.
> Am I wrong?
> Kenji

that depends.

the authserver needs to be rebooted after you converted to
aes format. or at least you'd have to kill the listener
for /rc/bin/service.auth and restart it with a new instance
of auth/keyfs in its namespace.

you might need to reboot your cpu/file server, or install the
new dp9ik key to its hostowner factotum manually by mounting
/srv/factotum and write the ctl file. a reboot can do that
given you have updated its nvram or installed the new key
in secstore.

if you already had a dp9ik key in its factotum and they
match with what the authserver has in its keydb, then no
reboot is neccesary.

the most important thing is making sure the authserver's
database has the keys for your cpu/file/auth server's
hostowners.

once you have that you can use auth/debug or try
to authenticate as these users and see if everything
works and make sure the clients and server have the
right keys in ther factotums.

if the authserver doesnt have keys for your server
and terminal it cannot work.

on the client side, you only get "key mismatch" error
when your client key doesnt match with the authserver.
the client can detect this as it will fail to decrypt
the ticket from the authserver.

if the server's key doesnt match the authservers you
get protocol botch error. this is because the server
will terminate the connection when it gets a ticket it
cannot decrypt.

--
cinap

RE: [9front] The last CD distribution

[kokamoto]

Thank you cinap, very much.
This is a clear teaching to me.
Now, I think I undestand it clearly.

Now, secstore also works for my system.

Kenji