* [9fans] auth on terminal
@ 2004-03-25 13:36 plan9fans
2004-03-25 13:43 ` Fco.J.Ballesteros
2004-03-25 14:00 ` Richard Miller
0 siblings, 2 replies; 13+ messages in thread
From: plan9fans @ 2004-03-25 13:36 UTC (permalink / raw)
To: 9fans
Hi,
Firstoff, sorry for dumb question.
I'am trying connect two stand alone terminals together,
larch and paris; paris is also going to act as authserver.
On paris I start the auth server by hand
auth/keyfs -m /mnt/keys /adm/keys
aux/listen -q -t $home/bin/service.auth -d $home/bin/aservice
setup my auth info (only once)
auth/wrkeys
auth/changeuser steve
Add keys to factotum for both machines.
key proto=p9sk1 dom=mydom.net user=steve !password=xxxx
Now if I run auth/debug on either machine and everything looks OK.
When I try to do
larch% cpu -h paris
the command doesn't return. When I hit return on paris it prints
password:
"behind rio" there is obviously two processes reading the keyboard,
rio, and this program running behind it (keyfs ?)
if I hit return a few more times larch prints
no key
rio: can't find mouse: device or object already in use
Unfortuanately this process on paris keeps reading the keyboard and
eating every other character or so I have to reboot it in the end.
I think I am nearly there but I don't know what I have missed.
Anyone?
-Steve
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] auth on terminal
2004-03-25 13:36 [9fans] auth on terminal plan9fans
@ 2004-03-25 13:43 ` Fco.J.Ballesteros
2004-03-25 13:55 ` David Presotto
2004-03-25 14:00 ` Richard Miller
1 sibling, 1 reply; 13+ messages in thread
From: Fco.J.Ballesteros @ 2004-03-25 13:43 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 120 bytes --]
Why don't you start one of them as a cpuserver?
You may start rio on it and run it on the
name of a user, of course.
[-- Attachment #2: Type: message/rfc822, Size: 3055 bytes --]
From: plan9fans@ntlworld.nospam.com
To: 9fans@cse.psu.edu
Subject: [9fans] auth on terminal
Date: Thu, 25 Mar 2004 13:36:04 0000
Message-ID: <bda459f6a02d0421aa4858fd71610770@snellwilcox.com>
Hi,
Firstoff, sorry for dumb question.
I'am trying connect two stand alone terminals together,
larch and paris; paris is also going to act as authserver.
On paris I start the auth server by hand
auth/keyfs -m /mnt/keys /adm/keys
aux/listen -q -t $home/bin/service.auth -d $home/bin/aservice
setup my auth info (only once)
auth/wrkeys
auth/changeuser steve
Add keys to factotum for both machines.
key proto=p9sk1 dom=mydom.net user=steve !password=xxxx
Now if I run auth/debug on either machine and everything looks OK.
When I try to do
larch% cpu -h paris
the command doesn't return. When I hit return on paris it prints
password:
"behind rio" there is obviously two processes reading the keyboard,
rio, and this program running behind it (keyfs ?)
if I hit return a few more times larch prints
no key
rio: can't find mouse: device or object already in use
Unfortuanately this process on paris keeps reading the keyboard and
eating every other character or so I have to reboot it in the end.
I think I am nearly there but I don't know what I have missed.
Anyone?
-Steve
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] auth on terminal
2004-03-25 13:43 ` Fco.J.Ballesteros
@ 2004-03-25 13:55 ` David Presotto
2004-03-25 14:51 ` Steve Simon
0 siblings, 1 reply; 13+ messages in thread
From: David Presotto @ 2004-03-25 13:55 UTC (permalink / raw)
To: 9fans
If you are running as the same user on both systems, you don't even need
an auth server...
Keyfs will get the password it encrypts/decrypts the /adm/keys with from
the nvram parittion if there's anything there (i.e. if you've already
run wrkeys and put something there). Otherwise, it will indeed prompt
with password:. Did you start it in the background?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] auth on terminal
2004-03-25 13:55 ` David Presotto
@ 2004-03-25 14:51 ` Steve Simon
2004-03-25 15:31 ` Richard Miller
0 siblings, 1 reply; 13+ messages in thread
From: Steve Simon @ 2004-03-25 14:51 UTC (permalink / raw)
To: 9fans
> If you are running as the same user on both systems, you don't even need
> an auth server...
>
> Keyfs will get the password it encrypts/decrypts the /adm/keys with from
> the nvram parittion if there's anything there (i.e. if you've already
> run wrkeys and put something there). Otherwise, it will indeed prompt
> with password:. Did you start it in the background?
I didn't start keyfs in the background, however Richards suggestion
of using
service=cpu auth/keyfs ...
stopped the prompts for a password; I guess keyfs changes it behaviour
depending.
Perhaps I am beginning to understand, Is it that keyfs is only
needed to change ones identity?
Ok, I scapped keyfs, now I just use aux/listen on the server side.
larch% cpu -h paris
!Adding key: proto=p9sk1 dom=mydom.net
user[steve]:
password:
!
!Adding key: proto=p9sk1 dom=mydom.net
user[steve]:
password:
!
[ad nausem]
However I do have a key, and the factotums are the same
(the contents transfered securely via Neware :-)
larch% grep mydom /mnt/factotum/ctl
key proto=p9sk1 dom=mydom.net user=steve !password?
paris% grep mydom /mnt/factotum/ctl
key proto=p9sk1 dom=mydom.net user=steve !password?
only one small step now ...
-Steve
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] auth on terminal
2004-03-25 14:51 ` Steve Simon
@ 2004-03-25 15:31 ` Richard Miller
0 siblings, 0 replies; 13+ messages in thread
From: Richard Miller @ 2004-03-25 15:31 UTC (permalink / raw)
To: 9fans
> I didn't start keyfs in the background, however Richards suggestion
> of using
> service=cpu auth/keyfs ...
That's not what I suggested. It's the aux/listen which needs service=cpu,
so that rc knows it's on a "cpu server" when running $home/lib/profile.
> Ok, I scapped keyfs, now I just use aux/listen on the server side.
Not a good idea: if aux/listen is still starting authsrv, it needs a keyfs.
That's why the client keeps prompting for a password.
-- Richard
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] auth on terminal
2004-03-25 13:36 [9fans] auth on terminal plan9fans
2004-03-25 13:43 ` Fco.J.Ballesteros
@ 2004-03-25 14:00 ` Richard Miller
1 sibling, 0 replies; 13+ messages in thread
From: Richard Miller @ 2004-03-25 14:00 UTC (permalink / raw)
To: 9fans
> aux/listen -q -t $home/bin/service.auth -d $home/bin/aservice
Try changing this to
service=cpu aux/listen -q -t $home/bin/service.auth -d $home/bin/aservice
-- Richard
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [9fans] auth on terminal
@ 2004-03-25 15:00 Tiit Lankots
2004-03-25 15:09 ` andrey mirtchovski
2004-03-25 15:10 ` andrey mirtchovski
0 siblings, 2 replies; 13+ messages in thread
From: Tiit Lankots @ 2004-03-25 15:00 UTC (permalink / raw)
To: 9fans
> However I do have a key, and the factotums are the same
> (the contents transfered securely via Neware :-)
If you're not running secstored(8), then your factotums are nonpersistent.
Factotum(4) looks for a secstore on startup; if it's not found at
tcp!$auth!5356 it gives up and does not use it even if later you start one.
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [9fans] auth on terminal
@ 2004-03-25 15:09 Tiit Lankots
0 siblings, 0 replies; 13+ messages in thread
From: Tiit Lankots @ 2004-03-25 15:09 UTC (permalink / raw)
To: 9fans
> larch% cpu -h paris
>
> !Adding key: proto=p9sk1 dom=mydom.net
> user[steve]:
> password:
> !
The fact that you see this implies that the local factotum does not
have a key for what the remote requests. I think it works this way:
A full-blown auth server runs factotum -S on startup; it (factotum) reads
authentication data (which contains the auth domain, among other things)
from nvram and initialises some important data to use this info.
So I guess, nvram setup + factotum -S should solve your problems.
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [9fans] auth on terminal
@ 2004-03-25 15:14 Tiit Lankots
0 siblings, 0 replies; 13+ messages in thread
From: Tiit Lankots @ 2004-03-25 15:14 UTC (permalink / raw)
To: 9fans
> oh, i forgot the standard addition -- auth/debug is your friend :)
running a terminal as an auth server is a good excercise in what
makes an auth server special ;)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [9fans] auth on terminal
@ 2004-03-25 15:45 plan9fans
0 siblings, 0 replies; 13+ messages in thread
From: plan9fans @ 2004-03-25 15:45 UTC (permalink / raw)
To: 9fans
Thanks for the help guys but I'am still not there.
>...then your factotums are nonpersistent.
My factotum's state is sort-of persistant as I run
auth/aescbc -d < /n/cdrom/secrets | read -m > /mnt/factotum/ctl
in my profile to populate it.
> ...keyfs and authsrv in the same namespace,
During my attempts to run auth/keyfs it was in the same namespace
as aux/listen, they where started on the command line in a Rio window.
>...nvram setup + factotum -S should solve your problems.
If I run factotum -S and populate it then I guess it would stop
the password prompts from behind rio (I have not tried, see below).
> ..-- auth/debug is your friend
If I don't run the authserver then auth/debug says I have a problem,
however if I do run the auth server it is happy, on bowth systems.
However I now think I don't need an auth server as all I want
is a direct connection between two machines, both running as me.
I tried turning on factotums debug but the issue wasn't "obvious"
Again I did:
cpu -h paris
!Adding key: proto=p9sk1 dom=quintile.net
user[steve]:
!Adding key: proto=p9sk1 dom=quintile.net
user[steve]:
...
Factotum debug from larch
287: start proto=p9any role=client yields phase CNeedProtos: ok
287: read 4093 in phase CNeedProtos yields phase CNeedProtos: phase: protocol phase error: read in state CNeedProtos
287: write 0 in phase CNeedProtos yields phase CNeedProtos: toosmall 2048
287: start proto=p9sk1 role=client dom=mydom.net yields phase CHaveChal: ok
287: write 78 in phase CNeedProtos yields phase CHaveProto: ok
287: read 19 in phase CHaveProto yields phase CRelay: ok
287: read 8 in phase CHaveChal yields phase CNeedTreq: ok
287: read 8 in phase CRelay yields phase CRelay: ok
287: read 4093 in phase CNeedTreq yields phase CNeedTreq: phase: protocol phase error: read in state CNeedTreq
287: read 4093 in phase CRelay yields phase CRelay: phase: protocol phase error: read in state CNeedTreq
287: write 0 in phase CNeedTreq yields phase CNeedTreq: toosmall 141
287: write 0 in phase CRelay yields phase CRelay: toosmall 141
287: write 141 in phase CNeedTreq yields phase CNeedTreq: needkey proto=p9sk1 dom=mydom.net user? !password?
287: write 141 in phase CRelay yields phase CRelay: needkey proto=p9sk1 dom=mydom.net user? !password?
Factotum debug from paris
8: start proto=p9any role=server yields phase SHaveProtos: ok
8: no key matches proto=p9sk1 role=server dom?
8: read 78 in phase SHaveProtos yields phase SNeedProto: ok
8: read 4093 in phase SNeedProto yields phase SNeedProto: phase: protocol phase error: read in state SNeedProto
8: write 0 in phase SNeedProto yields phase SNeedProto: toosmall 1
8: write 1 in phase SNeedProto yields phase SNeedProto: toosmall 2
8: write 2 in phase SNeedProto yields phase SNeedProto: toosmall 3
8: write 3 in phase SNeedProto yields phase SNeedProto: toosmall 4
8: write 4 in phase SNeedProto yields phase SNeedProto: toosmall 5
8: write 5 in phase SNeedProto yields phase SNeedProto: toosmall 6
8: write 6 in phase SNeedProto yields phase SNeedProto: toosmall 7
8: write 7 in phase SNeedProto yields phase SNeedProto: toosmall 8
8: write 8 in phase SNeedProto yields phase SNeedProto: toosmall 9
8: write 9 in phase SNeedProto yields phase SNeedProto: toosmall 10
8: write 10 in phase SNeedProto yields phase SNeedProto: toosmall 11
8: write 11 in phase SNeedProto yields phase SNeedProto: toosmall 12
8: write 12 in phase SNeedProto yields phase SNeedProto: toosmall 13
8: write 13 in phase SNeedProto yields phase SNeedProto: toosmall 14
8: write 14 in phase SNeedProto yields phase SNeedProto: toosmall 15
8: write 15 in phase SNeedProto yields phase SNeedProto: toosmall 16
8: write 16 in phase SNeedProto yields phase SNeedProto: toosmall 17
8: write 17 in phase SNeedProto yields phase SNeedProto: toosmall 18
8: write 18 in phase SNeedProto yields phase SNeedProto: toosmall 19
8: write 19 in phase SNeedProto yields phase SRelay: ok
8: read 4093 in phase SNeedChal yields phase SNeedChal: phase: protocol phase error: read in state SNeedChal
8: read 4093 in phase SRelay yields phase SRelay: phase: protocol phase error: read in state SNeedChal
8: write 0 in phase SNeedChal yields phase SNeedChal: toosmall 8
8: write 0 in phase SRelay yields phase SRelay: toosmall 8
8: write 8 in phase SNeedChal yields phase SHaveTreq: ok
8: write 8 in phase SRelay yields phase SRelay: ok
8: read 141 in phase SHaveTreq yields phase SNeedTicket: ok
8: read 141 in phase SRelay yields phase SRelay: ok
8: read 4093 in phase SNeedTicket yields phase SNeedTicket: phase: protocol phase error: read in state SNeedTicket
8: read 4093 in phase SRelay yields phase SRelay: phase: protocol phase error: read in state SNeedTicket
8: write 0 in phase SNeedTicket yields phase SNeedTicket: toosmall 85
8: write 0 in phase SRelay yields phase SRelay: toosmall 85
-Steve
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [9fans] auth on terminal
@ 2004-03-25 16:16 Tiit Lankots
0 siblings, 0 replies; 13+ messages in thread
From: Tiit Lankots @ 2004-03-25 16:16 UTC (permalink / raw)
To: 9fans
> -----Original Message-----
> From: 9fans-admin@cse.psu.edu
> [mailto:9fans-admin@cse.psu.edu]On Behalf Of
> plan9fans@ntlworld.nospam.com
> Sent: Thursday, March 25, 2004 5:45 PM
> To: 9fans@cse.psu.edu
> Subject: [9fans] auth on terminal
>
>
> Thanks for the help guys but I'am still not there.
>
> >...then your factotums are nonpersistent.
> My factotum's state is sort-of persistant as I run
> auth/aescbc -d < /n/cdrom/secrets | read -m > /mnt/factotum/ctl
> in my profile to populate it.
>
> > ...keyfs and authsrv in the same namespace,
> During my attempts to run auth/keyfs it was in the same namespace
> as aux/listen, they where started on the command line in a Rio window.
>
> >...nvram setup + factotum -S should solve your problems.
> If I run factotum -S and populate it then I guess it would stop
> the password prompts from behind rio (I have not tried, see below).
>
> > ..-- auth/debug is your friend
> If I don't run the authserver then auth/debug says I have a problem,
> however if I do run the auth server it is happy, on bowth systems.
>
> However I now think I don't need an auth server as all I want
> is a direct connection between two machines, both running as me.
>
> I tried turning on factotums debug but the issue wasn't "obvious"
> Again I did:
>
> cpu -h paris
> !Adding key: proto=p9sk1 dom=quintile.net
> user[steve]:
> !Adding key: proto=p9sk1 dom=quintile.net
> user[steve]:
> ...
>
> Factotum debug from larch
>
Whaddayaknow, man pages + source can be really informative :)
It turns out that factotum is not used on the auth server at all.
Authsrv uses keyfs to get to it's auth data.
Keyfs database (/adm/keys) is encrypted with the server's key,
stored in nvram.
So you'll need to
1. auth/wrkey (if you don't want to type a password each startup), or
2. run auth/keyfs -p in termrc (this prompts for password)
The 'Configuring a Standalone CPU Server' page in Wiki gives a
decent rundown.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2004-03-25 16:16 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-25 13:36 [9fans] auth on terminal plan9fans
2004-03-25 13:43 ` Fco.J.Ballesteros
2004-03-25 13:55 ` David Presotto
2004-03-25 14:51 ` Steve Simon
2004-03-25 15:31 ` Richard Miller
2004-03-25 14:00 ` Richard Miller
2004-03-25 15:00 Tiit Lankots
2004-03-25 15:09 ` andrey mirtchovski
2004-03-25 15:10 ` andrey mirtchovski
2004-03-25 15:09 Tiit Lankots
2004-03-25 15:14 Tiit Lankots
2004-03-25 15:45 plan9fans
2004-03-25 16:16 Tiit Lankots
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).