openssh unix dev - May 2020 - AW: AW: CanonicalHostname and ssh connections through a jumphost

raf wrote:
> Warlich, Christof wrote:
> > ...
> > I want to be able to ssh to all internal hosts that live in the
internal.sub.domain.net,
> > i.e. that are only accessible through the internal.sub.domain.net
jumphost without
> > having to list each of these hosts somewhere, as they may frequently
be added or
> > removed from the internal domain and without being forced to always
type their
> > fully qualified hostnames.
> If you are invoking ssh from a shell, you could define a short variable for
the internal
> domain and append that to the relevant hostnames:
> 
> e.g. in your ~/.bashrc or similar:
> 
>     i=".internal.sub.domain.net"
> 
> Then, on the command line:
> 
>     ssh foo$i
> 	ssh bar$i
> 
> At least until a better solution comes along.
> It's not perfect but it's only 2 extra characters on the command
line.
Thanks, I like this kind of "out of the box" thinking ??.

But it seems that we agree that this is a hack. From my rather na?ve point of
view, "fixing" the
behavior of CanonicalHostname in the presence of a ProxyJump would be most
desirable:
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.

What do you think: Could this be something worth to be considered?

Cheers,

Chris

On 20/05/2020 08:11, 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.
That sounds like a chicken-and-egg situation. You have:

host *.example.com
 ? ProxyJump blah

but you don't know that you should use this entry until you know that 
the unqualified name can be qualified to *.example.com.

ISTM that if you want the ProxyJump host to work that way, you'd have to 
try every ProxyJump entry in the file, and ask them in turn to resolve 
the name until you find one that works.

Hi Brian,

Brian Candler wrote:
> On 20/05/2020 08:11, 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.
>
> That sounds like a chicken-and-egg situation. You have:
>
> host *.example.com
>    ProxyJump blah
>
> but you don't know that you should use this entry until you know that
the unqualified name can be qualified to *.example.com.
>
> ISTM that if you want the ProxyJump host to work that way, you'd have
to try every ProxyJump entry in the file, and ask them in turn to resolve the
name until you find one that works.
This seems to be a misunderstanding: Yes, there would be a chicken-egg situation
if the ProxyJump command would only know an unqualified hostname, like
"blah" in your example. But that's not what I'm heading for:
To recap a part from my initial post on that topic, I am thinking of an ssh
config like this:

        CannonicalizeHostname always
        CannonicalDomains internal.sub.domain.net
        Host *.internal.sub.domain.net
                        ProxyJump internal.sub.domain.net

        But this would only work if the name lookup for the host that is to be
connected succeeds.
        But as these hosts are internal by definition, it is no surprise that
name resolution fails.

        A not really helpful but very illustrative hack is to fake successful
name resolutions by just
        adding all the internal hosts as aliases for e.g. 127.0.0.1 to
/etc/hosts, i.e. adding the following
        line to /etc/hosts:

        127.0.0.1 foo.internal.sub.domain.net bar.internal.sub.domain.net

        With that line in place, the last ~/.ssh/config works like a charm. But
apart from the fact that
        this would be quite a hack, it just only shifts the maintenance issue
form ~/.ssh/config to /etc/hosts.

As can be seen, there was no intent or reason to have an unqualified hostname in
ProxyJump. Instead, say there is an internal host named foo (i.e.
foo.internal.sub.domain.net), I want to be able to ssh to it by just typing
"ssh foo", which currently does not work because ssh tries to resolve
foo.internal.sub.domain.net _locally_, where is not known by definition, instead
of using the "directions" given in ProxyJump.

On 20/05/2020 09:58, Warlich, Christof wrote:
>> That sounds like a chicken-and-egg situation. You have:
>>
>> host *.example.com
>>     ProxyJump blah
>>
>> but you don't know that you should use this entry until you know
that the unqualified name can be qualified to *.example.com.
>>
>> ISTM that if you want the ProxyJump host to work that way, you'd
have to try every ProxyJump entry in the file, and ask them in turn to resolve
the name until you find one that works.
> This seems to be a misunderstanding: Yes, there would be a chicken-egg
situation if the ProxyJump command would only know an unqualified hostname, like
"blah" in your example. But that's not what I'm heading for
> ...
> there was no intent or reason to have an unqualified hostname in ProxyJump
Sorry, that bit was just my laziness in typing.? Pretend that I had written:

