Bug#1109742: upgrade-reports: No new SSH connections possible during large part of upgrade to Debian Trixie

On Tue, Jul 22, 2025 at 07:42:07PM +0200, Manfred Stock wrote:
>Further Comments/Problems: I've upgraded several Bookworm systems to
>Trixie so far, which went pretty smooth. But there's one thing I keep
>noticing, and which I observed a bit more closely while upgrading the
>system I'm sending this report from: Starting at roughly the time when
>dpkg says something like
>
>  Unpacking openssh-server (1:10.0p1-5) over (1:9.2p1-2+deb12u6) ...
>
>I'm not able anymore to open new SSH connections to the system I'm
>upgrading. The SSH daemon is still running, and the existing connections
>also still work, but new connections fail with
>
>  kex_exchange_identification: read: Connection reset by peer
>  Connection reset by fd... port 22
>
>on the client. At this time, I see messages like the following in the
>output from `systemctl status openssh-server.service` (the SSH daemon is
>still running, usually since the last reboot, or in this case since the
>libc upgrade earlier during the upgrade process, so the daemon process
>itself should still be running the binaries from Bookworm, even though
>the new binaries have already been extracted):
>
>  Jul 22 17:37:32 monitoring sshd[492742]: -R not supported here
[...]
>To me, it seems like the old binary, which is still running, is passing
>an unsupported parameter to the new binary that was already unpacked
>when trying to fork off a new process for the new connection (but I
>haven't checked if that's how it actually works when a new connection is
>opened, I'm just guessing). The "-R not supported here" string seems to
>be 'new', i.e. I didn't find it in the openssh package source on
>Bookworm, but it exists in the version from Trixie.

Thanks for the report.  This will be due to the split of sshd-session 
from the main sshd binary; the old sshd re-executed itself with 
different arguments, but the new sshd executes sshd-session instead and 
has removed support for the parameters that it used to rely on during 
re-execution.

I'll have to set up a suitable environment to test this, but my best 
idea for now is to have openssh-server.preinst take a copy of the old 
sshd binary before dpkg unpacks the new files, and patch sshd to re-exec 
that copy if it exists and it receives the -R option.  The postinst can 
then remove the copy after it's restarted the new sshd.

Tricky!