[Bug 3706] New: Support upgrading sshd without restarting the server

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3706

            Bug ID: 3706
           Summary: Support upgrading sshd without restarting the server
           Product: Portable OpenSSH
           Version: -current
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: gmveqfhbronz.anqzf_ at noclue.notk.org

Upgrading sshd-portable from 9.7p1 or earlier to 9.8p1 changes how sshd
handles new sessions: sshd used to re-exec `sshd -R` and now execs into
`sshd-session -R`

This binary separation is very welcome and reduces attack surface, but
some distros do not restart services on upgrades, so users can get
locked out after upgrade:
 - alpine
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68482#note_417613
 - arch
https://archlinux.org/news/the-sshd-service-needs-to-be-restarted-after-upgrading-to-openssh-98p1/
//
https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5
 - (gentoo apparently used not to restart but now does, so that's a
non-issue)

This was also known during devlopment but I assume that was not
considered a problem because openssh would get restarted on normal
upgrades in OpenBSD as well:
https://github.com/openssh/openssh-portable/commit/03e3de416ed7c34faeb692967737be4a7bbe2eb5
> NB. if you're updating via source, please restart sshd after installing,
> otherwise you run the risk of locking yourself out.



In theory it'd be possible for the new sshd to handle -R as "oh I was
run from an old version, let's re-exec sshd-session again" and do
whatever is needed here, without including the sshd-session code into
the sshd binary.

In practice I tried and it's not just re-exec, we need to setup file
descriptors properly and whatever else older versions weren't doing the
same way, I'm not sure the new sshd can even tell which version it was
re-excuted from in the first place so that setup might not even be
possible...

So this bz is double:
- Can you think of a way to do handle just exactly +1 version upgrade
(9.7p1 -> 9.8p1) more smoothly? Some systems might not be rebooted in
ages and if we allow upgrades without restarts there will always be
someone who keeps a very old sshd acceptor daemon running, but if we
keep things up to date and print a warning when the listener isn't
current that should be minimal enough.

- Could we try to keep the architecture in a way that allows this again
in the future, or is that not worth the effort for you?
(That means somewhat standardizing what sshd-session -R expects from
sshd for the session hand-off)


Thank you!

(meta: There's no version 9.8p1 in the bug tracker yet so selected
-current)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.