RFC: More explicit ssh agent forwarding on SSH_ASKPASS confirmation

[Ángel González]

This is an old idea I had, resurrected by the mention of changing the
agent protocol in "ssh-agent allowing access to other users?" thread.

Currently, when you forward the ssh-agent, the forwarded host has the
same rights as the local user. And when the key requires confirmation,
the is quite terse: "Allow use of key foobar?
Key fingerprint abcdf."

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)
allegedly
for "connecting to example.com (1.2.3.4)"


The rsync command line would be recovered by the agent itself, thus
being quite trustworthy.
In this case the example represented a local application.

If it was a forwarded request it could be:
Confirmation is required before allowing usage of key foobar
Key fingerprint abcdf.
to process 1234 (ssh -A example.com) allegedly
for process 235 (ssh example.net) allegedly
for connecting to example.net (1.2.3.4)

The fact that the whole chain is provided is what I refered as
"stackable" in the previous mail. Only the first process can be trusted,
but that already diminishes the potential to get the user to accept one
key for a different usage than intended.

Another big benefit of letting the agent know about the origin of the
key request is that keys could be constrained to be used locally (or to
require confirmation from a forwarded connection, but use automatically
by a local program). More complex setups could be achieved by modifying
the available keys forwarded depending on the host you connected to (eg.
for "work" vs "personal" keys) instead of using several agents.

Investigating the agent protocol for writing this, I discovered that I
wasn't the first with this idea, and draft-ietf-secsh-agent-02 [1]
already contemplated something similar with its
SSH_AGENT_FORWARDING_NOTICE message and
SSH_AGENT_CONSTRAINT_FORWARDING_STEPS &
SSH_AGENT_CONSTRAINT_FORWARDING_PATH constraints.
They can be a source for implementing the above. I don't know if the ssh
agent of ssh.com uses a variation of that (incomplete) specification.

Regards

1- http://tools.ietf.org/html/draft-ietf-secsh-agent-02#section-1.2