openssh bugs - Aug 2024 - [Bug 3726] New: `Include` in a file included in a Host-block

https://bugzilla.mindrot.org/show_bug.cgi?id=3726

            Bug ID: 3726
           Summary: `Include` in a file included in a Host-block
           Product: Portable OpenSSH
           Version: 9.8p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: calestyo at scientia.org

Hey.

I've recently stumbled over the systemd-ssh-generator feature and it's
friend /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf which is per
default Included in many ssh_configs.
Not so in mine, where I only explicitly include files and not glob
patters from the /etc/ssh/sshd?_config.d directories .

So I've added a manual Include
/etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf in my .ssh/config

And whether that worked depend upon whether I included it either in the
very top of the file (which I assume is as it's in a Host * block) or
in an explicit Host * block.

If I included it "in" another block it didn't work.



Now that's in principle documented in ssh_config(5) in the Include
directive, but what's not mentioned there and IMO ambiguous is:
What if the included file (here
/etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf) contains itself a Host
block?

It does *not* seem - as one would expect - that these actually start a
new Host block, but instead they seems to be accounted for the one in
which the file is included.

Either that's a bug, or there should IMO at least be some warning, that
the whole (included) block will be ignored, or it should be documented
that there are "sub" Host blocks (which I think there are not).

Cheers,
Chris.

btw. 20-systemd-ssh-proxy.conf:
Host unix/* vsock/*
        ProxyCommand /usr/lib/systemd/systemd-ssh-proxy %h %p
        ProxyUseFdpass yes
        CheckHostIP no

        # Disable all kinds of host identity checks, since these
addresses are generally ephemeral.
        StrictHostKeyChecking no
        UserKnownHostsFile /dev/null

# Allow connecting to the local host directly via ".host"
Host .host
        ProxyCommand /usr/lib/systemd/systemd-ssh-proxy
unix/run/ssh-unix-local/socket %p
        ProxyUseFdpass yes
        CheckHostIP no

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3726

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
This behaviour is completely intentional and is documented in the
manual page:
> An Include directive may appear inside a Match block to 
> perform conditional inclusion.
Having Match blocks within a conditionally-included file override the
Match that originally included them would be very surprising and
difficult to reason about.

As it operates now, both Match blocks (the one in the top-level file
and the one in the included file) need to evaluate to true for the
their configuration to apply. IMO this is the safest, easiest to reason
about and most expressive option.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3726

--- Comment #2 from Christoph Anton Mitterer <calestyo at scientia.org>
---
I agree that it's the most expressive handling.

But I still don't think it's obvious from the documentation what
actually happens.

As you quoted, the docs *do* say that the Include directive may appear
within Host/Match.

But semantically it's still only documented as "inclusion" - most
people will think of that as a literal copy&pasting of the included
file's contents to the location where it's included.

That means that for most people it will be clear that e.g. a directive
like User will be evaluated within the current Host/Match block.

But if the content would be literally copied and pasted, the Host/Match
block from the included file, would start a new such block - and not be
like a sub-block of the current one.

So I think that should merely be documented, i.e.
- telling that included Host/Match blocks will be like sub-blocks of
that block in which they are included
- perhaps indicating that one can always make a Host * block to get
inclusion on the top-level
- giving an example how a sub block would work (and that that is only
possible via inclusion, I guess), like in:
Host *.example.com
   Include foo.conf

foo.conf
Host *.example.org
   # will never match
Host foo.example.com
   # may match

Cheers,
Chris.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3726

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
Current behaviour can't really change and is adequately documented IMO

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.