PuTTY wish pageant-forwarding-path

Home | Licence | FAQ | Docs | Download | Keys | Links
Mirrors | Updates | Feedback | Changes | Wishlist | Team

It would be handy if Pageant could treat clients differently depending on whether they were local or agent-forwarded, and in the latter case, where they were agent-forwarded from.

Uses for this might include:

• Forwarding only a subset of the available keys: e.g. arrange to forward a low-security key but not a more critical one to some only-half-trusted server.
• Requiring manual confirmation of agent signing requests depending on the source server.
• Blacklisting a particular host from any agent forwarding at all, if for some reason you can't easily find all your SSH client configurations to remove the agent forwarding option from individually.

In principle, you could set this up by a system along the lines of: when any SSH client forwards a connection back to its agent, it begins the connection by sending a message of its own announcing what server it's forwarding from. If all SSH clients did this, then the real agent would see a string of 'forwarded-from' notices at the start of any client connection, and could trust each one not to have been tampered with by the server named in it.

(E.g. suppose you make a series of SSH connections from your client to host A, from A onwards to B, and from B to C. Then an agent connection originating at C would arrive at your actual agent prefixed with three forwarding notices listing hosts A,B,C, in that order. And if, say, the agent had reason to mistrust host B, then it could still at least trust the notice mentioning host B, because that notice was generated by the more-trusted host A and there was nothing B could do about it.)

In practice, it's not as easy as that. To begin with, this requires a system of agent communication which is stateful (in the sense that multiple requests from the same client can be linked to each other). The Unix agent protocol already manages this, but on Windows, we'd have to implement pageant-named-pipe first.

Also, there's a question of protocol design. The agent protocol proposed to the IETF working group did indeed include a forwarding-notice message, but the OpenSSH-derived one used in practice does not. So we'd have to start by inventing a protocol extension, and making sure it was one that could be handled without too much confusion by agents not supporting it. Also, SSH clients not supporting the extension would fail to inject a forwarding notice, and it's hard to think of any way that the ultimate agent could detect that failure.

So it might not be feasible at all to track multi-hop forwardings reliably. But you could still get something to work for the first hop, I think, by inventing agent messages saying either 'I promise I am a local client' or 'I am a forwarding from server X', and having the actual local clients send one or other of those messages and also delete all such messages from the start of forwarded connections.

Audit trail for this wish.