Informing the SSH agent of the target user at server

[Hector Martin 'marcan']

Hi,

I'm prototyping an SSH agent that can broker access to a large set of 
remotely held SSH keys (potentially hundreds or thousands)*. Since SSH 
servers have a limit on maximum authentication attempts, the client 
needs to be able to request whichever particular key it needs for a 
given target user at server from the agent. Currently, the SSH agent 
protocol[1] only supports unconditionally listing all held keys, it 
doesn't include information about what the target server is.

If all the possible keys are known in advance this could be potentially 
configured as a massive autogenerated ssh_config and a bundle of public 
keys to match, assigning the required key to each target host, but this 
is less than ideal. What I really want is for ssh to just ask the agent 
"give me a list of keys for this user at host" and the agent would offer 
only those, probably just one.

Thoughts? The SSH agent protocol has an extension mechanism, but I'm not 
aware of it being used for anything at the moment.

Ideas:
- Extend the SSH_AGENTC_REQUEST_IDENTITIES request by adding a payload 
with connection information (ideally a tag-value system so different 
metadata can be provided in the future). I've experimentally determined 
that the current standard ssh-agent does not care about a non-empty 
payload, so this would be backwards compatible with the current 
implementation (it would still just return all keys). This could be 
enabled by a config option, to ensure the current-spec-compliant 
behavior is available too.

- Implement an extension that can be queried for, which then replaces 
SSH_AGENTC_REQUEST_IDENTITIES with an extension request that does the 
same thing, with additional connection info. Might still require a 
config option to let people avoid the 1RTT penalty if unneeded, but it 
should be spec-compliant.

If this sounds like a good idea I'd be happy to give implementing it in 
OpenSSH a go and submit a patch. I want to get a feeling for whether any 
of this sounds like a workable plan before I do that.

Hacky approaches that would not require changes to the ssh client 
include using setting IdentityAgent to <path>/%u@%h:%p where <path> is a 
virtual filesystem that materializes sockets as required; using 
LD_PRELOAD to hook the agent socket and inject the appropriate info; 
setting ProxyCommand to something that informs the agent ahead of time; 
or just wrapping ssh in something that tries to figure out what you're 
trying to do ahead of time. Obviously all of these have various 
drawbacks and are less than ideal; good enough for a prototype, but I'd 
much rather have a sane way of achieving this in the future. In 
particular, having this in mainline SSH means agent forwarding would 
work as intended without having to have anything installed on 
intermediate servers, just the custom agent on the client side.

[1] https://tools.ietf.org/html/draft-miller-ssh-agent-02

* This will be an open-source project.

-- 
Hector Martin
Public key: https://mrcn.st/pub