openssh unix dev - Apr 2013 - RFC: More explicit ssh agent forwarding on SSH_ASKPASS confirmation

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

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

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'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?

	--dkg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20130402/42699d23/attachment.bin>