[9fans] Hopefully, one last problem

[9fans] Hopefully, one last problem

[Kim Shrier]

I have a cpu/auth/file server configured and running.  When I
try to log in using drawterm, I see the following:

     kim@tinker.com password:
     ?you and auth server agree about password.
     ?server is confused.
     cpu: server lies got 39dd60dfe7adb072.1510726563 want  
9b3644fcb26b1a66.0: cs gave empty translation list

     goodbye

I assume I have missed something obvious but I don't seem to be
able to track it down.

Thanks for any assistance.
Kim

Re: [9fans] Hopefully, one last problem

[Federico Benavento]

yes, you didn't pay enough attention to my last mail, did you? ; )

If I'm not mistaken, the pass you entered afer you did echo fsdajl >
/dev/sdC0/ctl
doesn't match the one you entered when you did auth/changeuser


On 5/10/07, Kim Shrier <kim@tinker.com> wrote:
> I have a cpu/auth/file server configured and running.  When I
> try to log in using drawterm, I see the following:
>
>      kim@tinker.com password:
>      ?you and auth server agree about password.
>      ?server is confused.
>      cpu: server lies got 39dd60dfe7adb072.1510726563 want
> 9b3644fcb26b1a66.0: cs gave empty translation list
>
>      goodbye
>
> I assume I have missed something obvious but I don't seem to be
> able to track it down.
>
> Thanks for any assistance.
> Kim
>


-- 
Federico G. Benavento

Re: [9fans] Hopefully, one last problem

[Kim Shrier]

On May 10, 2007, at 9:57 AM, Federico Benavento wrote:

> yes, you didn't pay enough attention to my last mail, did you? ; )
>

Well, I thought I did but the evidence is against me.

> If I'm not mistaken, the pass you entered afer you did echo fsdajl >
> /dev/sdC0/ctl
> doesn't match the one you entered when you did auth/changeuser
>
>

Actually, do you mean echo fsdajl > /dev/sdC0/nvram ?

