I have not tested this, but can't this just be addressed by the
following?
$ mkdir -p /etc/systemd/system/ssh.socket.d/
$ cat > /etc/systemd/system/ssh.socket.d/vsock.conf << EOF
[Socket]
ListenStream=<your vsock config>
EOF
That will give you ssh.socket which listens on vsock, *in addition* to
whatever other sshd config is in place (you could completely override
instead if you wanted).
The way the default ssh.socket and ssh.service are setup, it will
happily listen on multiple ports/sockets/addresses whatever. The sshd-
socket-generator writes its config in /run/systemd/generator, which
means the admin can still append/override the socket configuration with
files in /etc/systemd/system.
It seems to me that if you are modifying the socket unit to make this
work anyways, that just adding a drop-in configuration is preferable. Or
am I missing something about the integration here?
** Changed in: openssh (Ubuntu Noble)
Status: In Progress => Incomplete
--
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:
Incomplete
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.
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.
Basically user should setup ssh.socket correctly to use hv_sock(e.g
changing Accept=no to Accept=yes) but creating whole service file
(ssh@.service) might be different story since Jammy was working fine.
[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. Also it
was working in Jammy.
[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
https://launchpadlibrarian.net/619116456/openssh_1%3A9.0p1-1_1%3A9.0p1-1ubuntu1.diff.gz
during Kinetic development.
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
