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?
Best Answer
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. TheProxyCommand
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 forHost 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 matchtarget
,target%via
,target.example.com
andtarget.example.com%via
.And so you ask the question, would setting an
.ssh/config
on thegateway
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 theProxyCommand
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 seenHost *+*
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