AW: openssh-unix-dev Digest, Vol 205, Issue 26

[Warlich, Christof]

Hi Peter,

Peter Stuge <peter at stuge.se> wrote:

> Warlich, Christof wrote:
> > Instead of just trying to resolve one in the list of potential fully
> > qualified hostnames locally (which cannot work as the host is only
> > known in some remote subnet accessible through the ProxyJump command),
> > the command defined in ProxyJump should be used to resolve the fully
> > qualified hostname in that remote subnet.
>
> Please compare the ProxyJump and ProxyCommand options.
>
> Note that ProxyJump is shorthand for one particular (common) ProxyCommand pattern,
> and also note that ProxyCommand has rather limited semantics - nothing that allows explicit
> name resolution other than the one-shot attempt to connect to a destination,
> and waiting for success or timeout.

> My point is that neither ProxyJump nor ProxyCommand describe a command that executes
> remotely, they both result in an extra command being executed locally, on the initial client.

> That command (ssh -W) instructs the jumphost sshd to connect to the given destination by
> way of a "direct-tcpip" channel, and the destination sent in that CHANNEL_OPEN request is
> either what the user typed in the original client command or a configured HostName.

Thanks for the clarification: As I understand, ProxyCommand (and thus, ProxyJump) may
not be "misused" to do some hidden extra functionality that is just only needed for the
particular use case that I'm interested in.

Anyhow, the hacks suggested by raf and Jö Fahlke are good enough to cope with the situation,
so there is not really too much need from my side for a fully worked out solution.

But as, on the other hand, that use case is probably not too uncommon in "every day" ssh
usage, I wonder if it wouldn't be worth to consider a new option, e.g. something like
CanonicalProxy, that may be set to a jumphost and that allows to test the resolvability
of a host from that jumphost.

And finally, I'm _really_ curious w.r.t. the difference in functionality of "CanonicalizeHostname yes"
and "CanonicalizeHostname always". As the documentation is quite unspecific on that, I was just
hoping that the latter was _intended_ to switch on the hidden extra functionality that I was suggesting
for ProxyJump (and ProxyCommand). Then, depending on what "CanonicalHostname always"
might really be useful for, it may be a decent idea to extend its semantics to allow _it_
(instead of a newly invented CanonicalProxy option) to be set to a jumphost in addition to
"yes", "no" and "always".

Cheers,

Chris