host *.example.com
 ??? ProxyJump blah.some.random.domain

or

host *.example.com
 ??? ProxyJump proxy.example.com

The argument would be the same.? If you try to ssh to an unqualified 
host like "foo", then you don't know that it might be resolvable
via the
given ProxyJump host until you first know that it matches *.example.com 
- a circular dependency.

Regards,

Brian.

Brian Candler <b.candler at pobox.com> wrote:
>
> host *.example.com
>   ProxyJump proxy.example.com
>
> The argument would be the same.  If you try to ssh to an unqualified
> host like "foo", then you don't know that it might be
resolvable via
> the given ProxyJump host until you first know that it matches
> *.example.com - a circular dependency.

Ok, let me try to understand why you think this might be a circular dependency.

First, let's complete your example:

CanonicalizeHostname always
CanonicalDomains example.com

Host *.example.com

ProxyJump proxy.example.com

Currently, with this in place, when I do "ssh foo", ssh tries to
resolve foo.example.com _locally_ and fails. It never looks at the fact that,
for the section "Host *.example.com", a ProxyJump has been defined.
But, "CanonicalizeHostname always", as opposed to CanonicalizeHostname
yes", seems to be indicating that a special treatment is performed  for
proxied connections as described in the ssh_config man-page:



If CanonicalizeHostname is set to always, then canonicalization
is applied to proxied connections too.



Thus, I would consider it to be reasonable behavior if ssh would (_if_
CanonicalizeHostname is set to always) just _use_ the ProxyJump command related
to that section to test if the foo.example.com host is resolvable (from within
the example.com subnet).

Cheers,



Chris

On 20/05/2020 11:25, Warlich, Christof wrote:
>
> Ok, let me try to understand why you think this might be a circular 
> dependency.
>
> First, let?s complete your example:
>
> CanonicalizeHostname always
> CanonicalDomains example.com
>
> Host *.example.com
>
> ProxyJump proxy.example.com
>
> Currently, with this in place, when I do ?ssh foo?, ssh tries to 
> resolve foo.example.com _/locally/_ and fails. It never looks at the 
> fact that, for the section ?Host *.example.com?, a ProxyJump has been 
> defined. But, ?CanonicalizeHostname always?, as opposed to 
> CanonicalizeHostname yes?, seems to be indicating that a special 
> treatment is performed? for proxied connections as described in the 
> ssh_config man-page:
>
> If CanonicalizeHostname is set to always, then canonicalization
> is applied to proxied connections too.
>
I think the full context is needed:

 ???? CanonicalizeHostname
 ???????????? Controls whether explicit hostname canonicalization is 
performed.
 ???????????? The default, no, is not to perform any name rewriting and 
let the
 ???????????? system resolver handle all hostname lookups.? If set to 
yes then,
 ???????????? for connections that do not use a ProxyCommand or ProxyJump,
 ???????????? ssh(1) will attempt to canonicalize the hostname specified 
on the
 ???????????? command line using the CanonicalDomains suffixes and
 ???????????? CanonicalizePermittedCNAMEs rules.? If CanonicalizeHostname is
 ???????????? set to always, then canonicalization is applied to proxied 
con?
 ???????????? nections too.

The way I read this is:

1. *First* ssh decides which connection block the hostname matches (i.e. 
the Host xxx matching)

2. *Then* it performs canonicalization. It's performed if:
 ??? (a) CanonicalizeHostname is "always"; or
 ??? (b) CanonicalizeHostname is "yes" and there is no 
ProxyCommand/ProxyJump in the block

After canonicalization, it will match the blocks again:

 ???????????? If this option is enabled, then the configuration files 
are pro?
 ???????????? cessed again using the new target name to pick up any new 
config?
 ???????????? uration in matching Host and Match stanzas.

