I work for two companies (let's call them RedCorp and BlueCorp). They both trust me but they don't trust each other, and I don't want to expose either's secrets to the other.

My laptop's ssh-agent has two private keys, one for access to each company. I can run:

ssh -A redcorp-server1

and access all of redcorp's other servers from there, by virtue of my forwarded agent connection.

Likewise, I can run:

ssh -A bluecorp-server1

and access all of bluecorp's other servers from there.

The problem is that whenever I'm logged into redcorp-server1, the root user there can set his $SSH_AUTH_SOCK to point at my forwarded agent connection, and abuse my other identity to break into BlueCorp.

How can I prevent that?

ssh's IdentitiesOnly option doesn't do what I want. That only controls which key I offer when authenticating to redcorp-server1; it doesn't change the fact that my forwarded agent connection allows an ssh process on redcorp-server1 to authenticate using any of my identities.

The only solution I've found is to run two separate ssh-agents, and only load one key into each of them. That's a huge pain though: There's no way for an ssh_config stanza to specify which of my agents I should use when connecting to a given host. Instead I've had to make shell aliases on my laptop for each of the two corps which point $SSH_AUTH_SOCK to the right agent before running ssh. Also, I use rsync and a dozen other tools which use ssh as a transport, and each of them has to be configured using a different syntax to make it invoke ssh in this special way.

Is there a better way to do this?

  • 1
    I don't think this functionality exists. It would be a great idea to write a proxy agent that filters SSH agent requests so that sessions under that proxy could see only a subset of keys. It could probably be made so that it is used as a prefix to the ssh command line like ssh-agent-filter -i allow_this_fingerprint ssh rest-of-command-line
    – Celada
    Mar 19, 2013 at 1:39
  • Would it be possible to just not use ForwardAgent on your connections?
    – Jenny D
    Mar 19, 2013 at 8:39
  • 1
    It's a bit depressing that this has had so few views and votes. People are mostly just not aware of the issue.
    – mc0e
    May 12, 2016 at 15:38

4 Answers 4


I implemented an ssh-agent-filter for myself, use it with:

$ afssh -c id_bluecorp -- server1.bluecorp.com
$ afssh -c id_bluecorp -- server2.bluecorp.com
$ afssh -c id_redcorp -- server42.redcorp.com

It's already in Debian (and Ubuntu).

  • Sounds like a useful tool. I can think of a couple of features, which would make it even more useful. 1. Support for adding a key through the filter. 2. Support for using a key to authenticate to a server without forwarding the key I just used to authenticate to that server. 3. Support for specifying multiple agents from which the filter can request signatures. (Though the third might be better suited as a separate tool.)
    – kasperd
    Jan 17, 2015 at 17:48
  • @kasperd 1.: added as an issue 2: you might tell ssh to use a key without asking the agent or add the key needed for the initial connection as confirmed. for the agent it is impossible to tell apart local from forwarded requests because both come from the local ssh process. Jan 19, 2015 at 1:28
  • Telling the ssh client to find the key in a file would work fine, if I had the secret key in an unencrypted file. However my primary reason for using ssh-agent is, that I don't have the key in an encrypted file. I realize that one of the features I was asking for would probably require a modification to the ssh client rather than ssh-agent-filter. If the ssh client would read two different environment variables to find the agent to use for authentication and the agent to use for forwarding, then it should be possible.
    – kasperd
    Jan 19, 2015 at 1:41

You can use multiple agents and specify each specifically using IdentityAgent and add the keys you want with IdentityFile and set AddKeysToAgent to yes. You will have to specify the unix socket for each ssh-agent to bind to with the -a option. You could also of course add the keys manually with ssh-add, after you create each one.

First create your agent:

ssh-agent -a ~/.ssh/redcorp-agent

Then in your .ssh/config have something like this:

Host redcorp* *.redcorp.com
IdentityFile ~/.ssh/redcorp.pem
IdentityAgent ~/.ssh/redcorp-agent
AddKeysToAgent yes
ForwardAgent yes
  • I don't understand why this hasn't been voted the "best" answer. ssh-agent-filter (from the top voted answer) is interesting, but is a third party tool that's not part of OpenSSH. It's nice to know about, but the solution presented in this answer uses only OpenSSH and improves understanding of SSH, whereas I feel like ssh-agent-filter is obfuscating an otherwise understandable topic behind "magic". Aug 24, 2020 at 12:55

There is a patch to openssh that will forward the ssh-agent specified by the SSH_AUTH_SOCK_FORWARD environment variable to the remote host and use the usual SSH_AUTH_SOCK env. var. agent for authenticating to the host.

That means that you can use ssh-agent filter to filter just the key you want available on the remote machine and change the env. var from ssh-agent filter to SSH_AUTH_SOCK_FORWARD while leaving all your keys in the SSH_AUTH_SOCK agent.

You can find the patch here:


Hopefully it will be applied to openssh.


I don't get the problem. If you set and export $SSH_AUTH_SOCK to the appropriate value then programs which call ssh should not need any modification. Of course, the target of e.g. an rsync call must be compatible with the selection of the ssh-agent.

  • 1
    If you don't get the problem, then maybe make a comment about it, but don't put that forward as an answer. As the OP says, you can't select the agent from an ssh_config stanza.
    – mc0e
    May 12, 2016 at 15:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.