Hello,

Thank you so much for the input!
I was unaware that the agent can call these functions.
However, I believe that it is somewhat confusing to introduce a
passphrase dialog for ok/cancel input...

I released a new version of my patch:
http://alon.barlev.googlepages.com/o...1-0.21.tar.bz2

This version uses the ssh-askpass interface.

I also splitted the patches so it will be clear what goes to where and why.

Available for OpenSSH and Portable OpenSSH versions, and X.509 functionality.

I will appreciate any more comments you or anyone else may have!

Best Regards,
Alon Bar-Lev.

On 1/8/08, Peter Stuge wrote:
> Ok.
>
> On Sat, Sep 29, 2007 at 06:38:57PM +0200, Alon Bar-Lev wrote:
> > > You mentioned extending the agent protocol. Can you expand on
> > > that a little? Is it really neccessary?

>
> So my point here is that the agent is the only process that can be
> trusted to communicated with the user. ssh-add and others that are
> talking to the agent may be running somewhere else and may be
> compromised. The agent should always have final say.
>
> Compare with how ssh-add -c is implemented. Look for the confirm flag
> in ssh-agent.c.
>
>
> > > Can't the agent figure out when it needs help from the user just
> > > from how it is being used without actually being instructed by
> > > anyone?

>
> By this I mean that the agent is already able to determine when user
> input is required. And there is also an existing mechanism in place
> in ssh-agent for acquiring user input.
>
>
> > This is the major change all smartcard components requires, there
> > are some opened issues in bugzilla regarding this.

>
> Which ones do you mean? Please point them out.
>
>
> > Smartcards are dynamic in nature unlike file based keys, smartcards
> > can be removed and inserted by the users, also the session between
> > the application and the smartcard is sometime time limited.

>
> ssh-agent already handles limitied lifetime for file based keys. I
> think that code can be reused.
>
>
> > There are two kinds of user prompts that an smartcard enabled
> > application needs to have:
> >
> > 1. Token prompt - When key should be used but the hardware device
> > is not available the application should prompt the user to insert
> > his token.

>
> Certainly. I think this should be a prompt just like the one for keys
> added with the confirmation constraint.
>
>
> > This is very important when re-negotiation is performed, as users
> > don't expect session disconnect because their token is not
> > available.

>
> Hm, which re-negotiation do you mean? AFAIK the user's key is never
> used once authenticated between SSH client and server is completed.
> Rekeying etc only deals with session keys, right?
>
>
> > 2. Passphrase prompt - Private key is used first time on session,
> > may be triggered when:
> > a. A new session is created.
> > b. Card was removed and inserted, this actually forces application
> > to create a new session.
> > c. Provider forces session duration timeout, this also forces
> > application to create a new session.

>
> Yup. I think simply calling read_passphrase() in ssh-agent.c is the
> best way to do this.
>
>
> > Because I did not wanted to touch more than I needed, I currently
> > implemented these callbacks using external program the ssh-agent
> > execute when needed.

>
> No need for the prompt_prog stuff, see the mechanism in readpass.c.
>
>
> > But a much cleaner solution would be modifying the ssh-agent
> > protocol so that it inform the forground application to perform the
> > prompt.

>
> Thing is, we do not want the agent to proxy information from the
> network to tokens. The agent should read this information directly
> from the user.
>
>
> > BTW: I don't understood why ssh does not execute ssh-agent
> > internally if one is not available... GnuPG does this and it seems
> > to minimize code duplication...

>
> Probably because the agent causes a considerable change in behavior
> when agent forwarding is enabled.
>
> Forcing an agent whenever someone uses a key to authenticate would be
> a regression IMO. I like the fact that the agent is optional and
> distinct from agent forwarding.
>
>
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/li...enssh-unix-dev
>

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/li...enssh-unix-dev