Re: [9fans] Hopefully, one last problem

["Russ Cox" <rsc@swtch.com>]

> 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