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@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@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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
