Hacker News Reader

Comment by metafunctor | Hacker News Reader

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.

View on HN

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

> 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.

Reply on news.ycombinator.com