[9fans] Hopefully, one last problem - Plan9

This is a discussion on [9fans] Hopefully, one last problem - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: [9fans] Hopefully, one last problem

  1. [9fans] Hopefully, one last problem

    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

  2. Re: [9fans] Hopefully, one last problem

    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 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

  3. Re: [9fans] Hopefully, one last problem

    > 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


  4. Re: [9fans] Hopefully, one last problem

    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 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
    >




  5. Re: [9fans] Hopefully, one last problem

    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


  6. Re: [9fans] Hopefully, one last problem

    > 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

  7. Re: [9fans] Hopefully, one last problem

    > 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


  8. Re: [9fans] Hopefully, one last problem

    > 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


  9. Re: [9fans] Hopefully, one last problem


    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


  10. Re: [9fans] Hopefully, one last problem

    > 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


  11. Re: [9fans] Hopefully, one last problem

    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

+ Reply to Thread