openssh bugs - Jul 2024 - [Bug 3706] New: Support upgrading sshd without restarting the server

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.

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

--- Comment #1 from Dominique Martinet <gmveqfhbronz.anqzf_ at
noclue.notk.org> ---
Replying to myself for the first point:
> Can you think of a way to do handle just exactly +1 version upgrade (9.7p1
-> 9.8p1) more smoothly
I looked a bit more and rather than just the path change the problem
would be this protocol change:
        /*
         * Protocol from reexec master to child:
         *      string  configuration
+        *      uint64  timing_secret
+        *      string  host_keys[] {
+        *              string private_key
+        *              string public_key
+        *              string certificate
+        *      }
         *      string  included_files[] {
         *              string  selector
         *              string  filename

so I don't see any remotely clean way of doing that for this particular
update.

Unless there's a great idea somewhere, let's focus this bz about
further updates -- it doesn't make sense to freeze this protocol in my
opinion but perhaps add a version field first the next time there's a
breakage, so at least n->n+1 might be handled.

Thanks

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

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|-current                    |9.8p1
                 CC|                            |dtucker at dtucker.net

--- Comment #2 from Darren Tucker <dtucker at dtucker.net>
---
> (meta: There's no version 9.8p1 in the bug tracker yet so selected
-current)
fixed.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

gky44px1999 at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gky44px1999 at gmail.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
                 CC|                            |djm at mindrot.org
             Status|NEW                         |RESOLVED

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
Sorry, but the interprocess stuff is complicated enough without having
to manage support for legacy versions there too. Moreover, it's almost
all privileged code so we absolutely want simplicity there.

IMO is quite reasonable to require a restart after a daemon has been
upgraded and to consider buggy any package management/administrative
process that fails to do this.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

--- Comment #4 from Dominique Martinet <gmveqfhbronz.anqzf_ at
noclue.notk.org> ---
> Sorry, but the interprocess stuff is complicated enough without having to
manage support for legacy versions there too. Moreover, it's almost all
privileged code so we absolutely want simplicity there.
That's fair, thanks for having taken the time to reply.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.