Bug#1074766: openssh-server: upgrading to openssh-server (1:9.2p1-2+deb12u3) resets /etc/ssh/sshd_config file without any prompt

I might have an idea of what could have happened: how does the packager
know that the file is different from the previous package's default version?

While I upgraded other packages on another server today I noticed something
in my own behaviour: when there are modifications on a package file and I'm
asked what I want to do I always choose to open a terminal, then I use
vimdiff to merge the differences but sometimes, depending on the amount of
changes, I will pull the changes inside the new version, save that version,
exit the terminal and then choose "Install the maintainer's version"
(knowing that I modified it with the changes I wanted to keep)... So if the
packager uses the modified file stats/content as a basis it might explain
why it didn't prompt me... Could that be it?

On Tue, Jul 2, 2024 at 5:50 PM John Wellesz <[email protected]> wrote:

> Hello Colin,
>
> Here is the output of apt/term.log:
>
> Log started: 2024-07-02  00:04:13
> (Reading database ... 64456 files and directories currently installed.)
> Preparing to unpack .../openssh-sftp-server_1%3a9.2p1-2+deb12u3_amd64.deb
> ...
> Unpacking openssh-sftp-server (1:9.2p1-2+deb12u3) over (1:9.2p1-2+deb12u2)
> ...
> Preparing to unpack .../openssh-server_1%3a9.2p1-2+deb12u3_amd64.deb ...
> Unpacking openssh-server (1:9.2p1-2+deb12u3) over (1:9.2p1-2+deb12u2) ...
> Preparing to unpack .../openssh-client_1%3a9.2p1-2+deb12u3_amd64.deb ...
> Unpacking openssh-client (1:9.2p1-2+deb12u3) over (1:9.2p1-2+deb12u2) ...
> Setting up openssh-client (1:9.2p1-2+deb12u3) ...
> Setting up openssh-sftp-server (1:9.2p1-2+deb12u3) ...
> Setting up openssh-server (1:9.2p1-2+deb12u3) ...
> Replacing config file /etc/ssh/sshd_config with new version
> rescue-ssh.target is a disabled or a static unit not running, not starting
> it.
> ssh.socket is a disabled or a static unit not running, not starting it.
> Processing triggers for man-db (2.11.2-2) ...
> Processing triggers for ufw (0.36.2-1) ...
> Log ended: 2024-07-02  00:04:16
>
> I've attached the sshd_config from my last week backup, I've just changed
> the port number I use to a random one.
>
> I had the same problem on 4 different servers I upgraded last night. Maybe
> it's not related to openssh-server and I just noticed the problem on this
> package...
>
> Also note that I've recently enabled apt-listchange prompting on all these
> servers:
>
> cat /etc/apt/listchanges.conf
> [apt]
> frontend=pager
> which=both
> email_address=root
> email_format=html
> confirm=true
> headers=false
> reverse=false
> save_seen=none
> no_network=false
>
> Here is the command I used to check and apply security updates:
>
> sudo apt update && sudo apt dist-upgrade -V && sudo apt autoremove -y
>
> Regards,
>
> John Wellesz
>
> On Tue, Jul 2, 2024 at 5:24 PM Colin Watson <[email protected]> wrote:
>
>> On Tue, Jul 02, 2024 at 03:05:16PM +0000, John Wellesz wrote:
>> > I used apt upgrade to install the security update available for
>> >   openssh-server
>> >
>> >    * What was the outcome of this action?
>> >
>> > It overwrote /etc/ssh/sshd_config without promtping, erasing the custom
>> settings
>> > and almost locking me out as a result (my custom port setting was gone
>> > as well as other changes I've made).
>> >
>> >    * What outcome did you expect instead?
>> >
>> > I expected to receive the usual prompt when a configuration file is
>> > modified asking me what I want to do but there was none.
>>
>> We'll need to be able to reproduce this problem before being able to do
>> anything about it.  (I have a modified /etc/ssh/sshd_config on my own
>> stable system and it wasn't overwritten on upgrade.)
>>
>> Can you please provide a copy of your modified /etc/ssh/sshd_config,
>> along with the output of the relevant apt run (which should be preserved
>> in /var/log/apt/term.log)?
>>
>> --
>> Colin Watson (he/him)                              [[email protected]]
>>
>