Fix ProxyJump to support SSH ports and host aliases

[andrewleech]

ET currently fails to connect through jump hosts when the jump host uses a non-standard SSH port or when ProxyJump references an SSH config Host alias.

For example, with this SSH config:

Host jumphost
  HostName jump.example.com
  Port 2222

Host destination
  HostName dest.example.com
  ProxyJump jumphost

Running et destination fails with Could not reach the ET server: jumphost:2022

The issue is that the ProxyJump parsing code was stripping SSH ports from the jump host value:

if (colonIndex != string::npos) {
  jumphost = proxyjump.substr(0, colonIndex);  // Strips :2222
}

Additionally, Host aliases like "jumphost" weren't being resolved to actual hostnames, so ET tried to connect to the alias name instead of the configured hostname.

This PR fixes both issues by:

• Preserving the full ProxyJump value [user@]host[:port] when passing to SSH via -J flag
• Extracting just the hostname from the ProxyJump value for ET socket connections
• Looking up Host aliases in SSH config to get the actual hostname

Tested with the config above. Before the fix et destination fails, after it successfully connects via jump.example.com:2222 (SSH) -> destination (ET).

No breaking changes expected - existing ProxyJump configurations should continue to work, though I don't currently have a working jumphost setup to verify backwards compatibility directly.

[jshort]

@andrewleech now that master has the ci setup fixed, could you rebase so we can make sure the tests all pass. Potentially consider adding a new test case to the connect_with_jumphost but using the ssh path you have fixed.

[andrewleech]

Thanks for the suggestions @jshort
I've rebased and added additional test coverage along with some other cleanups.
While doing this I found some issues with ipv6 address bracket notation support ([::1]:port) in host parsing, so addressed them in a follow up commit with some tests.

[MisterTea]

@andrewleech looks like this is breaking CI?

[jshort]

Thanks for the suggestions @jshort I've rebased and added additional test coverage along with some other cleanups. While doing this I found some issues with ipv6 address bracket notation support ([::1]:port) in host parsing, so addressed them in a follow up commit with some tests.

Oh I see. So in a PR of mine just recently (tunnel/reversetunnel support for bind address and ssh -L/-R notation) I implemented ipv6 bracket parsing of -L/-R arguments. Do you think this logic for the tunnel args and your host parsing for ipv6 addrs in brackets can be shared?

Also maybe an OBOE (note trailing colon):

ssh: Could not resolve hostname localhost:22: Name or service not known

[andrewleech]

Rebased cleanly onto upstream/master — the merge commit and its fix-up are gone, now 3 linear commits.

Re: localhost:22 hostname error — that was caused by the merge conflict resolution in the merge commit. The merge kept the old SSH call {jumphost, SSH_SCRIPT_JUMP} instead of the jump_ssh_args vector that separates the port into a -p flag. With the clean rebase this is resolved correctly: SshSetupHandler.cpp now passes jump_ssh_args which constructs ssh -p 22 user@localhost ... rather than ssh user@localhost:22 ....

Re: sharing IPv6 bracket parsing with tunnel args — unless I misinterpreted what you had in mind, the formats seem different enough that sharing would hurt clarity:

• Host parsing: [user@]host[:port] — 2-3 variable components, keeps brackets, outputs a struct with user/host/portSuffix
• Tunnel parsing: bind:port:host:hostport — exactly 4 colon-separated components, strips brackets, outputs a vector of strings

The bracket-tracking logic itself is only a few lines in each case. An adapter to bridge the format differences would be more code than the duplication it eliminates. Happy to reconsider if you see a cleaner way to factor it though.