CLI on Windows -exec gives wrong template values

I’m trying to get the boundary CLI integrated in a SSH config on Windows. My goal is, that the tunnel is being opened automatically when running SSH.
This is the SSH config:

Host ttcp_*
  UserKnownHostsFile NUL
  StrictHostKeyChecking no
  ProxyCommand cmd.exe /C "boundary connect -target-id %n -exec plink -- -v -raw {{boundary.ip}}:{{boundary.port}}"

It seems like {{boundary.ip}}:{{boundary.port}} or{{boundary.addr}} always resolve to 127.0.0.1:22 …
The output shows:

 ssh -vv ihadmin@ttcp_d6Y7pa3fgH
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
debug1: Reading configuration data C:\\Users\\JZ/.ssh/config
debug1: C:\\Users\\JZ/.ssh/config line 16: Applying options for ttcp_*
debug1: Executing proxy command: exec cmd.exe /C "boundary connect -target-id ttcp_d6Y7pa3fgH -exec plink -- -v -l ihadmin -raw {{boundary.ip}}:{{boundary.port}}"
debug1: identity file C:\\Users\\JZ/.ssh/id_rsa type 0

debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.1
debug1: kex_exchange_identification: banner line 0:
debug1: kex_exchange_identification: banner line 1: Proxy listening information:
debug1: kex_exchange_identification: banner line 2:   Address:             127.0.0.1
debug1: kex_exchange_identification: banner line 3:   Connection Limit:    -1
debug1: kex_exchange_identification: banner line 4:   Expiration:          Wed, 19 Apr 2023 21:17:46 +08
debug1: kex_exchange_identification: banner line 5:   Port:                52098
debug1: kex_exchange_identification: banner line 6:   Protocol:            tcp
debug1: kex_exchange_identification: banner line 7:   Session ID:          s_HwraNgihrm
Looking up host "127.0.0.1" for main connection
Connecting to 127.0.0.1 port 22
Failed to connect to 127.0.0.1: Network error: Connection refused
Network error: Connection refused
FATAL ERROR: Network error: Connection refused

the templating seems to work, as I get different results when writing “localhost” instead of “{{boundary.ip}}”.

I think it would be really great, if we get this running, as it is the corresponding blueprint for windows for these docs: SSH ProxyCommand Workflow | Boundary | HashiCorp Developer

Any ideas, on how to further debug this? There is no CLI debug / verbose mode…

Just had a thought on this – 127.0.0.1 is not necessarily the same as localhost on all systems. For instance, on my Windows system, which is IPv6 enabled, it resolves to ::1, and firewall rules may be different for IPv4 vs. IPv6. It’s also possible to map localhost to something else entirely.

Does it work if you use 127.0.0.1 with exec instead of localhost without using templating?

Hello Jannik,

Hope you are doing well!

As far as I understand, the issue seems to be related to the {{boundary.port}} part not being rendered correctly.

It looks to me that the command you are using does not have the correct syntax for port in relation to plink utility. It seems that plink uses the -P flag for specifying a port.

If that still does not work, would you share the output of the following command (adjust for Windows if needed):

boundary connect  -target-scope-name=TARGET_SCOPE_HERE -target-name=TARGET_NAME_HERE -exec echo -- {{boundary.ip}} {{boundary.port}}

Seems like you guys are right! I got it working using the -P from plink as well.
My config looks now like this (as reference, for everybody else and maybe for the CLI docs):

Host ttcp_*
  UserKnownHostsFile NUL
  StrictHostKeyChecking no
  ProxyCommand cmd.exe /C "boundary connect -target-id %n -exec plink -- -raw {{boundary.ip}} -P {{boundary.port}}"

Host * !localhost
  UserKnownHostsFile NUL
  StrictHostKeyChecking no
  ProxyCommand cmd.exe /C "boundary connect -target-name %n -target-scope-name="IT XXX" -exec plink -- -raw {{boundary.ip}} -P {{boundary.port}}"

like this, I can connect directly with SSH ssh root@server-name as long as server-name is the name of the target in our corresponding boundary project. As we have one generic IT project, with all SSH targets, I can work like this.
Furthermore, I can also use the target id, that always starts with the prefix ttcp_.

1 Like