[9fans] Auth woes.

[9fans] Auth woes.

["Nils O. Selåsdal"]

Hi,
I'm having some auth woes - on a cpu/file/auth server running pccpuf(minus some 
network and video drivers).

These lines appear in my cpurc;

auth/cron >>/sys/log/cron >[2=1] &
auth/secstored -s tcp!192.168.1.100!5356
auth/keyfs -wp -m /mnt/keys /adm/keys >/dev/null >[2=1]

Now, the only crontab is /cron/upas/cron , after cron has run that once, I can
no longer authenticate to the box.
Drawterm says; drawterm: cannot authenticate with p9
abort 11426

And 'cpu -h localhost -u bootes' from an already logged in drawterm
session says
cpu% cpu -h localhost -u bootes
cpu: can't authenticate: localhost: auth_proxy short read: cpu: srvauth: 
auth_proxy rpc: negotiation failed, no common protocols or keys

Commenting out the line that starts cron in cpurc, auth never(so far)
stops after a reboot...
Any suggestions ?

(btw. 2 other people have the same symptoms on their auth/cpu/file servers, I've
not verified with them wether running cron or not affects anything.)

--
Nils O. Selåsdal

Re: [9fans] Auth woes.

[Russ Cox]

pull a new factotum from sources.
i bet your problem goes away.

On 5/3/05, "Nils O. Selåsdal" <noselasd@asgaard.homelinux.org> wrote:
> Hi,
> I'm having some auth woes - on a cpu/file/auth server running pccpuf(minus some
> network and video drivers).
> 
> These lines appear in my cpurc;
> 
> auth/cron >>/sys/log/cron >[2=1] &
> auth/secstored -s tcp!192.168.1.100!5356
> auth/keyfs -wp -m /mnt/keys /adm/keys >/dev/null >[2=1]
> 
> Now, the only crontab is /cron/upas/cron , after cron has run that once, I can
> no longer authenticate to the box.
> Drawterm says; drawterm: cannot authenticate with p9
> abort 11426
> 
> And 'cpu -h localhost -u bootes' from an already logged in drawterm
> session says
> cpu% cpu -h localhost -u bootes
> cpu: can't authenticate: localhost: auth_proxy short read: cpu: srvauth:
> auth_proxy rpc: negotiation failed, no common protocols or keys
> 
> Commenting out the line that starts cron in cpurc, auth never(so far)
> stops after a reboot...
> Any suggestions ?
> 
> (btw. 2 other people have the same symptoms on their auth/cpu/file servers, I've
> not verified with them wether running cron or not affects anything.)
> 
> --
> Nils O. Selåsdal
>

Re: [9fans] Auth woes.

["Nils O. Selåsdal"]

Russ Cox wrote:
> pull a new factotum from sources.
> i bet your problem goes away.

I had my hopes up for a while, but, still same troubles.
(I also rebuilt the kernel so it gets the new factotum (?))
Then again, I don't need cron ;-)

--
Nils O. Selåsdal

Re: [9fans] Auth woes.

["Nils O. Selåsdal"]

Russ Cox wrote:
> after the cron job has run, what does cat /mnt/factotum/ctl show?
> 
As I told Russ, the key gets disabled. I added a flog call to
factotum/p9sk1.c;

convM2T(tbuf, &s->t, (char*)s->key->priv);
if(s->t.num != AuthTc){
	disablekey(s->key);
	flog("disabling key. s->t.num=%d",s->t.num);
	if(askforkeys){

(Ok I later realized t.num is a char)
Which seems to be what is disabling the key.
/mnt/factotum/log says disabling key. s->t.num=41,
(on next reboot it said s->t.num=76)

The whole log is;

2: no key matches proto=p9sk1 role=server dom?
2: failure no key matches proto=p9sk1 role=server dom?
3: no key matches proto=p9sk1 dom=fiane.intra role=client dom=fiane.intra user? 
!password? owner=upas owner=*
3: failure no key matches proto=p9sk1 dom=fiane.intra role=client 
dom=fiane.intra user? !password?
disabling key. s->t.num=76
3: failure bad key
4: no key matches proto=p9sk1 role=server user? dom?
4: failure no key matches proto=p9sk1 role=server user? dom?

--
Nils O. Selåsdal

Re: [9fans] Auth woes.

[Russ Cox]

It sure sounds like your auth server (keyfs) and your factotum
do not agree on what the password is.  The new factotum that
I said to pull fixed a different problem -- if the server side fails
the auth, it could be because the client lied, so that case doesn't
disable the key anymore.  But the case you're running into is that
the tickets coming back from the auth server don't decrypt properly,
and since factotum trusts the auth server, it disables the key.

Russ

On 5/3/05, "Nils O. Selåsdal" <noselasd@asgaard.homelinux.org> wrote:
> Russ Cox wrote:
> > after the cron job has run, what does cat /mnt/factotum/ctl show?
> >
> As I told Russ, the key gets disabled. I added a flog call to
> factotum/p9sk1.c;
> 
> convM2T(tbuf, &s->t, (char*)s->key->priv);
> if(s->t.num != AuthTc){
>         disablekey(s->key);
>         flog("disabling key. s->t.num=%d",s->t.num);
>         if(askforkeys){
> 
> (Ok I later realized t.num is a char)
> Which seems to be what is disabling the key.
> /mnt/factotum/log says disabling key. s->t.num=41,
> (on next reboot it said s->t.num=76)
> 
> The whole log is;
> 
> 2: no key matches proto=p9sk1 role=server dom?
> 2: failure no key matches proto=p9sk1 role=server dom?
> 3: no key matches proto=p9sk1 dom=fiane.intra role=client dom=fiane.intra user?
> !password? owner=upas owner=*
> 3: failure no key matches proto=p9sk1 dom=fiane.intra role=client
> dom=fiane.intra user? !password?
> disabling key. s->t.num=76
> 3: failure bad key
> 4: no key matches proto=p9sk1 role=server user? dom?
> 4: failure no key matches proto=p9sk1 role=server user? dom?
> 
> --
> Nils O. Selåsdal
>

Re: [9fans] Auth woes.

["Nils O. Selåsdal"]

Russ Cox wrote:
>>>It sure sounds like your auth server (keyfs) and your factotum
>>>do not agree on what the password is.  The new factotum that
>>>I said to pull fixed a different problem -- if the server side fails
>>>the auth, it could be because the client lied, so that case doesn't
>>>disable the key anymore.  But the case you're running into is that
>>>the tickets coming back from the auth server don't decrypt properly,
>>>and since factotum trusts the auth server, it disables the key.
>>
>>Ok. I'm not quite sure I follow, You're saying the key(password) in nvram
>>doesn't match what's stored in /adm/keys ?
>>(if so I'm pretty sure they're the same, but I'll try to investigate further..)
> 
> 
> if you're not using securestore, then yes that's what i'm saying.
> (if you're using securestore, then i'm saying that the password
> in the secstore file doesn't match what is stored in /adm/keys.)
Well, bootes secstore only holds my key for sources..

I reinitialized nvram (echo asda >/dev/sdC0/nvram, rebooted) and
ran 'passwd' as bootes , ensuring both passwords were the same.
I suspect they already were, else no login/passwd changing would have worked ?
Still, I can only drawterm to it (as bootes, or anyone else) until cron
has run.

*sigh* I'm too new/not any good at this.

--
Nils O. Selåsdal