Re: [9fans] factotum/ssh issue

Re: [9fans] factotum/ssh issue

[Russ Cox]

> I have a minor nitpick, though.  When I ssh'd into a unix
> box for the first time I was prompted to add the key
> (not real security, but good enough for me), then I was
> asked for the password to the machine.  My trigger happy finger
> decided to hit enter, thereby entering a nil password
> and failing to authenticate.  Further attempts to
> ssh into the machine failed because factotum stored the
> incorrect password.  I needed to become accustomed to
> key management with factotum anyway, but it still seems improper
> to store the password if password authentication fails.

I agree.  This has bugged me for a while, but I'm
just not sure what to do.  If authentication fails,
should the key be silently removed from the key store?
Maybe, but I think that would be just as surprising.

> I looked at removing the server key if ssh password authentication
> fails, but there doesn't seem to be an rpc mechanism in factotum
> to do this.

Nothing is stopping the application from doing
	echo delkey whatever >/mnt/factotum/ctl

There are lots of little things about factotum that
bug me.

Russ

Re: [9fans] factotum/ssh issue

[Sam]

> I agree.  This has bugged me for a while, but I'm
> just not sure what to do.  If authentication fails,
> should the key be silently removed from the key store?
> Maybe, but I think that would be just as surprising.

Indeed.

> Nothing is stopping the application from doing
> 	echo delkey whatever >/mnt/factotum/ctl

True, but i didn't want to start junking up the source with
hacks until I received some further thoughts.  Deleting
the key just didn't *seem* right.

Perhaps we could make a factotum nitpick list on the wiki and
begin thinking about shaping it?  I'ld be interested to hear
what else about it bugs you.

Cheers,

Sam

Re: [9fans] factotum/ssh issue

[Skip Tavakkolian]

(Just a thought!)
What if the client process propagated the final part of the
negotiations to the client factotum, identifying it as 'failed' or
'succeeded'.  When the client factotum receives a 'failed', it could
insert a new attribute (maybe 'needkey=').  into that tuple.  Then
when client factoum gets a 'start' again, user would be prompted,
perhaps with the public attributes of the existing tuple as default.
The reason to use a new attribute instead of 'confirm=' is to make the
distinction of providing defaults or not.

> I have a minor nitpick, though.  When I ssh'd into a unix
> box for the first time I was prompted to add the key
> (not real security, but good enough for me), then I was
> asked for the password to the machine.  My trigger happy finger
> decided to hit enter, thereby entering a nil password
> and failing to authenticate.  Further attempts to
> ssh into the machine failed because factotum stored the
> incorrect password.  I needed to become accustomed to
> key management with factotum anyway, but it still seems improper
> to store the password if password authentication fails.

[9fans] factotum/ssh issue

[Sam]

Hola,

We finally stopped working long enough to upgrade
to 4e last week and I have to admit, the first
time I was auto-login'd to a remote unix box
after having stored the key in factotum I was
exuberant.

I have a minor nitpick, though.  When I ssh'd into a unix
box for the first time I was prompted to add the key
(not real security, but good enough for me), then I was
asked for the password to the machine.  My trigger happy finger
decided to hit enter, thereby entering a nil password
and failing to authenticate.  Further attempts to
ssh into the machine failed because factotum stored the
incorrect password.  I needed to become accustomed to
key management with factotum anyway, but it still seems improper
to store the password if password authentication fails.

I looked at removing the server key if ssh password authentication
fails, but there doesn't seem to be an rpc mechanism in factotum
to do this.

Cheers,

Sam