** Description changed:
+
[Impact]
- Hello
+ On Ubuntu VMs running under Microsoft Hyper-V, users commonly rely on
'hv_sock' (Hyper-V socket) to enable seamless SSH access using the 'hvc.exe'
tool on the Windows host. This works correctly on Ubuntu Jammy and earlier (
and Oracular and later with different mechanism ), but fails silently in Noble
due to a missing 'ssh@.service' systemd unit.
- A customer uses hyperv Ubuntu vm and uses hv_sock to connect to it.
+ The failure is due to a combination of systemd and OpenSSH changes:
- With Jammy, it works well with minimum setup. but with Noble, they
- can't.
+ * In older versions (e.g., Jammy with systemd 249), the 'ssh@.service' unit
was relied upon for socket activation ('Accept=yes' mode) and the unit file
exists.
+ * With the Ubuntu Kinetic release, 'ssh@.service' was removed, and no
template unit was shipped by default.
+ * systemd introduced systemd-ssh-generator in version 256 checks
sshd@.service unit and openssh provides sshd@.service unit.
+ * Ubuntu Noble ships with systemd 255, which lacks this feature, resulting in
the absence of sshd@.service.
+ * Debian has restored a static 'sshd@.service' template in recent OpenSSH
packaging. Noble’s OpenSSH package currently lacks it.
- I've analyzed a bit further and found below.
+ As a result, the typical 'ssh.socket' activation workflow fails on
+ Noble, breaking compatibility for 'hv_sock' SSH access.
- debian upstream added sshd@.service template back
-
https://salsa.debian.org/ssh-team/openssh/-/commit/eb25ab611967996a0d57b4ee565faa7de58b41f6
+ [Test Case]
- systemd 256 added ssh-generator
-
https://github.com/systemd/systemd/commit/0e3220684c6184a2f70396d991200ae207a25377
+ 1. Launch a Noble VM on Hyper-V.
+ 2. Ensure the 'hv_sock' kernel module is loaded:
- before systemd 256, ssh@.service was default.
+ echo 'hv_sock' >> /etc/modules
- with Knetic, ssh@.service is removed
-
https://launchpadlibrarian.net/619116456/openssh_1%3A9.0p1-1_1%3A9.0p1-1ubuntu1.diff.gz
+ 3. Modify the socket unit for SSH to listen on vsock:
- So,
+ # /lib/systemd/system/ssh.socket
+ [Socket]
+ ListenStream=vsock:22
+ Accept=yes
- Questing : systemd 257, sshd@.service exists
- Plucky : systemd 257, sshd@.service exists
- Oracular : systemd 256, sshd@.service exists
- Noble : systemd 255, ssh@.service or sshd@.service doesn't exist.
- ...
- Jammy : systemd 249, ssh@.service exists.
- ...
+ 4. Reload and reconfigure systemd units:
- I guess, K, L, M, N are affected by this issue.
+ systemctl disable ssh.service
+ systemctl daemon-reload
+ systemctl stop ssh.service
+ systemctl enable ssh.socket
+ systemctl start ssh.socket
+
+ 5. Attempt to connect from the Hyper-V host:
- [Test Cases]
- 1. deploy hyperv Ubuntu vm
- 2. echo 'hv_sock' >> /etc/module
- 3. vi /lib/systemd/system/ssh.socket
- ..
- [Socket]
- ...
- ListenStream=vsock:22 << add this part
- ...
- Accept=yes << change from no to yes
- ...
- 4. systemctl disable ssh.service; systemctl daemon-reload; systemctl stop
ssh.service;
- 5. systemctl enable ssh.socket; systemctl start ssh.socket;
-
- # in the hyperv host
- 1. hvc ssh user@ubuntu24.04
- # hang this point.
+ hvc ssh user@ubuntu-vm
+
+ Expected Result: Connection succeeds and SSH login is presented.
+ Actual Result: The connection hangs. No systemd unit is spawned due to
missing 'ssh@.service'.
[Where problems could occur]
- TBD
+ Adding a static 'ssh@.service' template unit, as done in Debian(although it
is sshd@.service), is unlikely to interfere with traditional SSH service setups
(i.e., 'ssh.service'). The '@' template only activates in conjunction with
'Accept=yes' sockets and does not conflict with existing unit files.
- [Others]
+ [Other Info]
+
+ * [Debian commit restoring
'sshd@.service'](https://salsa.debian.org/ssh-team/openssh/-/commit/eb25ab611967996a0d57b4ee565faa7de58b41f6)
+ * [systemd 256 adding
'systemd-ssh-generator'](https://github.com/systemd/systemd/commit/0e3220684c6184a2f70396d991200ae207a25377)
+ * OpenSSH in Ubuntu removed 'ssh@.service' in [this
patch](https://launchpadlibrarian.net/619116456/openssh_1%3A9.0p1-1_1%3A9.0p1-1ubuntu1.diff.gz)
during Kinetic development.
+
+ This issue affects all Ubuntu series between Kinetic and Noble
+ (inclusive) where:
+
+ * systemd < 256 is used (no dynamic generator)
+ * 'ssh@.service' has been removed
+
+ But I think Noble only needs SRU for now since the others are EOL.
--
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/2111226
Title:
ssh@.service is still needed for hv_sock in Noble release
Status in openssh package in Ubuntu:
Fix Released
Status in openssh source package in Jammy:
Fix Released
Status in openssh source package in Noble:
In Progress
Status in openssh source package in Oracular:
Fix Released
Status in openssh source package in Plucky:
Fix Released
Status in openssh source package in Questing:
Fix Released
Bug description:
[Impact]
On Ubuntu VMs running under Microsoft Hyper-V, users commonly rely on
'hv_sock' (Hyper-V socket) to enable seamless SSH access using the 'hvc.exe'
tool on the Windows host. This works correctly on Ubuntu Jammy and earlier (
and Oracular and later with different mechanism ), but fails silently in Noble
due to a missing 'ssh@.service' systemd unit.
The failure is due to a combination of systemd and OpenSSH changes:
* In older versions (e.g., Jammy with systemd 249), the 'ssh@.service' unit
was relied upon for socket activation ('Accept=yes' mode) and the unit file
exists.
* With the Ubuntu Kinetic release, 'ssh@.service' was removed, and no
template unit was shipped by default.
* systemd introduced systemd-ssh-generator in version 256 checks
sshd@.service unit and openssh provides sshd@.service unit.
* Ubuntu Noble ships with systemd 255, which lacks this feature, resulting in
the absence of sshd@.service.
* Debian has restored a static 'sshd@.service' template in recent OpenSSH
packaging. Noble’s OpenSSH package currently lacks it.
As a result, the typical 'ssh.socket' activation workflow fails on
Noble, breaking compatibility for 'hv_sock' SSH access.
[Test Case]
1. Launch a Noble VM on Hyper-V.
2. Ensure the 'hv_sock' kernel module is loaded:
echo 'hv_sock' >> /etc/modules
3. Modify the socket unit for SSH to listen on vsock:
# /lib/systemd/system/ssh.socket
[Socket]
ListenStream=vsock:22
Accept=yes
4. Reload and reconfigure systemd units:
systemctl disable ssh.service
systemctl daemon-reload
systemctl stop ssh.service
systemctl enable ssh.socket
systemctl start ssh.socket
5. Attempt to connect from the Hyper-V host:
hvc ssh user@ubuntu-vm
Expected Result: Connection succeeds and SSH login is presented.
Actual Result: The connection hangs. No systemd unit is spawned due to
missing 'ssh@.service'.
[Where problems could occur]
Adding a static 'ssh@.service' template unit, as done in Debian(although it
is sshd@.service), is unlikely to interfere with traditional SSH service setups
(i.e., 'ssh.service'). The '@' template only activates in conjunction with
'Accept=yes' sockets and does not conflict with existing unit files.
[Other Info]
* [Debian commit restoring
'sshd@.service'](https://salsa.debian.org/ssh-team/openssh/-/commit/eb25ab611967996a0d57b4ee565faa7de58b41f6)
* [systemd 256 adding
'systemd-ssh-generator'](https://github.com/systemd/systemd/commit/0e3220684c6184a2f70396d991200ae207a25377)
* OpenSSH in Ubuntu removed 'ssh@.service' in [this
patch](https://launchpadlibrarian.net/619116456/openssh_1%3A9.0p1-1_1%3A9.0p1-1ubuntu1.diff.gz)
during Kinetic development.
This issue affects all Ubuntu series between Kinetic and Noble
(inclusive) where:
* systemd < 256 is used (no dynamic generator)
* 'ssh@.service' has been removed
But I think Noble only needs SRU for now since the others are EOL.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2111226/+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
