From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <66f0189a4a1807edfe24c7c699c8aa42@centurytel.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] factotum/ssh issue
From: "Skip Tavakkolian" <fst@centurytel.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Mon, 11 Nov 2002 10:36:49 -0500
Topicbox-Message-UUID: 1af912e2-eacb-11e9-9e20-41e7f4b1d025

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