you should check out https://github.com/StanfordSNR/guardian-agent ATM it's hard because ssh only contacts the agent when it needs it and drops the connection immediately when done. To "pin" an agent request to a remote identity we'd either need to make the connections persistent and add an extension to inform the agent of the remote identity OR do this on every request. The latter is probably easier. I.e. have ssh inject a SSH_AGENTC_EXTENSION "remote-id@xxxxxxxxxxx" string("user@host") before each agent request (ssh would need to eat the reply too) and the agent uses that to filter the keys it is prepared to send. Specifying which hosts a given key is allowed for could be done with a key constraint. This is backwards-compatible with old agents; if an agent doesn't support the extension, then it would continue working as usual, offering all keys. It also limits the modifications needed to ssh. At present, ssh doesn't have any knowledge of what happens over the agent socket and, critically, doesn't inspect or modify messages there. This design would have it do a one-shot transaction whenever it opens the socket and then it can go back to not caring what happens there afterwards. The downside of this design is that it blurs the trust boundary for ssh-agent; no longer would it be making decisions solely on its own - it would be trusting ssh not to lie to it about the remote destination. I had more grandiose plans to allow each sshd to sign agent requests with the hostkey as they passed through, to allow some sort of chain of trust. Unfortunately that would require fairly far reaching changes to the SSH protocol to enable binding those signatures to the transport instance over which they occur. On Tue, 20 Mar 2018, Hector Martin 'marcan' wrote: > 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 > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
