Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it possible to use agent forwarding excluding all keys from being forwarded, except ones specifically stated? Alternatively, are there any ways to specify the order the keys are tried per session?

Using ssh-agent requires managing different sockets:

Are there any alternative agents that are more easily configurable?

For example:

Client A -->  ssh/agent-forwarding --> Server B -->  Server C 
                                            ------>  Server D 

I want to allow only one key in agent forwarding, allowing: A -> B -> C, and not A -> B -> D. Or at least specify the order the keys are tried.

(Edited for clarity after @jeff-ferland answer.)

share|improve this question
up vote 1 down vote accepted

I'm not aware of any agents that allow for the selective forwarding of keys as you've diagramed. Once a key is forwarded to a host, it's as if it were locally stored and can be used to authenticate against any host from there.

Looking at your question on another level, I have two ideas about what you might be trying to do:

  • Prevent somebody from authenticating to certain hosts without physical presence at a location.

If this is your goal, you cannot achieve it through control of authentication keys. You must control access through architecture and host restrictions such that no host which can be accessed remotely is capable of accessing a "safe" host.

  • "Protect" certain keys so they're not exposed.

If this is your goal, it's a misunderstanding of how to protect keys. Keys themselves are never forwarded. The ability to access the ssh agent to authenticate against a key is forwarded. However, that forwarding can only be taken advantage of while the forwarding is in place and only if the machine you've forwarded your agent to is run by an untrustworthy admin (voluntarily or through compromise). Thus in your diagram, unless you successfully log from machine B -> D and export forwarding from A -> B -> D, you are not at risk of exposing your credentials. You can forward from A -> B safely if you trust B.

I suggest you read a very verbose explanation of how forwarding works with diagrams if you're still unclear about the concept.

share|improve this answer
The goal was actually to get around the fact that the order the keys are used on "Server B" can't be easily customized during agent forwarding. Everything works using a regular .ssh session with .ssh/config. However, during agent-forwarding it seems you have no control over the ordering of the keys tried. The question was more for curiosity than practical/security concerns. Thanks for the detailed response and sorry for the confusion. – dgo.a Mar 17 '12 at 18:42
it seems completely legitimate to trust B only for a specific task and thus only forward keys that can authenticate B-ish tasks to B. Thus you seem to be misunderstanding why "Protect certain keys so they're not exposed" is a reasonable goal. If the key can be used to authenticate, access to whatever it protects can be lost and then whether the key was exposed or not is irrelevant. – user239558 Aug 3 '15 at 20:19

If this problem comes up solely for app deployment using various private repos that require different keys:

You can skip agent forwarding altogether. Copy the files onto the machine containing the various keys, then rsync the cloned repos over to the server where deployment occurs.

Client A
* private keys
* `git clone ...` private repos 
* /tmp/repos
      |  ------------> rsync/scp -----------> Server B

You could automate the process with alias, shell scripts, etc. Capistrano even has this built in. It's called the copy strategy:

share|improve this answer

A feature like the one requested would belong in the ssh client.

It would be too difficult for the ssh-agent to figure out when it was communicating through a forwarding and when it was communicating with a local ssh client. Letting the server apply the restriction would be a security flaw. This leaves the ssh client as the only place such a feature could reasonably exist.

A quick look through the openssh source lead me to the client_request_agent function in clientloop.c. From what I see there I get the impression the ssh client simply forwards the raw byte stream without trying to understand which keys are being used. This means it would require a significant effort to add this feature to the client.

Another related feature, which could be added with less work would be an option to use two different agents. One agent could be used for authenticating with the server while another agent could be forwarded to the server.

Both would be useful features which I would make use of as well, but alas appears to not exist in openssh (yet).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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