sshd_config makes some changes awkward

[Kevin O'Gorman]

As distribted, the file sshd_config has apparently been modified from an upstream version -- those lines that are NOT comments. There is no good way for me to change any of them, even though there is a sshd_config.d directory for my changes. That is because the files in the sshd_config.d directory are invoked early, and the uncommented lines in the sshd_config file override them. I would have to modify the sshd_config file which defeats the purpose of having the directory.

I suggest to adopt a method that I have seen elsewhere: put all of your changes in a file and put the file in the .d directory. Start the filename with something like '50' so that it can sort before or after any file contributed by the local admin. Keep the sshd_config file as you get it from upstream.

This is, after all, the reason that the .d directories exist.

In this way, admins do not have to modify distributed files, which avoids awkwardness when the package is updated.

The same applies to ssh_config.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: openssh-server 1:8.2p1-4ubuntu0.5
ProcVersionSignature: Ubuntu 5.4.0-122.138-generic 5.4.192
Uname: Linux 5.4.0-122-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.11-0ubuntu27.24
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: XFCE
Date: Mon Jan 16 06:29:16 2023
SourcePackage: openssh
UpgradeStatus: Upgraded to focal on 2021-02-19 (696 days ago)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Robie Basak (racb)]

Thank you for your report. I agree.

When I wrote the TOTP/HOTP section in https://ubuntu.com/server/docs/service-openssh, I wanted to use sshd_config.d/ but was unable to instruct readers without also changing sshd_config directly, so I gave up on the former to keep the instructions simpler.

We're making progress at least though, in that now that we have the .d directory, defaults have somewhere to be moved to.

[Christian Ehrhardt  (paelzer)]

I agree as well, it is great that we have .d function at all, but it could be better.
As reported there is no control yet at what goes early or late and that would be a great enhancement. Just including it late isn't an easy option either as you might unintentionally to a different section that was at the end of the former config.

A bit of history:
- initially added via
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845315
  - https://salsa.debian.org/ssh-team/openssh/-/commit/cb37f2bf1
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862316
    (unclosed, but in theory adressed by the above)
- having some troubles to work
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961007
  - https://bugzilla.mindrot.org/show_bug.cgi?id=3122
- good but not yet as good as other .d config inclusions
  - this bug
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998834
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954965

Overall a problem that I see after going through all those is that some settings seem to be "the earliest set wins" so including at the top is good. And others are "overwritten by later statements" which asks for an inclusion at the end of the file.

This needs to be analyzed, maybe the behavior changed over time or there are different categories of settings? To do so I recommend to read through those bugs, some have more examples and how to debug them. Once that check is done one can propose a solution and it might very well be what Kevin suggested here which is to put the main config into the .d directory as well and include them in numerical order. That might not solve/address the behavior of different statements, but at least it would give full control to the admin without touching the package owned config file.

Either way this is worth having a look, but needs more time than a usual bug fix.
Therefore I've added it to a set of ideas that we pick the most important ones from each Ubuntu release cycle. If anyone else wants to tackle this before we get to it - great, keep the bug updated in that case.