[arch-dev-public] Urgent news item: sshd needs restarting after upgrading to openssh-8.2p1
Dear all, I'd like to post the following news item within the hour. ======== Title: sshd needs restarting after upgrading to openssh-8.2p1 Conent: After upgrading to openssh-8.2p1, the existing SSH daemon will be unable to accept new connections. When upgrading remote hosts, please make sure to restart the SSH daemon using `systemctl restart sshd` right after `pacman -Syu`. ======== I deeply regret not spotting this while the package was in [testing]. And I also regret not being able to diagnose what the exact problem is just now. Given time is of the essence, I propose posting the above news quickly even I don't consider it a very satisfying solution... Cheers. -- Gaetan
On 2/16/20 7:47 PM, Gaetan Bisson via arch-dev-public wrote:
Dear all,
I'd like to post the following news item within the hour.
========
Title: sshd needs restarting after upgrading to openssh-8.2p1
Conent: After upgrading to openssh-8.2p1, the existing SSH daemon will be unable to accept new connections. When upgrading remote hosts, please make sure to restart the SSH daemon using `systemctl restart sshd` right after `pacman -Syu`.
========
I deeply regret not spotting this while the package was in [testing]. And I also regret not being able to diagnose what the exact problem is just now. Given time is of the essence, I propose posting the above news quickly even I don't consider it a very satisfying solution...
Is it sufficient to add a post_upgrade message? -- Eli Schwartz Bug Wrangler and Trusted User
On Sun, Feb 16, 2020 at 07:51:19PM -0500, Eli Schwartz via arch-dev-public wrote:
On 2/16/20 7:47 PM, Gaetan Bisson via arch-dev-public wrote:
Dear all,
I'd like to post the following news item within the hour.
========
Title: sshd needs restarting after upgrading to openssh-8.2p1
Conent: After upgrading to openssh-8.2p1, the existing SSH daemon will be unable to accept new connections. When upgrading remote hosts, please make sure to restart the SSH daemon using `systemctl restart sshd` right after `pacman -Syu`.
========
I deeply regret not spotting this while the package was in [testing]. And I also regret not being able to diagnose what the exact problem is just now. Given time is of the essence, I propose posting the above news quickly even I don't consider it a very satisfying solution...
Is it sufficient to add a post_upgrade message?
The issue is that the package is already out iiuc. I had this issue but I blamed my wonky sshd configuration haha... -Santiago
[2020-02-16 19:53:53 -0500] Santiago Torres-Arias via arch-dev-public:
On Sun, Feb 16, 2020 at 07:51:19PM -0500, Eli Schwartz via arch-dev-public wrote:
On 2/16/20 7:47 PM, Gaetan Bisson via arch-dev-public wrote:
Dear all,
I'd like to post the following news item within the hour.
========
Title: sshd needs restarting after upgrading to openssh-8.2p1
Conent: After upgrading to openssh-8.2p1, the existing SSH daemon will be unable to accept new connections. When upgrading remote hosts, please make sure to restart the SSH daemon using `systemctl restart sshd` right after `pacman -Syu`.
========
I deeply regret not spotting this while the package was in [testing]. And I also regret not being able to diagnose what the exact problem is just now. Given time is of the essence, I propose posting the above news quickly even I don't consider it a very satisfying solution...
Is it sufficient to add a post_upgrade message?
The issue is that the package is already out iiuc.
Let's do both: announcement and new package with post_upgrade. Cheers. -- Gaetan
[2020-02-16 19:51:19 -0500] Eli Schwartz via arch-dev-public:
On 2/16/20 7:47 PM, Gaetan Bisson via arch-dev-public wrote:
Dear all,
I'd like to post the following news item within the hour.
========
Title: sshd needs restarting after upgrading to openssh-8.2p1
Conent: After upgrading to openssh-8.2p1, the existing SSH daemon will be unable to accept new connections. When upgrading remote hosts, please make sure to restart the SSH daemon using `systemctl restart sshd` right after `pacman -Syu`.
========
I deeply regret not spotting this while the package was in [testing]. And I also regret not being able to diagnose what the exact problem is just now. Given time is of the essence, I propose posting the above news quickly even I don't consider it a very satisfying solution...
Is it sufficient to add a post_upgrade message?
Probably, yes but then we'd need a new package out of [testing] fast. And users might complain that the post_upgrade message wasn't visible enough... :) Cheers. -- Gaetan
On 2/16/20 7:54 PM, Gaetan Bisson wrote:
Is it sufficient to add a post_upgrade message?
Probably, yes but then we'd need a new package out of [testing] fast. And users might complain that the post_upgrade message wasn't visible enough... :)
We could even try to detect a running sshd.service when upgrading from openssh <= 8.1p1-2 and restart it, I suppose. It should not close existing sessions, and new ones would not be able to be created anyway, so there's no downsides to doing this limited-scope restart in a situation where it is definitely required. -- Eli Schwartz Bug Wrangler and Trusted User
On 2/16/20 7:47 PM, Gaetan Bisson via arch-dev-public wrote:
And I also regret not being able to diagnose what the exact problem is just now.
As was pointed out in the bug: https://bugs.archlinux.org/task/65517#comment186483 ssh errors with: kex_exchange_identification: read: Connection reset by peer sshd logs the error: fatal: recv_rexec_state: buffer error: incomplete message It's pretty plausible that this commit is simply incompatible with the previous version of sshd, therefore it could not reexec: https://github.com/openssh/openssh-portable/commit/c2bd7f74b0e0f3a3ee9d19ac5... So this is "expected" behavior. There's no way to upgrade this without triggering the need for a restart. All consumers of openssh on any operating system will need to restart sshd, possibly via maintenance scripts provided by the distro. -- Eli Schwartz Bug Wrangler and Trusted User
[2020-02-16 20:03:16 -0500] Eli Schwartz via arch-dev-public:
It's pretty plausible that this commit is simply incompatible with the previous version of sshd, therefore it could not reexec: https://github.com/openssh/openssh-portable/commit/c2bd7f74b0e0f3a3ee9d19ac5...
So this is "expected" behavior.
That seems likely indeed. What troubles me is that upstream has never broken live SSH daemons in such a way before, maybe it was just pure luck, but I had assumed this was a conscious design choice on their part. Cheers. -- Gaetan
On 2/16/20 8:11 PM, Gaetan Bisson wrote:
[2020-02-16 20:03:16 -0500] Eli Schwartz via arch-dev-public:
It's pretty plausible that this commit is simply incompatible with the previous version of sshd, therefore it could not reexec: https://github.com/openssh/openssh-portable/commit/c2bd7f74b0e0f3a3ee9d19ac5...
So this is "expected" behavior.
That seems likely indeed. What troubles me is that upstream has never broken live SSH daemons in such a way before, maybe it was just pure luck, but I had assumed this was a conscious design choice on their part.
It could be this one was too difficult to handle since it changed the way marshaling the sshd_config worked? I suppose you'd need to double-check with them. In the meantime, it is definitely not just us: https://bugs.gentoo.org/709748 -- Eli Schwartz Bug Wrangler and Trusted User
participants (3)
-
Eli Schwartz
-
Gaetan Bisson
-
Santiago Torres-Arias