I'm attempting to set up some universal options for bouncing ssh connections. Here is my ~/.ssh/config file, abbreviated:

Host *%via
  ProxyCommand ssh gateway -W $(echo %h | cut -d%% -f1) %p

Host gateway
  HostName gateway.example.com
  User username
  ForwardAgent yes
  IdentityFile keypathg

Host target
  User username
  HostName target.example.com
  IdentityFile keypatht

When I utilise *%via utilising the Host aliases, I get:

% ssh -vvv target%via
OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /Users/myuser/.ssh/config
debug1: /Users/myuser/.ssh/config line 5: Applying options for *
debug1: /Users/myuser/.ssh/config line 12: Applying options for *%via
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/Users/myuser/.ssh/tmp/target%via_22_myuser" does not exist
debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec ssh -A gateway -W $(echo target%via | cut -d% -f1):22
debug1: permanently_drop_suid: 501
debug1: identity file /Users/myuser/.ssh/id_rsa type -1
debug1: identity file /Users/myuser/.ssh/id_rsa-cert type -1
debug1: identity file /Users/myuser/.ssh/id_dsa type -1
debug1: identity file /Users/myuser/.ssh/id_dsa-cert type -1
ssh_exchange_identification: Connection closed by remote host

However, if I utilise

% ssh target.example.com%via

I hit the target server, but as the wrong user and with no pubkey authentication.

I think my question, at this point, is does this method of bouncing, when utilising ForwardAgent, pass through my ssh config/environment whole, or just keys. If just keys, can the former be utilised in some way?

My ssh version is 5.9v1, gateway is 5.9v1, and target is 5.3p1. I believe -W was introduced in 5.4, but that should not matter for the final box in line? utilising the older school nc seems no different.

I have verified that I can manually ssh to each box in the line. Doing so indicates that hostname alias information is not passed, as when on gateway, I cannot ssh target but I can ssh target.example.com. This works with pubkey auth. gateway and target incidentally have the same username, which is why this works if no config is pushed.

If ForwardAgent or similar config can't push this information, what's the sanest way to get around it, keeping a .ssh/config on gateway with this information?

1 Answer 1


Wow, thanks for asking this question. I find it rare to see someone fully exploiting SSH and this question hits on a couple of areas.

This is not a ProxyCommand issue. The ProxyCommand simply instructs the local ssh client to do something in preparation before trying to talk to the remote client. Yes, in our instance, we talk to another ssh session, but that session, with the -W simply takes our input and forwards it to another machine. You can think of that preparatory ssh session is completely independent. Inevitable car analogy: Your car is the same car, regardless of whether you had to ride a ferry to get from point A to point B.

This isn't a ForwardAgent issue. ForwardAgent has the local client provide a facility that makes local keys available within the environment of the remote session. You haven't gotten past establishing the remote session.

It is an .ssh/config format issue. Note the second and third debug1 lines. They list what Host stanzas are being applied from your .ssh/config. You note that $ ssh target.example.com%via works, but as wrong username and key. Well, the stanza for Host target is not being read (which would provide the correct username and keyfile). Which stanzas are used? * and *%via.

How to get these options to pass? Well, interesting enough, the wildcard matches 0 length strings. Host target* will match target, target%via, target.example.com and target.example.com%via.

And so you ask the question, would setting an .ssh/config on the gateway machine help. No, it would not. It would never be read. Everything's happening from our local machine.

All I've explained, only answers why $ ssh target.example.com%via isn't working.

You prefer $ ssh target%via. Rightly so, it's more convenient. The short form is failing because, as a hostname, target isn't found; it's not resolving. Why isn't isn't ssh spewing: ssh: Could not resolve hostname target: Name or service not known? Because the ProxyCommand has already been successfully established. Elements of an ssh connection have been built, but the hostname failure is happening where it's not expecting, and so it's bombing out with the more generic message. I would file a bug report on this, to help identify where debug information could be improved.

Final commentary:

I do like the Host *%via syntax. It's clean, yet flexible. I'd previously seen Host *+* and it uses both the first and last part of the %h(ost) to determine where to go. But it takes a little more effort to get your mind around that. link: http://wiki.gentoo.org/wiki/SSH_jump_host

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.