stuge-openssh-unix-dev at cdy.org
Tue Jan 8 15:15:46 EST 2008
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
> > 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
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
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.
More information about the openssh-unix-dev