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 <john.well...@gmail.com> 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 <cjwat...@debian.org> 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) [cjwat...@debian.org] >> >
