Hi,

this just bit me on current stable (Buster) while updating from the
security repo:

The following packages will be upgraded:
   openssh-client (1:7.9p1-10 => 1:7.9p1-10+deb10u1)
   openssh-server (1:7.9p1-10 => 1:7.9p1-10+deb10u1)
   openssh-sftp-server (1:7.9p1-10 => 1:7.9p1-10+deb10u1)
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1.178 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://security.debian.org/debian-security buster/updates/main amd64
openssh-sftp-server amd64 1:7.9p1-10+deb10u1 [44,6 kB]
Get:2 http://security.debian.org/debian-security buster/updates/main amd64
openssh-server amd64 1:7.9p1-10+deb10u1 [352 kB]
Get:3 http://security.debian.org/debian-security buster/updates/main amd64
openssh-client amd64 1:7.9p1-10+deb10u1 [782 kB]
Fetched 1.178 kB in 0s (4.945 kB/s)
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 498927 files and directories currently installed.)
Preparing to unpack .../openssh-sftp-server_1%3a7.9p1-10+deb10u1_amd64.deb ...
Unpacking openssh-sftp-server (1:7.9p1-10+deb10u1) over (1:7.9p1-10) ...
Preparing to unpack .../openssh-server_1%3a7.9p1-10+deb10u1_amd64.deb ...
Unpacking openssh-server (1:7.9p1-10+deb10u1) over (1:7.9p1-10) ...
Preparing to unpack .../openssh-client_1%3a7.9p1-10+deb10u1_amd64.deb ...
Unpacking openssh-client (1:7.9p1-10+deb10u1) over (1:7.9p1-10) ...
Setting up openssh-client (1:7.9p1-10+deb10u1) ...
Setting up openssh-sftp-server (1:7.9p1-10+deb10u1) ...
Setting up openssh-server (1:7.9p1-10+deb10u1) ...
Replacing config file /etc/ssh/sshd_config with new version
rescue-ssh.target is a disabled or a static unit, not starting it.
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for systemd (241-7~deb10u1) ...

The important line is the forth from the bottom.
Since I have changed the port of SSHD this makes it impossible to
open new connections afterwards. I can't believe that making computers
secure by essentially disconnecting their admins is the desired behavior
of this package (update). Arguably, changing the port back to its default
(as in my case) might even increase security risks. ;)
AFAIK there is no way to override the settings from the standard
config file (by files in a *.d directory as requested in other bug
reports). If there is no other (well-documented) workaround I strongly
consider this behavior a bug.

This hit me this weekend, courtesy of the Debian 12.1 to 12.2 point upgrade.
That upgraded openssh-server from 1:9.2p1-2 to 1:9.2p1-2+deb12u1.

I had made some changes to /etc/ssh/sshd_config in March 2018 (Debian 9.4), one of which moved the default port to 2222.  This was to make port 22 available for use by a Docker-based GitLab instance.

I have been following point upgrades since then through 9.13, jumped to 10.6, point upgrades through 10.11, jumped to 11.2, point upgrades through 11.7.  All without making any manual changes to sshd_config.

I integrated upstream sshd_config changes when I manually upgraded the host to Debian 12.1 (from 11.7) in August 2023.  At that time I did not move my customizations to use the new /etc/ssh/sshd_config.d/* support.

The point upgrade was performed by unattended-upgrades on 2023-10-08 and the machine was automatically rebooted on 2023-10-09.  The SSH daemon was started first, preventing the GitLab instance from starting.  Seeing that, I tried to login remotely via port 2222 and got a connection refused.  Yikes!

Fortunately, the logcheck reports in my mailbox pointed out the GitLab could not bind to port 22, giving me a clue that I could probably SSH in on that port.  Fortunately that worked and I was able to get things back to working order via that remote login.

I have not been able to find any notice of this in the Debian 12 release notes or the /usr/share/doc/openssh-server/{NEWS,README}.Debian.gz files and was therefore very unpleasantly surprised by this behavior.

FWIW, my /var/cache/debconf/config.dat contains

  Name: openssh-server/password-authentication
  Template: openssh-server/password-authentication
  Value: false
  Owners: openssh-server

  Name: openssh-server/permit-root-login
  Template: openssh-server/permit-root-login
  Value: true
  Owners: openssh-server

but I manually edited sshd_config to use

  PermitRootLogin no

as well as

  Port 22

Cross-checking with /var/cache/debconf/templates.dat, it appears I used dpkg-reconfigure to change password-authentication to end up with

  PasswordAuthentication no

in my sshd_config.

The openssh-server.postinst appears to be responsible for "clobbering" my customizations (via ucf) but I don't see any differences to that file between the old and new versions, making me wonder why this hasn't hit me before.

I'll be syncing the openssh-server debconf answers with what I have in my sshd_config and move out any other customizations to /etc/ssh/sshd_config.d/* snippets but thought this might be of use to others.

That should have been

  Port 2222

Additionally, when I reviewed the `permit-root-login` debconf settings against the postinst I got a bit confused.

In `create_sshdconfig` it says

        if [ "$permit_root_login" != true ]; then
                sed -i 's/^#*PermitRootLogin .*/PermitRootLogin yes/' \
                        "$new_config"
        fi

My debconf setting for `$permit_root_login` is `true` so the `$new_config` is left untouched and has a

  #PermitRootLogin  prohibit-password

It took me a second think to realize that `prohibit-password` still permits root logins.
However, what left me dumb-founded was that if I were to change `permit-root-login` to any value other then `true`, even `false` or `no` (debconf says it's a boolean), that that would change `$new_config` to have

  PermitRootLogin yes

FWIW, PermitRootLogin supports four values.

I find the debconf/postinst behavior *very* unintuitive, so I didn't change my debconf answers and put

  PermitRootLogin no

in a `/etc/ssh/ssdh_config.d/*.conf` snippet so it takes precedence, per `man 5 sshd_config`, no matter how the postinst changes the `$new_config`.