5 ms·

I've seen several systems that wrap the ssh binary to allow different agents to be forwarded to different hosts. Personally I think this is unwieldy -- it real

I've seen several systems that wrap the ssh binary to allow different agents to be forwarded to different hosts. Personally I think this is unwieldy -- it really should be something which is built into ssh directly. Running multiple agents is also a bit ugly, especially if you are trying to consolidate your keys with an agent integrated with your desktop environment, which I think is the most common use case. FWIW my proposal for fixing it is https://github.com/openssh/openssh-portable/pull/233 https://github.com/openssh/openssh-portable/pull/233 but it isn't the most elegant solution either I guess. It doesn't seem to have picked up much interest so I don't think it's likely to ever be merged (at least in its current form) which is fine. Hopefully some tamed version of agent forwarding appears directly in openssh someday, either as a simple key filter or something more complicated like guardian-agent

metafunctor 5y ago
No need to wrap the binary for that, just something like this in ~/.ssh/config: Host *.foobar.com IdentityAgent ~/.ssh-agent-for-foobar.ssh Of course, you still need to run a separate agent for each security domain you wish to keep separate.
- inetknght 5y ago
  Better: IdentitiesOnly yes # Only use the identity specified by IdentityFile instead of any presented by an agent ForwardAgent no # Don't forward to a remote server. IdentityAgent none # Don't use an agent. AddKeysToAgent no # Don't add any unlocked keys to an agent. Host *.foobar.com IdentityFile ~/.ssh/path/to/private/key
- bodyfour 5y ago
  > Of course, you still need to run a separate agent for each security domain you wish to keep separate. Yes, and that's the rub. It wouldn't be as bad if there was a way to make the ssh client manage the lifetime of the agent process itself (similar to ProxyCommand or something) And I definitely looked into building something like that. Ultimately I thought that something built into the client was better overall for a couple reasons: * Filtering rules can be easily managed as .ssh/config settings * As I mentioned in the PR, I was able to reuse a lot of the existing code for the agent protocol that already is compiled into the client. I also think the "filter" approach makes more sense than having truly separate ssh-agent binaries running. For one thing it's flexible to allow for multiple hops. Imagine if you are ssh'ing from A->B->C. On the first hop I want to give "B" access to keys "K1,K2" but then it wants to only give access to "K2" to C. With a protocol-filtering approach both hosts can prune back the amount of access being forwarded onwards.

metafunctor 5y ago

No need to wrap the binary for that, just something like this in ~/.ssh/config: Host *.foobar.com IdentityAgent ~/.ssh-agent-for-foobar.ssh Of course, you still need to run a separate agent for each security domain you wish to keep separate.

inetknght 5y ago
Better: IdentitiesOnly yes # Only use the identity specified by IdentityFile instead of any presented by an agent ForwardAgent no # Don't forward to a remote server. IdentityAgent none # Don't use an agent. AddKeysToAgent no # Don't add any unlocked keys to an agent. Host *.foobar.com IdentityFile ~/.ssh/path/to/private/key
bodyfour 5y ago
> Of course, you still need to run a separate agent for each security domain you wish to keep separate. Yes, and that's the rub. It wouldn't be as bad if there was a way to make the ssh client manage the lifetime of the agent process itself (similar to ProxyCommand or something) And I definitely looked into building something like that. Ultimately I thought that something built into the client was better overall for a couple reasons: * Filtering rules can be easily managed as .ssh/config settings * As I mentioned in the PR, I was able to reuse a lot of the existing code for the agent protocol that already is compiled into the client. I also think the "filter" approach makes more sense than having truly separate ssh-agent binaries running. For one thing it's flexible to allow for multiple hops. Imagine if you are ssh'ing from A->B->C. On the first hop I want to give "B" access to keys "K1,K2" but then it wants to only give access to "K2" to C. With a protocol-filtering approach both hosts can prune back the amount of access being forwarded onwards.