[9fans] login problems

[9fans] login problems

[John Floren]

Hi everyone.
I've just set up a cpu/auth/file server here at home; I think I've
done it right (followed the directions on the wiki). However, when I
try to use drawterm, I can connect fine as "bootes", but when trying
to connect as a new user (just added), I get this message after typing
the password:

cpu: cannot get auth tickets in p9sk1: Connection refused
goodbye

Have I forgotten to configure something?
Thanks

John
-- 
"The first thing we do, let's kill all the lawyers" -- Shakespeare, Henry VI

Re: [9fans] login problems

[Rodolfo (kix)]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

Ummm,

you have the auth server running?  try to find it with ps.

you used the newuser script, with the new user?

slds.



2006/8/12, John Floren <slawmaster@gmail.com>:
>
> Hi everyone.
> I've just set up a cpu/auth/file server here at home; I think I've
> done it right (followed the directions on the wiki). However, when I
> try to use drawterm, I can connect fine as "bootes", but when trying
> to connect as a new user (just added), I get this message after typing
> the password:
>
> cpu: cannot get auth tickets in p9sk1: Connection refused
> goodbye
>
> Have I forgotten to configure something?
> Thanks
>
> John
> --
> "The first thing we do, let's kill all the lawyers" -- Shakespeare, Henry
> VI
>



-- 
Rodolfo García "kix"

