RFC: More explicit ssh agent forwarding on SSH_ASKPASS confirmation

[Ángel González]

On 03/04/13 02:20, Daniel Kahn Gillmor wrote:
> On 04/02/2013 06:13 PM, Ángel González wrote:
>> It would be desirable to have instead a text like:
>> Confirmation is required before allowing usage of key foobar
>> Key fingerprint abcdf.
>> to process 1234 (ssh example.com rsync --server --sender -logDtpre.iLsf)
> this material itself could be presented to the user even without changes
> to the protocol.
Right. Although I'm afraid there would be little difference between a
direct
request and one proxied from another ssh instance (specially if it is
configured
with ForwardAgent yes).

>> allegedly for "connecting to example.com (1.2.3.4)"
> this line would need some protocol extension.  The SSH_FORWARDING_NOTICE
> protocol detail you've referenced does *not* seem to cover this case,
> but as you noted, you could use it for inspiration.
The provided SSH_AGENT_FORWARDING_NOTICE only covers to whom it
would be sent, the reason would be a nice addition (perhaps as a different
message).

> It seems like the first step would be to implement the prompting you
> describe without the protocol changes and get people using it and giving
> feedback on whether they find it useful.  This would probably be just a
> patch to ssh-agent, no need to change ssh or ssh-askpass or anything
> else.  I'd be happy to review and test such a patch, if you post it
> someplace publicly.
I think the big benefit would be to separate forwarded requests from
local ones,
but I could begin with this.

> I'm less convinced of the usefulness of the advisory strings, and they
> have a higher bar to meet in the first place since they require changes
> to the protocol to get them through to the agent.  is there a way to do
> version or feature negotiation on the channel so that clients can fall
> back to not providing advisory strings to an agent that might reject or
> crash on them?
If the agent doesn't support the message, it should reply with
SSH_AGENT_FAILURE.
The client could then skip that message in later events. An agent that
crashed seems extremely broken.

Thanks for your feedback