The new openssh works just fine and this is just a little note to those of us with remote machines. After updating both client and remote machine(s) its important to restart sshd. If you don't restart sshd, and then attempt to ssh into the remote, it may fail with: kex_exchange_identification: read: Connection reset by peer -- Gene
On Mon, Jul 01, 2024 at 06:36:50 -0400, Genes Lists wrote:
After updating both client and remote machine(s) its important to restart sshd.
If you don't restart sshd, and then attempt to ssh into the remote, it may fail with:
kex_exchange_identification: read: Connection reset by peer
More specifically, the upgraded server logs the following: sshd: -R not supported here (when forked by a not-restarted master process) I can't immediatly spot in the ChangeLog what is causing this, but it certainly warrants a big post_upgrade warning in the openssh package. I created an issue for that: https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5 Geert
On Mon, Jul 01, 2024 at 12:59:05 +0200, Geert Hendrickx wrote:
More specifically, the upgraded server logs the following: sshd: -R not supported here
(when forked by a not-restarted master process)
I can't immediatly spot in the ChangeLog what is causing this, but it certainly warrants a big post_upgrade warning in the openssh package.
It's due to this change, sshd now invokes an sshd-session handler instead, for which the master process MUST be restarted: https://www.openssh.com/releasenotes.html#9.8p1
* sshd(8): the server has been split into a listener binary, sshd(8), and a per-session binary "sshd-session". This allows for a much smaller listener binary, as it no longer needs to support the SSH protocol. As part of this work, support for disabling privilege separation (which previously required code changes to disable) and disabling re-execution of sshd(8) has been removed. Further separation of sshd-session into additional, minimal binaries is planned for the future.
(it's probably advised to restart sshd immediatly after every upgrade, but the package should point this out as Arch does not automate this.) Geert
(…) If you don't restart sshd, and then attempt to ssh into the remote, it may fail with: (…) Note that one *must* restart sshd regardless. Updating the files isn’t fixing the vulnerability. The old, vulnerable version of the process is still running until the service is restarted.
Cheers
On Mon, 1 Jul 2024 20:57:31 +0200
mpan
(…) If you don't restart sshd, and then attempt to ssh into the remote, it may fail with: (…) Note that one *must* restart sshd regardless. Updating the files isn’t fixing the vulnerability. The old, vulnerable version of the process is still running until the service is restarted.
Cheers
That's outside the scope of the issue being discussed here, though. Not all ssh servers are publicly accessible, making the vulnerability much less of a concern.
On 7/1/24 05:36, Genes Lists wrote:
The new openssh works just fine and this is just a little note to those of us with remote machines.
After updating both client and remote machine(s) its important to restart sshd.
If you don't restart sshd, and then attempt to ssh into the remote, it may fail with:
kex_exchange_identification: read: Connection reset by peer
Thank you Genes, All, The Recent News feed and the discussion here is appreciated. This greatly reduces the chance somebody remote admissing a box is caught by the update. Works as advertised. Update openssh, restart sshd -- all good. -- David C. Rankin, J.D.,P.E.
participants (5)
-
David C. Rankin
-
Doug Newgard
-
Geert Hendrickx
-
Genes Lists
-
mpan