[-- Attachment #2: Type: text/html, Size: 1084 bytes --]

Re: [9fans] login problems

[John Floren]

On 8/18/06, Rodolfo (kix) <rodolfogarciap@gmail.com> wrote:
> Ummm,
>
> you have the auth server running?  try to find it with ps.
>
> you used the newuser script, with the new user?
>
> slds.
>

I just followed the instructions on the wiki,
http://plan9.bell-labs.com/wiki/plan9/Configuring_a_standalone_CPU_server/index.html

That *said* it would configure auth too, I think. What is the name of
the auth server? auth/authsrv?

John
-- 
"The first thing we do, let's kill all the lawyers" -- Shakespeare, Henry VI

Re: [9fans] login problems

[John Floren]

On 8/19/06, John Floren <slawmaster@gmail.com> wrote:
> On 8/18/06, Rodolfo (kix) <rodolfogarciap@gmail.com> wrote:
> > Ummm,
> >
> > you have the auth server running?  try to find it with ps.
> >
> > you used the newuser script, with the new user?
> >
> > slds.
> >
>
> I just followed the instructions on the wiki,
> http://plan9.bell-labs.com/wiki/plan9/Configuring_a_standalone_CPU_server/index.html
>
> That *said* it would configure auth too, I think. What is the name of
> the auth server? auth/authsrv?
>
> John
Well, I don't know what it is for you, but I had to put these lines in cpurc:

mv /rc/bin/service.auth/!il566 /rc/bin/service.auth/il566
mv /rc/bin/service.auth/!tcp567 /rc/bin/service.auth/tcp567

Problem appears to be solved.

John
-- 
"The first thing we do, let's kill all the lawyers" -- Shakespeare, Henry VI

Re: Re: [9fans] login problems

[andrey mirtchovski]

this is a quote from the wiki page you listed:

Uncomment the two lines indicated to enable the authentication functions:

# auth/keyfs -wp -m /mnt/keys /adm/keys >/dev/null >[2=1]
# auth/cron >>/sys/log/cron >[2=1] &

Uncomment the indicated code block. The file names indicate the port
and protocol, and the file itself contains the commands for starting a
service. The authsrv. and ! prefixes indicate disabled services;
adding or removing the prefix disables or enables the service:

# if(! test -e /rc/bin/service.auth/il566){
#	mv /rc/bin/service.auth/authsrv.il566 /rc/bin/service.auth/il566
#	mv /rc/bin/service.auth/authsrv.tcp567 /rc/bin/service.auth/tcp567
#	mv /rc/bin/service/il566 /rc/bin/service/!il566
#	mv /rc/bin/service/tcp567 /rc/bin/service/!tcp567
# }

The original /rc/bin/service/il566 and /rc/bin/service/tcp567 services
were proxy calls for the authentication services to be used by
terminals. We don't need these on the authentication server.

Re: Re: [9fans] login problems

[John Floren]

On 8/19/06, andrey mirtchovski <mirtchovski@gmail.com> wrote:
> this is a quote from the wiki page you listed:
>
> Uncomment the two lines indicated to enable the authentication functions:
>
> # auth/keyfs -wp -m /mnt/keys /adm/keys >/dev/null >[2=1]
> # auth/cron >>/sys/log/cron >[2=1] &
>
> Uncomment the indicated code block. The file names indicate the port
> and protocol, and the file itself contains the commands for starting a
> service. The authsrv. and ! prefixes indicate disabled services;
> adding or removing the prefix disables or enables the service:
>
> # if(! test -e /rc/bin/service.auth/il566){
> #       mv /rc/bin/service.auth/authsrv.il566 /rc/bin/service.auth/il566
> #       mv /rc/bin/service.auth/authsrv.tcp567 /rc/bin/service.auth/tcp567
> #       mv /rc/bin/service/il566 /rc/bin/service/!il566
> #       mv /rc/bin/service/tcp567 /rc/bin/service/!tcp567
> # }
>
> The original /rc/bin/service/il566 and /rc/bin/service/tcp567 services
> were proxy calls for the authentication services to be used by
> terminals. We don't need these on the authentication server.
>

Yes; what of it? I did not have /rc/bin/service.auth/authsrv.il566. I
did, however, have /rc/bin/service.auth/!il566.

John
-- 
"The first thing we do, let's kill all the lawyers" -- Shakespeare, Henry VI

Re: Re: Re: [9fans] login problems

[andrey mirtchovski]

> Yes; what of it?

you said:

> That *said* it would configure auth too, I think.

i listed the section "configuring" auth in hopes it'll shed some more
light. there's a bug in there, of course, and the 'mv' actions are not
to be uncommented but to be issued once, after some pondering given
the bug.

Re: [9fans] login problems

[Alberto Cortés]

On 2006-08-12 13:32, John Floren wrote:
> Hi everyone.
> I've just set up a cpu/auth/file server here at home; I think I've
> done it right (followed the directions on the wiki). However, when I
> try to use drawterm, I can connect fine as "bootes", but when trying
> to connect as a new user (just added), I get this message after typing
> the password:
> 
> cpu: cannot get auth tickets in p9sk1: Connection refused
> goodbye
> 
> Have I forgotten to configure something?

The same here.

I can cpu and drawterm as bootes but not as any other user.

When I cpu (-u bootes) into the cpu/auth/file server there is a
keyfs running but /mnt/keys is empty.

I run keyfs at /rc/bin/cpurc like this:

    auth/keyfs -wp -m /mnt/keys /adm/keys >/usr/bootes/tmp/keyfs_out >[2=1]

There are 3 users in my system.

    cpu% cat /usr/bootes/tmp/keyfs_out
    3 keys read
    cpu% ls /mnt/keys
    cpu% 

I have done some hardware resets (at the lab) and /mnt/keys was
correctly populated and everything works OK. Now, at home,
remotely rebooting (with the reboot command) does not seem to fix
anything.

One more thing... /sys/log/cron (only) complains (each 10 minutes) about:

grunt Dec 21 13:20:01 upas: can't call mailserver: cs: can't translate service

don't know if it is important

Maybe running auth/keyfs on the procces listening for incomming
network connections solve the problem, but i don't know how to do
it :)

-- 
  http://bach.gast.it.uc3m.es/~alcortes/index.html

Re: [9fans] login problems

[Gabriel Diaz]

hello

> keyfs running but /mnt/keys is empty.

keyfs should be only available on the console namespace i think.


