fix: follow a ProxyJump declared by a jump host - #338
Open
NatLee wants to merge 2 commits into
Open
Conversation
The port of a jump host was computed in two places with different fallbacks: connecting to the hop fell back to the target's port, while the forwardOut reaching the next hop fell back to 22. A jump host does not inherit the target's Port, so a target declared on a non-default port had its first hop dialed on that port. Use one helper for both, falling back to 22 like ssh does, and cover the ProxyJump path with unit tests for the resolution order plus a two container e2e where the target is only reachable through the hop.
Only the target's ProxyJump was read, so a jump host that declares one of its own was contacted directly. When that host is only reachable through its own proxy the connection fails, which is what jeanp413#109 reports. Expand the chain depth first, so the hops a jump host depends on are connected to before it, and report a config that jumps back to a host already being resolved instead of recursing forever.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #109. Stacked on #337 — both touch the
ProxyJumpchain, so this one's diff will shrink once that lands.The bug
Only the target's
ProxyJumpwas read:A jump host that declares a
ProxyJumpof its own was therefore contacted directly. When that host is only reachable through its own proxy, the connection fails.That's the rest of #109. With its config, reaching
teneedsfirst -> second -> te, but onlysecondwas in the chain and it was dialed directly, which is whyfirstandsecondconnect on their own whiletedoesn't. (#337 covers the other half of that report — the target'sPortleaking into the first hop.)The chain is now expanded depth first, so the hops a jump host depends on are connected to before it, matching how ssh re-reads the config for each hop it opens.
A config that jumps back to a host already being resolved is reported rather than recursed into, and a chain longer than 10 hops is refused.
Tests
test/resolve-proxy-jumps.test.ts— 10 unit tests: ordering, blank entries, one and several levels of nesting, per-entry expansion of a list, the config carried for each hop,user@host:portin the value, self loop, two host loop, over long chaintest/nested-proxy-jump.test.ts— e2e over three containers. Only the first is published; the second and the target are reachable solely inside the network, so the whole chain has to be walked. It fails onmasterwithgetaddrinfo ENOTFOUNDfor the middle hop.Full suite passes locally (23 tests).