RE: [9fans] auth on terminal

RE: [9fans] auth on terminal

[Tiit Lankots]

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

[9fans] auth on terminal

[plan9fans]

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

RE: [9fans] auth on terminal

[Tiit Lankots]

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

RE: [9fans] auth on terminal

[Tiit Lankots]

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

RE: [9fans] auth on terminal

[Tiit Lankots]

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

RE: [9fans] auth on terminal

[andrey mirtchovski]

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

in his case he needs to run keyfs and authsrv in the same namespace,
looking at /sys/log/auth would probably tell you that there's nothing
in /mnt/keys

RE: [9fans] auth on terminal

[andrey mirtchovski]

oh, i forgot the standard addition -- auth/debug is your friend :)

[9fans] auth on terminal

[plan9fans]

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

Re: [9fans] auth on terminal

[Fco.J.Ballesteros]

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

Re: [9fans] auth on terminal

[David Presotto]

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?

Re: [9fans] auth on terminal

[Steve Simon]

> 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

Re: [9fans] auth on terminal

[Richard Miller]

> 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

Re: [9fans] auth on terminal

[Richard Miller]

> 	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