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
Best Answer
The issue can be resolved by doing the following:
Edit your client's
~/.ssh/config
file such that the host entry has the following:Note that the
IdentityFile
directive refers to the public key and not the private key file.Add the relevant private key to ssh-agent using
ssh-add
. You should be prompted for a password at this time.