[Touch-packages] [Bug 2047082] Re: upgrading openssh-server always shows error: rescue-ssh.target is a disabled or a static unit not running, not starting it.
This bug was fixed in the package openssh - 1:9.6p1-3ubuntu1 --- openssh (1:9.6p1-3ubuntu1) noble; urgency=medium * Merge with Debian unstable (LP: #2040406). Remaining changes: - debian/rules: modify dh_installsystemd invocations for socket-activated sshd. - debian/openssh-server.postinst: handle migration of sshd_config options to systemd socket options on upgrade. - debian/README.Debian: document systemd socket activation. - debian/patches/socket-activation-documentation.patch: Document in sshd_config(5) that ListenAddress and Port no longer work. - debian/openssh-server.templates: include debconf prompt explaining when migration cannot happen due to multiple ListenAddress values. - debian/.gitignore: drop file. - debian/openssh-server.postrm: remove systemd drop-ins for socket-activated sshd on purge. - debian/openssh-server.ucf-md5sum: update for Ubuntu delta - debian/openssh-server.tmpfile,debian/systemd/ssh.service: Move /run/sshd creation out of the systemd unit to a tmpfile config so that sshd can be run manually if necessary without having to create this directory by hand. - debian/patches/systemd-socket-activation.patch: Fix sshd re-execution behavior when socket activation is used. - debian/tests/systemd-socket-activation: Add autopkgtest for systemd socket activation functionality. - d/p/test-set-UsePAM-no-on-some-tests.patch: set UsePAM=no for some tests. * Dropped changes, fixed upstream: - d/p/fix-ftbfs-with-zlib13.patch: fix ftbfs when using zlib 1.3 (LP #2049552) openssh (1:9.6p1-3) unstable; urgency=medium * Allow passing extra ssh-agent arguments via "/usr/lib/openssh/agent-launch start", making it possible to override things like identity lifetime using a systemd drop-in unit (closes: #1059639). * Don't try to start rescue-ssh.target in postinst (LP: #2047082). openssh (1:9.6p1-2) unstable; urgency=medium * Improve detection of broken -fzero-call-used-regs=used (see https://bugzilla.mindrot.org/show_bug.cgi?id=3645; fixes build on ppc64/ppc64el). openssh (1:9.6p1-1) unstable; urgency=medium * Use single quotes in suggested ssh-keygen commands (closes: #1057835). * Debconf translations: - Catalan (thanks, Pablo Huguet; closes: #1049995). * New upstream release (https://www.openssh.com/releasenotes.html#9.6p1): - [CVE-2023-48795] ssh(1), sshd(8): implement protocol extensions to thwart the so-called "Terrapin attack" discovered by Fabian Bäumer, Marcus Brinkmann and Jörg Schwenk. This attack allows a MITM to effect a limited break of the integrity of the early encrypted SSH transport protocol by sending extra messages prior to the commencement of encryption, and deleting an equal number of consecutive messages immediately after encryption starts. A peer SSH client/server would not be able to detect that messages were deleted. - [CVE-2023-51384] ssh-agent(1): when adding PKCS#11-hosted private keys while specifying destination constraints, if the PKCS#11 token returned multiple keys then only the first key had the constraints applied. Use of regular private keys, FIDO tokens and unconstrained keys are unaffected. - [CVE-2023-51385] ssh(1): if an invalid user or hostname that contained shell metacharacters was passed to ssh(1), and a ProxyCommand, LocalCommand directive or "match exec" predicate referenced the user or hostname via %u, %h or similar expansion token, then an attacker who could supply arbitrary user/hostnames to ssh(1) could potentially perform command injection depending on what quoting was present in the user-supplied ssh_config(5) directive. OpenSSH 9.6 now bans most shell metacharacters from user and hostnames supplied via the command-line. - ssh(1), sshd(8): the RFC4254 connection/channels protocol provides a TCP-like window mechanism that limits the amount of data that can be sent without acceptance from the peer. In cases where this limit was exceeded by a non-conforming peer SSH implementation, ssh(1)/sshd(8) previously discarded the extra data. From OpenSSH 9.6, ssh(1)/sshd(8) will now terminate the connection if a peer exceeds the window limit by more than a small grace factor. This change should have no effect of SSH implementations that follow the specification. - ssh(1): add a %j token that expands to the configured ProxyJump hostname (or the empty string if this option is not being used) that can be used in a number of ssh_config(5) keywords. - ssh(1): add ChannelTimeout support to the client, mirroring the same option in the server and allowing ssh(1) to terminate quiescent channels. - ssh(1), sshd(8), ssh-add(1), ssh-keygen(1): add support for reading ED25519 private
[Touch-packages] [Bug 2047082] Re: upgrading openssh-server always shows error: rescue-ssh.target is a disabled or a static unit not running, not starting it.
https://salsa.debian.org/ssh- team/openssh/-/commit/da06b7ef32c20de4dd18cd578025d96a9221984b ** Changed in: openssh (Ubuntu) Status: New => Fix Committed ** Changed in: openssh (Ubuntu) Assignee: (unassigned) => Colin Watson (cjwatson) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2047082 Title: upgrading openssh-server always shows error: rescue-ssh.target is a disabled or a static unit not running, not starting it. Status in openssh package in Ubuntu: Fix Committed Bug description: In our project we regularly build Ubuntu VM images for current 23.10 (stable). In https://github.com/cockpit-project/bots/issues/5691 we ran into an upgrade failure of openssh-server. It starts with the current cloud image and then apt upgrades it, with "DEBIAN_FRONTEND=noninteractive". openssh was updated a few days ago indeed: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... Creating SSH2 ECDSA key; this may take some time ... 256 SHA256:UqrRSpQNM7SIixVivYP/WwZRjt7Sv89P31W/Gxaf+Z8 root@ubuntu (ECDSA) Creating SSH2 ED25519 key; this may take some time ... 256 SHA256:hy9AEDydfnZeY9nf9P4Sb90kx39Oqr101A6tz5j4RQw root@ubuntu (ED25519) rescue-ssh.target is a disabled or a static unit not running, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 145. dpkg: error processing package openssh-server (--configure): installed openssh-server package post-installation script subprocess returned error exit status 1 I.e. of course that security update itself [1] didn't introduce the regression, but earlier VM builds just didn't have a pending openssh update -- looks like this has been a luring upgrade trap in the release already. As a first naïve reproducer I tried apt update DEBIAN_FRONTEND=noninteractive apt update openssh-server on our current VM (with the release version 1:9.3p1-1ubuntu3), and that worked fine. Same with installing all 9 available packages. rescue.target is loaded/inactive/static, as it should be. Updating without DEBIAN_FRONTEND does show me a conffile prompt about /etc/ssh/sshd_config, which is justified as we do modify the config: # Allow root login with password sed -i 's/^[# ]*PermitRootLogin .*/PermitRootLogin yes/' /etc/ssh/sshd_config # Prevent SSH from hanging for a long time when no external network access echo 'UseDNS no' >> /etc/ssh/sshd_config this also leads to a merge conflict. However, I suppose all of that is tangential to the rescue-ssh.target issue. In all my interactive upgrades, it seemed to handle that just fine: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... rescue-ssh.target is a disabled or a static unit not running, not starting it. So this seems to be related to the first-time installation of openssh- server -- it is part of the cloud image, but it does the host key generation during our image builds. So reproducing this is a bit tricky, but aside from that: Why does it even do this in the first place? # Automatically added by dh_installsystemd/13.11.6ubuntu1 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then if [ -d /run/systemd/system ]; then systemctl --system daemon-reload >/dev/null || true if [ -n "$2" ]; then _dh_action=restart else _dh_action=start fi deb-systemd-invoke $_dh_action 'rescue-ssh.target' >/dev/null || true fi fi It feels like the postinst should *never* try to start rescue- ssh.target. That's an alternative boot mode, and should never run un multi-user.target, isn't it? [1] https://launchpad.net/ubuntu/+source/openssh/1:9.3p1-1ubuntu3.1 DistroRelease: Ubuntu 23.10 PackageVersion: openssh-server 1:9.3p1-1ubuntu3.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2047082/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2047082] Re: upgrading openssh-server always shows error: rescue-ssh.target is a disabled or a static unit not running, not starting it.
** Tags added: server-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2047082 Title: upgrading openssh-server always shows error: rescue-ssh.target is a disabled or a static unit not running, not starting it. Status in openssh package in Ubuntu: New Bug description: In our project we regularly build Ubuntu VM images for current 23.10 (stable). In https://github.com/cockpit-project/bots/issues/5691 we ran into an upgrade failure of openssh-server. It starts with the current cloud image and then apt upgrades it, with "DEBIAN_FRONTEND=noninteractive". openssh was updated a few days ago indeed: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... Creating SSH2 ECDSA key; this may take some time ... 256 SHA256:UqrRSpQNM7SIixVivYP/WwZRjt7Sv89P31W/Gxaf+Z8 root@ubuntu (ECDSA) Creating SSH2 ED25519 key; this may take some time ... 256 SHA256:hy9AEDydfnZeY9nf9P4Sb90kx39Oqr101A6tz5j4RQw root@ubuntu (ED25519) rescue-ssh.target is a disabled or a static unit not running, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 145. dpkg: error processing package openssh-server (--configure): installed openssh-server package post-installation script subprocess returned error exit status 1 I.e. of course that security update itself [1] didn't introduce the regression, but earlier VM builds just didn't have a pending openssh update -- looks like this has been a luring upgrade trap in the release already. As a first naïve reproducer I tried apt update DEBIAN_FRONTEND=noninteractive apt update openssh-server on our current VM (with the release version 1:9.3p1-1ubuntu3), and that worked fine. Same with installing all 9 available packages. rescue.target is loaded/inactive/static, as it should be. Updating without DEBIAN_FRONTEND does show me a conffile prompt about /etc/ssh/sshd_config, which is justified as we do modify the config: # Allow root login with password sed -i 's/^[# ]*PermitRootLogin .*/PermitRootLogin yes/' /etc/ssh/sshd_config # Prevent SSH from hanging for a long time when no external network access echo 'UseDNS no' >> /etc/ssh/sshd_config this also leads to a merge conflict. However, I suppose all of that is tangential to the rescue-ssh.target issue. In all my interactive upgrades, it seemed to handle that just fine: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... rescue-ssh.target is a disabled or a static unit not running, not starting it. So this seems to be related to the first-time installation of openssh- server -- it is part of the cloud image, but it does the host key generation during our image builds. So reproducing this is a bit tricky, but aside from that: Why does it even do this in the first place? # Automatically added by dh_installsystemd/13.11.6ubuntu1 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then if [ -d /run/systemd/system ]; then systemctl --system daemon-reload >/dev/null || true if [ -n "$2" ]; then _dh_action=restart else _dh_action=start fi deb-systemd-invoke $_dh_action 'rescue-ssh.target' >/dev/null || true fi fi It feels like the postinst should *never* try to start rescue- ssh.target. That's an alternative boot mode, and should never run un multi-user.target, isn't it? [1] https://launchpad.net/ubuntu/+source/openssh/1:9.3p1-1ubuntu3.1 DistroRelease: Ubuntu 23.10 PackageVersion: openssh-server 1:9.3p1-1ubuntu3.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2047082/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
