Re: [SOLVED] Re: old entries in sources.list?

[Andy Smith <andy@strugglers.net>]

Hi,

On Fri, Jun 20, 2025 at 01:23:13PM -0400, Greg Wooledge wrote:
> In the specific case of /etc/ssh/sshd_config.d/, the man page is
> pretty explicit:
> 
>      Note that the Debian openssh-server package sets several options as stan‐
>      dard in /etc/ssh/sshd_config which are not the default in sshd(8):
> 
>            •   Include /etc/ssh/sshd_config.d/*.conf
>            •   KbdInteractiveAuthentication no
>            •   X11Forwarding yes
>            •   PrintMotd no
>            •   AcceptEnv LANG LC_*
>            •   Subsystem sftp /usr/lib/openssh/sftp-server
>            •   UsePAM yes
> 
>      /etc/ssh/sshd_config.d/*.conf files are included at the start of the con‐
>      figuration file, so options set there will override those in
>      /etc/ssh/sshd_config.
> 
> To be completely transparent here, I'd never even *heard* of this until
> you mentioned it earlier in this thread.  This is completely new to me.
> The fact that it's a Debian change is probably why I couldn't find it
> in the OpenSSH web site's release notes, which is where I looked before
> trying "man sshd_config" on Debian.

You may be putting too much stress on "a Debian change" here. There
isn't anything code-wise specific to Debian, only the fact that Debian
ships with the above configuration directives already there while the
upstream sshd_config doesn't.

I think the main reason why this note exists is to inform about the
behaviour of the .d directory, because OpenSSH's configuration is a bit
unorthodox in that it is usually first-match-wins, i.e. the .d inclusion
has to happen at the top so that it is even possible to override
anything that appears below the inclusion in sshd_config.

So I think this note is important to inform about some directives that
may at first glance look like they needed to be removed or overridden in
sshd_config but can in fact be overridden in a file inside
/etc/ssh/sshd_config.d/.

Other than that, as far as I am aware the OpenSSH packaging on Debian
remains silent on where admins' local modification SHOULD be made, so I
am generally in agreement with you.

I also want to note that I agree that Debian's handling of modified
config files has always (for literally decades) been designed to support
and help with merging local modifications to config files. It has always
been much more advanced than support in other distributions.

There have even been some arguments that the relatively recent trend of
providing .d directories and support for config fragment inclusion has
been added predominantly by software coming from distribution ecosystems
that lack decent support for config file upgrades, as their means of
handling that deficiency. I don't know how much I agree with that as,
even in Debian, it is an issue that it is forbidden by policy for one
package to meddle with the configuration files of another package, so
config file fragments were a way to solve that one.

But all that is to say that, we've been upgrading and merging old config
files for decades; some packages still do not support the concept of .d
config directories; even amongst those that do, in Debian there is
usually nothing saying where one SHOULD make edits, only that the
facility exists if you want it.

Personally I find the .d directory mechanism a mixed blessing. It is
handy for config management (by a tool) but it doesn't remove the need
to have to carefully check through any configuration changes *anyway*,
because I still need to know what I am or am not overriding! For example
if I override a setting in a config fragment, I don't want to miss when
the opposite setting gets added to the main distributed config file with
a warning next to it saying, "never change this, it will cause demons to
fly out of your nose".

As far as I am concerned the "correct" place to make changes is of local
concern while understanding the trade-offs of the choice.

I think a better exemplar of this trend could be something like apache2
rather than openssh-server. In Debian we are all used to putting config
fragments in the {conf,mods,sites}-available directories and then using
the tools to enable or disable those config fragments. I haven't looked
if Debian's package documentation says this is how it SHOULD be done but
in this package's case it has so many advantages that it would be a bit
odd not to. Nevertheless, I am sure some are still putting their edits
directly into /etc/apache2/apache.conf.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting