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.

[MisterTea]

@andrewleech I thought our Ci was flaky but I've run this several times and it is timing out. Can you run ctest on your side and see what is causing the issue?

[andrewleech]

Found the hang. Test 4 in connect_with_jumphost.sh was missing --port 9901 for the destination ET server.

Without it, destinationPort defaults to 2022. The jump daemon starts on the jumphost with --dstport=2022 but the destination etserver is at 9901, so UserJumphostHandler::connect() fails. The jump daemon then enters its reconnect loop indefinitely. Since it's daemonized (via DaemonCreator::createSessionLeader()) it doesn't block the SSH subprocess, so SubprocessToStringInteractive returns fine with the IDPASSKEY, but the et client then hangs in TerminalClient::run() waiting for data through the jump channel that never arrives.

I've pushed a fix - just adds --port 9901 to the Test 4 et command. ctest passes locally (259s). Should unblock CI.

[codecov]

Codecov Report

❌ Patch coverage is 72.97297% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.82%. Comparing base (ee8ddc2) to head (a60b294).
⚠️ Report is 7 commits behind head on master.

Files with missing lines	Patch %	Lines
src/terminal/HostParsing.hpp	66.66%	7 Missing ⚠️
src/terminal/SshSetupHandler.cpp	81.25%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #705      +/-   ##
==========================================
- Coverage   87.05%   86.82%   -0.24%     
==========================================
  Files          70       71       +1     
  Lines        5161     5366     +205     
  Branches      483      500      +17     
==========================================
+ Hits         4493     4659     +166     
- Misses        667      707      +40     
+ Partials        1        0       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.