> Thus, I would consider it to be reasonable behavior if ssh would (_if_ 
> CanonicalizeHostname is set to always) just _/use/_ the ProxyJump 
> command related to that section to test if the foo.example.com host is 
> resolvable (from within the example.com subnet).
>
But in order to do that, I think it would have to establish an ssh 
connection to all the ProxyJump hosts in the config, until it hits on 
the right one.? Consider:

CanonicalizeHostname always

Host *.foo.com
 ? ProxyJump proxy.foo.com

Host *.bar.com
 ? ProxyJump proxy.bar.com

Host *.baz.com
 ? ProxyJump proxy.baz.com

Given bareword hostname "qux", currently it won't match any of
those
Host patterns.? I think you're asking it to try all the ProxyJump 
commands in turn, until it happens on one which is able to resolve the 
name.? That would involve opening up ssh connections to all the 
ProxyJump hosts in turn.? If not, what would you expect it to do?

If that's what you want, J? Fahlke gave a way to do that using Match ... 
host=... exec=...

Or to send all unqualified names to a single host:

Host !*.*? *
 ??? ProxyJump blah.whatever.com

Regards,

Brian.

Brian Candler <b.candler at pobox.com>  wrote:
> I think the full context is needed:
>
>      CanonicalizeHostname
>              Controls whether explicit hostname canonicalization is
performed.
>              The default, no, is not to perform any name rewriting and let
the
>              system resolver handle all hostname lookups.  If set to yes
then,
>              for connections that do not use a ProxyCommand or ProxyJump,
>              ssh(1) will attempt to canonicalize the hostname specified on
the
>              command line using the CanonicalDomains suffixes and
>              CanonicalizePermittedCNAMEs rules.  If CanonicalizeHostname is
>              set to always, then canonicalization is applied to proxied
con?
>              nections too.
>
> The way I read this is:
> 1. *First* ssh decides which connection block the hostname matches (i.e.
the Host xxx matching)
> 2. *Then* it performs canonicalization. It's performed if:
>     (a) CanonicalizeHostname is "always"; or
>     (b) CanonicalizeHostname is "yes" and there is no
ProxyCommand/ProxyJump in the block
>
> After canonicalization, it will match the blocks again:
>
> If this option is enabled, then the configuration files are pro?
> cessed again using the new target name to pick up any new config?
> uration in matching Host and Match stanzas.
>
> Christof Warlich wrote:
> > Thus, I would consider it to be reasonable behavior if ssh would
> > (_if_ CanonicalizeHostname is set to always) just _use_ the
> >  ProxyJump command related to that section to test if the
> > foo.example.com host is resolvable (from within the example.com
subnet).
>
> But in order to do that, I think it would have to establish an ssh
connection to all the ProxyJump hosts in the config, until it hits on the right
one.  Consider:
>
> CanonicalizeHostname always
>
> Host *.foo.com
>        ProxyJump proxy.foo.com
>
> Host *.bar.com
>         ProxyJump proxy.bar.com
>
> Host *.baz.com
>        ProxyJump proxy.baz.com
>
> Given bareword hostname "qux", currently it won't match any
of those Host patterns.
> I think you're asking it to try all the ProxyJump commands in turn,
until it happens on
> one which is able to resolve the name.  That would involve opening up ssh
connections
> to all the ProxyJump hosts in turn.
Yes, that?s exactly what I am asking for _if_ CaninicalizeHostname is set to
always. Wouldn?t
this be the most similar behavior to the ?ordinary? case, where all domains are
tried with the
qux hostname until one is found that has that host?
> If that's what you want, J? Fahlke gave a way to do that using Match
... host=... exec=...
>
> Or to send all unqualified names to a single host:
> Host !*.*  *
>         ProxyJump blah.whatever.com
>
Yes, J? Fahlke?s suggestions are definitely more than worth to be considered,
especially as (or until - ??)
ssh cannot do what I would really would have liked it to do.

Finally, the difference between ?CanonicalizeHostname yes? and
?CanonicalizeHostname always?
is a miracle to me, and I would very much appreciate an example where using
either of them
makes a difference.

Cheers,

Chris

Hi Christof,

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.


I hope this helps.

//Peter