* [9fans] Hopefully, one last problem @ 2007-05-10 15:53 Kim Shrier 2007-05-10 15:57 ` Federico Benavento 2007-05-10 15:58 ` Russ Cox 0 siblings, 2 replies; 11+ messages in thread From: Kim Shrier @ 2007-05-10 15:53 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Hopefully, one last problem 2007-05-10 15:53 [9fans] Hopefully, one last problem Kim Shrier @ 2007-05-10 15:57 ` Federico Benavento 2007-05-10 18:04 ` Kim Shrier 2007-05-10 15:58 ` Russ Cox 1 sibling, 1 reply; 11+ messages in thread From: Federico Benavento @ 2007-05-10 15:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Hopefully, one last problem 2007-05-10 15:57 ` Federico Benavento @ 2007-05-10 18:04 ` Kim Shrier 2007-05-10 20:12 ` Russ Cox 2007-05-10 20:23 ` erik quanstrom 0 siblings, 2 replies; 11+ messages in thread From: Kim Shrier @ 2007-05-10 18:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Hopefully, one last problem 2007-05-10 18:04 ` Kim Shrier @ 2007-05-10 20:12 ` Russ Cox 2007-05-11 2:05 ` Kim Shrier 2007-05-10 20:23 ` erik quanstrom 1 sibling, 1 reply; 11+ messages in thread From: Russ Cox @ 2007-05-10 20:12 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Hopefully, one last problem 2007-05-10 20:12 ` Russ Cox @ 2007-05-11 2:05 ` Kim Shrier 2007-05-11 11:58 ` Russ Cox 0 siblings, 1 reply; 11+ messages in thread From: Kim Shrier @ 2007-05-11 2:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Hopefully, one last problem 2007-05-11 2:05 ` Kim Shrier @ 2007-05-11 11:58 ` Russ Cox 2007-05-12 23:28 ` Kim Shrier 0 siblings, 1 reply; 11+ messages in thread From: Russ Cox @ 2007-05-11 11:58 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Hopefully, one last problem 2007-05-11 11:58 ` Russ Cox @ 2007-05-12 23:28 ` Kim Shrier 0 siblings, 0 replies; 11+ messages in thread From: Kim Shrier @ 2007-05-12 23:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Hopefully, one last problem 2007-05-10 18:04 ` Kim Shrier 2007-05-10 20:12 ` Russ Cox @ 2007-05-10 20:23 ` erik quanstrom 2007-05-10 21:04 ` Russ Cox 1 sibling, 1 reply; 11+ messages in thread From: erik quanstrom @ 2007-05-10 20:23 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Hopefully, one last problem 2007-05-10 20:23 ` erik quanstrom @ 2007-05-10 21:04 ` Russ Cox 0 siblings, 0 replies; 11+ messages in thread From: Russ Cox @ 2007-05-10 21:04 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Hopefully, one last problem 2007-05-10 15:53 [9fans] Hopefully, one last problem Kim Shrier 2007-05-10 15:57 ` Federico Benavento @ 2007-05-10 15:58 ` Russ Cox 2007-05-10 18:04 ` Kim Shrier 1 sibling, 1 reply; 11+ messages in thread From: Russ Cox @ 2007-05-10 15:58 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Hopefully, one last problem 2007-05-10 15:58 ` Russ Cox @ 2007-05-10 18:04 ` Kim Shrier 0 siblings, 0 replies; 11+ messages in thread From: Kim Shrier @ 2007-05-10 18:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2007-05-12 23:28 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-05-10 15:53 [9fans] Hopefully, one last problem Kim Shrier 2007-05-10 15:57 ` Federico Benavento 2007-05-10 18:04 ` Kim Shrier 2007-05-10 20:12 ` Russ Cox 2007-05-11 2:05 ` Kim Shrier 2007-05-11 11:58 ` Russ Cox 2007-05-12 23:28 ` Kim Shrier 2007-05-10 20:23 ` erik quanstrom 2007-05-10 21:04 ` Russ Cox 2007-05-10 15:58 ` Russ Cox 2007-05-10 18:04 ` Kim Shrier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).