4 ms·

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, y

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.