> grunt Dec 21 13:20:01 upas: can't call mailserver: cs: can't translate service
>

look at /cron/upas/cron and change mailserver with the name of your
mailserver (if you're on standalone installation use your hostname)

> don't know if it is important
>

it only matters if you are not able wasting space with logs :)

about the login problems i would suggest to use auth/debug and check
the /sys/logs

gabi

Re: [9fans] login problems

[Alberto Cortés]

On 2006-12-28 15:56, Gabriel Diaz wrote:
> hello
> 
> >keyfs running but /mnt/keys is empty.
> 
> keyfs should be only available on the console namespace i think.

Do you know how to check it?


> >grunt Dec 21 13:20:01 upas: can't call mailserver: cs: can't translate 
> >service
> >
> 
> look at /cron/upas/cron and change mailserver with the name of your
> mailserver (if you're on standalone installation use your hostname)
> 
> >don't know if it is important
> >
> 
> it only matters if you are not able wasting space with logs :)
> 
> about the login problems i would suggest to use auth/debug and check
> the /sys/logs

auth/debug seems ok, I can not find documentation for it, but i
am reading the source know.

cpu% grep '^grunt Dec 28' /sys/log/*

does not show anything weird.

> gabi
> 

-- 
  http://bach.gast.it.uc3m.es/~alcortes/index.html

Re: [9fans] login problems

[Gabriel Diaz]

hello

just test if you can't see /mnt/keys from drawterm (as hostowner) and
you can see it on the console of the auth system, thats the way it is
on my computer.

>
> auth/debug seems ok, I can not find documentation for it, but i
> am reading the source know.
>

auth/debug had been discussed here time ago, try to search for those
mails on 9fans archives, iirc it should be easy to understand it, just
run auth/debug and see if it fails.

gabi

Re: [9fans] login problems

[Alberto Cortés]

On 2006-12-28 16:38, Gabriel Diaz wrote:
> hello
> 
> just test if you can't see /mnt/keys from drawterm (as hostowner) and
> you can see it on the console of the auth system, thats the way it is
> on my computer.

If I drawterm to the server as bootes, /mnt/keys is empty.

If I cpu to the server as bootes, /mnt/keys is empty.

I have no physical access to my server, I don't know how to
check /mnt/keyfs from the console on remote.


> >auth/debug seems ok, I can not find documentation for it, but i
> >am reading the source know.
> >
> 
> auth/debug had been discussed here time ago, try to search for those
> mails on 9fans archives, iirc it should be easy to understand it, just
> run auth/debug and see if it fails.

OK, anyway I have read the sources, and the output of auth/debug
is good, no problems, no warnings, no errors.


> 
> gabi
> 

Thanks for your checkings and quick replys.


-- 
  http://bach.gast.it.uc3m.es/~alcortes/index.html

Re: [9fans] login problems

[andrey mirtchovski]

> If I drawterm to the server as bootes, /mnt/keys is empty.
>
> If I cpu to the server as bootes, /mnt/keys is empty.

those both are correct behaviours.

>
> I have no physical access to my server, I don't know how to
> check /mnt/keyfs from the console on remote.

cpu as bootes/hostowner, run "kill keyfs | rc; auth/keyfs". then keyfs
will run in your local namespace, but you need to reboot the machine
before you disconnect.

Re: [9fans] login problems

[Alberto Cortés]

On 2006-12-28 17:01, andrey mirtchovski wrote:
> >If I drawterm to the server as bootes, /mnt/keys is empty.
> >
> >If I cpu to the server as bootes, /mnt/keys is empty.
> 
> those both are correct behaviours.

good news!


> >I have no physical access to my server, I don't know how to
> >check /mnt/keyfs from the console on remote.
> 
> cpu as bootes/hostowner, run "kill keyfs | rc; auth/keyfs". then keyfs
> will run in your local namespace, but you need to reboot the machine
> before you disconnect.

After invoking "kill keyfs | rc ; auth/keyfs" I can see the users 
directories under /mnt/keys. But I still can not cpu with the
login name of other users:

    cpu: can't authenticate: grunt: auth_proxy rpc write: (black
    square)bootes: connection timed out


I can still cpu as bootes as usual.

Rebooting doesn't change anything.



-- 
  http://bach.gast.it.uc3m.es/~alcortes/index.html

Re: [9fans] login problems

[andrey mirtchovski]

>
> After invoking "kill keyfs | rc ; auth/keyfs" I can see the users
> directories under /mnt/keys. But I still can not cpu with the
> login name of other users:
>
>     cpu: can't authenticate: grunt: auth_proxy rpc write: (black
>     square)bootes: connection timed out
>

the way an auth server works is by linking together several programs:
keyfs, authsrv and listen. keyfs decrypts the users passwords (keys)
and serves them as a plan9 file system, listen accepts connections on
the auth port (tcp 567) and starts authsrv to verify passwords against
keys in keyfs.

when you kill keyfs it disappears from the namespace in which listen
was started and consequently authsrv can't read the keys, hence the
requirement to reboot the machine (therefore rebuilding the right
namespace).

having written this just now, i think you may be starting keyfs after
you start aux/listen in cpurc. you may want to look for that.

now, to verify what keyfs thinks it has the same passwords as the ones
you've given to the users you will have to navigate the directories it
serves. you'll find the password in plaintext there. having the
password in plaintext is one of the reasons /mnt/keys should be empty
when you cpu to a machine.

to ensure that auth/changeuser sets the password correctly you need to
verify that /mnt/keys is populated before you run auth/changeuser. one
way to do it is the aforementioned killing/restarting of keyfs, which
is what i use to add new users to machines where i have no physical
access handy.

Re: [9fans] login problems

[Alberto Cortés]

On 2006-12-28 18:06, andrey mirtchovski wrote:
> >
> >After invoking "kill keyfs | rc ; auth/keyfs" I can see the users
> >directories under /mnt/keys. But I still can not cpu with the
> >login name of other users:
> >
> >    cpu: can't authenticate: grunt: auth_proxy rpc write: (black
> >    square)bootes: connection timed out
> >
> 
> the way an auth server works is by linking together several programs:
> keyfs, authsrv and listen. keyfs decrypts the users passwords (keys)
> and serves them as a plan9 file system, listen accepts connections on
> the auth port (tcp 567) and starts authsrv to verify passwords against
> keys in keyfs.
> 
> when you kill keyfs it disappears from the namespace in which listen
> 
> [...]
> 
> way to do it is the aforementioned killing/restarting of keyfs, which
> is what i use to add new users to machines where i have no physical
> access handy.

thank you for enlighten me, I was failing to see the big
picture.

After some more man page reading, I have been doing some tests:

  term% telnet tcp!grunt!17007
  connected to tcp!grunt!17007 on /net/tcp/1
  p9sk1@grunt.foo.bar(fs)
  >>>   (b)reak, (i)nterrupt, (q)uit, ...
  >>> q
  term%
  term%
  term% telnet tcp!grunt!567
  telnet: tcp!grunt!567: connection timed out  # this can be the problem!!
  term%
  term%
  term% cpu=grunt
  term% cpu -u bootes
  cpu%
  cpu%
  cpu% telnet tcp!grunt!567
  connected to tcp!grunt!567
  
  >>>   (b)reak, (i)nterrupt, (q)uit, ...
  >>> q
  cpu%
  cpu%
  cpu% tail -19 /rc/bin/cpurc
  auth/keyfs -wp -m /mnt/keys /adm/keys >/usr/bootes/tmp/keyfs_out >[2=1]
  auth/cron >>/sys/log/cron >[2=1] &
  #
  # also rename some files:
  #
  #if(! test -e /rc/bin/service.auth/il566){
  #    mv /rc/bin/service.auth/authsrv.il566 /rc/bin/service.auth/il566
  #    mv /rc/bin/service.auth/authsrv.tcp567 /rc/bin/service.auth/tcp567
  #    mv /rc/bin/service/il566 /rc/bin/service/_il566
  #    mv /rc/bin/service/tcp567 /rc/bin/service/_tcp567
  #}

  # services available to networks
  aux/listen -q -t /rc/bin/service.auth -d /rc/bin/service il
  aux/listen -q -t /rc/bin/service.auth -d /rc/bin/service tcp

  aux/mouse $mouseport
  aux/vga -l $vgasize
  exec rio
  cpu%
  cpu%
  cpu% cat /rc/bin/service.auth/tcp567
  #!/bin/rc
  /bin/auth/authsrv -d $3
  cpu% 

If ssh to a linux on the same LAN as grunt, I can connect to
grunt at port 567:

  alcortes@linux$ telnet grunt.foo.bar 567
  Trying 163.117.141.235...
  Connected to grunt.gast.it.uc3m.es.
  Escape character is '^]'.
  ^]
  telnet> q
  Connection closed.
  alcortes@linux$ 

It seems that the auth port of my server (grunt) can not been
reached from my home. Firewall problems?, isp problems?, Any more
thing I can be missing?



-- 
  http://bach.gast.it.uc3m.es/~alcortes/index.html

Re: [9fans] login problems

[andrey mirtchovski]

> It seems that the auth port of my server (grunt) can not been
> reached from my home. Firewall problems?, isp problems?, Any more
> thing I can be missing?

you'll need to forward port 567 or allow connections to it somehow.
there's a list of required ports to forward on a cpu server behind a
nat/firewall. the list is somewhere on the wiki. if your cpu server
has an external ip address visible to all on the internet, then the
firewall is most likely filtering externaly initiated connections to
ports below 1024.

you pasted the ip address of the machine in your email (the part where
you connect from linux on the same part: you may want to delete more
than just the command line :) so i tried it from here:

administrators-computer:~ andrey$ telnet 163.117.141.235 567
Trying 163.117.141.235...
^C
administrators-computer:~ andrey$ telnet 163.117.141.235 17007
Trying 163.117.141.235...
Connected to grunt.gast.it.uc3m.es.
Escape character is '^]'.
p9sk1@gast.it.uc3m.es


as you can see, 567 times out, while 17007 does not. most likely a
firewall being overprotective.

cheers!

Re: [9fans] login problems

[Alberto Cortés]

On 2006-12-29 13:06, andrey mirtchovski wrote:
> >It seems that the auth port of my server (grunt) can not been
> >reached from my home. Firewall problems?, isp problems?, Any more
> >thing I can be missing?
> 
> you'll need to forward port 567 or allow connections to it somehow.
> there's a list of required ports to forward on a cpu server behind a
> nat/firewall. the list is somewhere on the wiki. if your cpu server
> has an external ip address visible to all on the internet, then the
> firewall is most likely filtering externaly initiated connections to
> ports below 1024.
> 
> you pasted the ip address of the machine in your email (the part where
> you connect from linux on the same part: you may want to delete more
> than just the command line :) so i tried it from here:
> 
> administrators-computer:~ andrey$ telnet 163.117.141.235 567
> Trying 163.117.141.235...
> ^C
> administrators-computer:~ andrey$ telnet 163.117.141.235 17007
> Trying 163.117.141.235...
> Connected to grunt.gast.it.uc3m.es.
> Escape character is '^]'.
> p9sk1@gast.it.uc3m.es
> 
> 
> as you can see, 567 times out, while 17007 does not. most likely a
> firewall being overprotective.

Yes :), my server has a public address, I was hoping someone test
it like you did :), thank you.

It seems the problem is in my server network, not at my home. I
will ask my network admin to open the port.

Thank you all for your help and your quick replys.

-- 
  http://bach.gast.it.uc3m.es/~alcortes/index.html