Here is what I typed in:

     term% echo blahblahblah >/dev/sdC0/nvram
     term% fshalt
        ...
        boot with 9pccpuf kernel
        ...
     root is from (tcp, il, local)[local!#S/sdC0/fossil]: hit enter
     bad nvram key
     bad authentication id
     bad authentication domain
     authid: bootes
     authdom: tinker.com
     secstore key: password_number_one
     password: password_number_two
     time...
     venti...fossil(#S/sdC0/fossil)...version...time...

     init: starting /bin/rc
     vh# auth/changeuser bootes
     Password: password_number_two
     Confirm password: password_number_two
     assign Inferno/POP secret? (y/n) n
     Expiration date (YYYYMMDD or never)[return = never]: hit enter
     Post id: hit enter
     User's full name: bootes on vh
     Department #: hit enter
     User's email address: hit enter
     Sponsor's email address: hit enter
     changeuser: can't open /adm/keys.who
     vh#

I believe someone told me that the error message from changeuser
was not important.  Sometime after I did this, I added bootes to
both the sys and adm groups.  It is possible that I fat-fingered
password_number_two so I will go through this again the next time
I go down to the machine room.

Kim

> On 5/10/07, Kim Shrier <kim@tinker.com> wrote:
>> I have a cpu/auth/file server configured and running.  When I
>> try to log in using drawterm, I see the following:
>>
>>      kim@tinker.com password:
>>      ?you and auth server agree about password.
>>      ?server is confused.
>>      cpu: server lies got 39dd60dfe7adb072.1510726563 want
>> 9b3644fcb26b1a66.0: cs gave empty translation list
>>
>>      goodbye
>>
>> I assume I have missed something obvious but I don't seem to be
>> able to track it down.
>>
>> Thanks for any assistance.
>> Kim
>>
>
>
> -- 
> Federico G. Benavento
>

Re: [9fans] Hopefully, one last problem

[Russ Cox]

> I believe someone told me that the error message from changeuser
> was not important.  Sometime after I did this, I added bootes to
> both the sys and adm groups.  It is possible that I fat-fingered
> password_number_two so I will go through this again the next time
> I go down to the machine room.

It is correct that
>      changeuser: can't open /adm/keys.who
is unimportant.

You should be able to run auth/wrkey on the console
instead of echoing garbage into /dev/sdC0/nvram.
Either way you do need to reboot in order to restart
the machine's factotum.

Russ

Re: [9fans] Hopefully, one last problem

[Kim Shrier]

On May 10, 2007, at 2:12 PM, Russ Cox wrote:
>
> It is correct that
>>      changeuser: can't open /adm/keys.who
> is unimportant.
>
> You should be able to run auth/wrkey on the console
> instead of echoing garbage into /dev/sdC0/nvram.
> Either way you do need to reboot in order to restart
> the machine's factotum.
>
> Russ

OK, that was not the problem.  I have done auth/wrkey
twice and taken care not to mistype the password and the
secstore key.  I have rebooted more times than I can count.
I have run auth/changeuser bootes and auth/changeuser kim
and made sure that I keyed the passwords in correctly.  I
have rebooted some more.  I still have the same problem.

I suspicion that the problem is somewhere else.

What components are involved in handling this remote login?

Do they log anything?

Can I make them log more?

Which piece of software is issuing the message:

     cpu: server lies got 39dd60dfe7adb072.1510726563 want  
9b3644fcb26b1a66.0: cs gave empty translation list


I would actually like to track this down myself but I seem
to keep hitting brick walls.

Kim

Re: [9fans] Hopefully, one last problem

[Russ Cox]

> OK, that was not the problem.  I have done auth/wrkey
> twice and taken care not to mistype the password and the
> secstore key.  I have rebooted more times than I can count.
> I have run auth/changeuser bootes and auth/changeuser kim
> and made sure that I keyed the passwords in correctly.  I
> have rebooted some more.  I still have the same problem.
> 
> I suspicion that the problem is somewhere else.
> 
> What components are involved in handling this remote login?
> 
> Do they log anything?
> 
> Can I make them log more?
> 
> Which piece of software is issuing the message:
> 
>      cpu: server lies got 39dd60dfe7adb072.1510726563 want  
> 9b3644fcb26b1a66.0: cs gave empty translation list
> 
> I would actually like to track this down myself but I seem
> to keep hitting brick walls.

* Logs

The auth server logs to /sys/log/auth.
You can make the cpu server factotum log by
	echo debug >/mnt/factotum/ctl
	cat /mnt/factotum/log

* Things to try

On the cpu server, run auth/debug.

Try to authenticate as bootes instead
of as kim using drawterm.

On the cpu server, in a new window, run

	auth/factotum
	cpu -h cpu-server-name

and try to log in as kim.
Do the same as bootes.

Try auth/wrkey and 
type the bootes password as the secstore key too.
(I wonder if some program is reading the wrong field.)

* What's going on

Drawterm is printing the message "server lies".
It turns out that code is not quite right, but it's close
enough for the moment.  The auth protocol is 
p9any+p9sk1, described in authsrv(6).  

Drawterm connects to the auth server, gets a ticket
pair, one encrypted with kim's password and one 
with bootes's password.  The tickets are slightly 
different but they both contain the same random
key that will be the shared secret between drawterm
and the cpu server once the protocol finishes.

Drawterm decrypts the one encrypted with kim's password
to get the shared key.  It sends the bootes-encrypted
ticket to the cpu server along with a random challenge string.
The cpu server is supposed to decrypt the bootes-encrypted
ticket, get the shared secret, and then use it to encrypt
the challenge string and send it back to drawterm.
When this works, drawterm now knows that the remote 
side knows the shared secret.  The encrypted secret that
drawterm gets back does not decrypt properly, hence
the "server lies".  (If it had been okay, then drawterm
would have encrypted a random challenge from the server
to prove that it knew the key too, and then we'd be done.)

But the fact that the protocol got as far as it did
means that drawterm was able to decrypt the kim-encrypted
ticket that the auth server created.  So drawterm and the
auth server agree about kim's password.  But the cpu 
server was unable to decrypt the bootes-encrypted ticket,
meaning that the auth server and the cpu factotum disagree
about bootes's password.

(In fact the cpu server recognized that it couldn't
decrypt the ticket and gave up before sending the
challenge response, instead printing an error message.
But drawterm interprets the error message as the
response and sure enough it doesn't decrypt well.
That's a separate problem.  Seeing the error message
wouldn't really help.  It would be
	cpu: srvauth: protocol failure
which doesn't shed any additional light.)

If you drawterm in as bootes instead of as kim, then
seeing how far this process gets will check whether
the auth server agrees with the password you typed
in for bootes.

Russ

Re: [9fans] Hopefully, one last problem

[Kim Shrier]

I have fixed the problem with logging in from a drawterm to my
cpu/auth/file server.  Based on a suggestion by Russ Cox, I
changed the bootes password.  I first set the bootes password
and secstore key to the same value.  I was still unable to log
in as kim and when I tried to log in as bootes, it complained
that I had typed in an incorrect password.  After staring at
the notes I had taken during the initial installation, I saw
that the first time a ran auth/keyfs, I got the following
output:

     term% auth/keyfs
     bad nvram key
     bad authentication id
     bad authentication domain
     can't read /dev/key, please enter machine key
     Password: some_long_password
     Confirm password: some_long_password
     term%

This password was different than the one I was originally
using for bootes's secstore key and password.  I have now
set the secstore key and the password to some_long_password.

After rebooting the cpu/auth/file server, I can log in both
as bootes and as kim from a drawterm.  I am going to leave
things alone with regard to configuration until I get a
little more familiar with Plan 9.

I really appreciate all the help I received from this list.

Kim

Re: [9fans] Hopefully, one last problem

[erik quanstrom]

> Actually, do you mean echo fsdajl > /dev/sdC0/nvram ?
> 
> Here is what I typed in:
> 
>      term% echo blahblahblah >/dev/sdC0/nvram
>      term% fshalt

even better:
	dd -if /dev/zero -of /dev/sdC0/nvram -count 1

>         ...
>         boot with 9pccpuf kernel
>         ...
>      root is from (tcp, il, local)[local!#S/sdC0/fossil]: hit enter
>      bad nvram key
>      bad authentication id
>      bad authentication domain
>      authid: bootes
>      authdom: tinker.com
>      secstore key: password_number_one
>      password: password_number_two
>      time...
>      venti...fossil(#S/sdC0/fossil)...version...time...
> 
>      init: starting /bin/rc
>      vh# auth/changeuser bootes
>      Password: password_number_two

this should be password_number_one

the secstore server is something else.  man secuser for its usage.

>      changeuser: can't open /adm/keys.who

odd.  this is part of the distribution.  

	touch /adm/keys.who

- erik

Re: [9fans] Hopefully, one last problem

[Russ Cox]

> even better:
> 	dd -if /dev/zero -of /dev/sdC0/nvram -count 1

This does not matter.  All you have to do is
invalidate the checksum and the boot process
will prompt you.  Or you can run auth/wrkey 
to get prompted later (and then reboot).
Whether you echo blah blah blah >nvram
or use dd into nvram or cat /dev/zero > nvram
or auth/wrkey doesn't matter any more than
whether you type sync one, two, or three times
before halting your file systems.

>>         ...
>>         boot with 9pccpuf kernel
>>         ...
>>      root is from (tcp, il, local)[local!#S/sdC0/fossil]: hit enter
>>      bad nvram key
>>      bad authentication id
>>      bad authentication domain
>>      authid: bootes
>>      authdom: tinker.com
>>      secstore key: password_number_one
>>      password: password_number_two
>>      time...
>>      venti...fossil(#S/sdC0/fossil)...version...time...
>> 
>>      init: starting /bin/rc
>>      vh# auth/changeuser bootes
>>      Password: password_number_two
> 
> this should be password_number_one

It is correct as password_number_two.

Let's assume secstore is not in the picture (since it
hasn't been mentioned until now).  Then you can type
anything you want at the secstore key: prompt and
it won't matter.  But what you type at the two
other password: prompts needs to be the same
(and they are, in the original post: password_number_two).

> the secstore server is something else.  man secuser for its usage.
> 
>>      changeuser: can't open /adm/keys.who
> 
> odd.  this is part of the distribution.  
> 
> 	touch /adm/keys.who

The problem here (again irrelevant) is likely
to be permissions, not that the file is missing.

Russ

Re: [9fans] Hopefully, one last problem

[Russ Cox]

> I have a cpu/auth/file server configured and running.  When I
> try to log in using drawterm, I see the following:
> 
>      kim@tinker.com password:
>      ?you and auth server agree about password.
>      ?server is confused.
>      cpu: server lies got 39dd60dfe7adb072.1510726563 want  
> 9b3644fcb26b1a66.0: cs gave empty translation list
> 
>      goodbye
> 
> I assume I have missed something obvious but I don't seem to be
> able to track it down.

You need to fix the key held in your
server's factotum, which does not match
the one in /mnt/keys and the one you typed to drawterm.
(The last two *do* match.)

Try running auth/wrkey on the console to
reset the nvram password.

Russ

Re: [9fans] Hopefully, one last problem

[Kim Shrier]

On May 10, 2007, at 9:58 AM, Russ Cox wrote:

>> I have a cpu/auth/file server configured and running.  When I
>> try to log in using drawterm, I see the following:
>>
>>      kim@tinker.com password:
>>      ?you and auth server agree about password.
>>      ?server is confused.
>>      cpu: server lies got 39dd60dfe7adb072.1510726563 want
>> 9b3644fcb26b1a66.0: cs gave empty translation list
>>
>>      goodbye
>>
>> I assume I have missed something obvious but I don't seem to be
>> able to track it down.
>
> You need to fix the key held in your
> server's factotum, which does not match
> the one in /mnt/keys and the one you typed to drawterm.
> (The last two *do* match.)
>
> Try running auth/wrkey on the console to
> reset the nvram password.
>
> Russ

Thanks.  I'll try this the next time I am in the machine room.

Kim