** Description changed: [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 '[email protected]' systemd unit. + 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, because the logic in Ubuntu's systemd-socket-activation.patch silently rejects sockets that are not AF_INET or AF_INET6. - The failure is due to a combination of systemd and OpenSSH changes: - - * In older versions (e.g., Jammy with systemd 249), the '[email protected]' unit was relied upon for socket activation ('Accept=yes' mode) and the unit file exists. - * With the Ubuntu Kinetic release, '[email protected]' was removed, and no template unit was shipped by default. - * systemd introduced systemd-ssh-generator in version 256 checks [email protected] unit and openssh provides [email protected] unit. - * Ubuntu Noble ships with systemd 255, which lacks this feature, resulting in the absence of [email protected]. - * Debian has restored a static '[email protected]' 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) - * '[email protected]' 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 - ([email protected]) might be different story since Jammy was working fine. + Hence, when an AF_VSOCK socket is passed (which is supported by systemd + socket's ListenStream=), the client connection silently hangs. [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. Adding the socket conf for SSH to listen on vsock: # cat > /etc/systemd/system/ssh.socket.d/vsock.conf << EOF [Socket] ListenStream=vsock::22 EOF 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 '[email protected]'. [Where problems could occur] Adding a static '[email protected]' template unit, as done in Debian(although it is [email protected]), 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 '[email protected]' 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 '[email protected]' in https://launchpadlibrarian.net/619116456/openssh_1%3A9.0p1-1_1%3A9.0p1-1ubuntu1.diff.gz during Kinetic development.
** Description changed: [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, because the logic in Ubuntu's systemd-socket-activation.patch silently rejects sockets that are not AF_INET or AF_INET6. Hence, when an AF_VSOCK socket is passed (which is supported by systemd socket's ListenStream=), the client connection silently hangs. [Test Case] - 1. Launch a Noble VM on Hyper-V. - 2. Ensure the 'hv_sock' kernel module is loaded: + 1. Launch a VM with vsock support. This could be e.g. a VM on Hyper-V + using hv_vsock, or a LXD VM created with: - echo 'hv_sock' >> /etc/modules + $ lxc launch --vm ubuntu:$series + + 2. Ensure the relevant vsock modules are loaded: + + $ lsmod | grep vsock 3. Adding the socket conf for SSH to listen on vsock: - # cat > /etc/systemd/system/ssh.socket.d/vsock.conf << EOF - [Socket] - ListenStream=vsock::22 - EOF + $ cat > /etc/systemd/system/ssh.socket.d/vsock.conf << EOF + [Socket] + ListenStream=vsock::22 + EOF + $ systemctl daemon-reload + $ systemctl restart ssh.socket - 4. Reload and reconfigure systemd units: + 4. Attempt the connection: - 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: + (a) 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 '[email protected]'. + Actual Result: The connection hangs. [Where problems could occur] Adding a static '[email protected]' template unit, as done in Debian(although it is [email protected]), 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 '[email protected]' 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 '[email protected]' in https://launchpadlibrarian.net/619116456/openssh_1%3A9.0p1-1_1%3A9.0p1-1ubuntu1.diff.gz during Kinetic development. ** Description changed: [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, because the logic in Ubuntu's systemd-socket-activation.patch silently rejects sockets that are not AF_INET or AF_INET6. Hence, when an AF_VSOCK socket is passed (which is supported by systemd socket's ListenStream=), the client connection silently hangs. [Test Case] + + The autopkgtests for openssh contain socket-activation tests to help + avoid regressions in the existing logic. In addition to those tests, the + below manual testing will be performed to verify the AF_VSOCK fix: 1. Launch a VM with vsock support. This could be e.g. a VM on Hyper-V using hv_vsock, or a LXD VM created with: $ lxc launch --vm ubuntu:$series 2. Ensure the relevant vsock modules are loaded: $ lsmod | grep vsock 3. Adding the socket conf for SSH to listen on vsock: $ cat > /etc/systemd/system/ssh.socket.d/vsock.conf << EOF [Socket] ListenStream=vsock::22 EOF $ systemctl daemon-reload $ systemctl restart ssh.socket 4. Attempt the connection: (a) 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. [Where problems could occur] - Adding a static '[email protected]' template unit, as done in Debian(although it is [email protected]), 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] + The effective goals of the patch are to (a) accept when AF_VSOCK sockets + are passed by systemd, and (b) to close() (rather than silently ignore) + unsupported socket types. - * Debian commit restoring '[email protected]' - 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 '[email protected]' in - https://launchpadlibrarian.net/619116456/openssh_1%3A9.0p1-1_1%3A9.0p1-1ubuntu1.diff.gz - during Kinetic development. + There is additional logic to properly log about where the server is + listening. This creates additional room for error. + + All of the changes are contained within the setup_systemd_socket() + function. Therefore, problems would be seen when sshd is socket- + activated, e.g. on the first connection attempt to a given server. -- You received this bug notification because you are a member of Debcrafters packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2111226 Title: sshd socket activation does not support AF_VSOCK Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Jammy: Fix Released Status in openssh source package in Noble: Triaged Status in openssh source package in Oracular: Won't Fix Status in openssh source package in Plucky: Triaged 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, because the logic in Ubuntu's systemd-socket-activation.patch silently rejects sockets that are not AF_INET or AF_INET6. Hence, when an AF_VSOCK socket is passed (which is supported by systemd socket's ListenStream=), the client connection silently hangs. [Test Case] The autopkgtests for openssh contain socket-activation tests to help avoid regressions in the existing logic. In addition to those tests, the below manual testing will be performed to verify the AF_VSOCK fix: 1. Launch a VM with vsock support. This could be e.g. a VM on Hyper-V using hv_vsock, or a LXD VM created with: $ lxc launch --vm ubuntu:$series 2. Ensure the relevant vsock modules are loaded: $ lsmod | grep vsock 3. Adding the socket conf for SSH to listen on vsock: $ cat > /etc/systemd/system/ssh.socket.d/vsock.conf << EOF [Socket] ListenStream=vsock::22 EOF $ systemctl daemon-reload $ systemctl restart ssh.socket 4. Attempt the connection: (a) 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. [Where problems could occur] The effective goals of the patch are to (a) accept when AF_VSOCK sockets are passed by systemd, and (b) to close() (rather than silently ignore) unsupported socket types. There is additional logic to properly log about where the server is listening. This creates additional room for error. All of the changes are contained within the setup_systemd_socket() function. Therefore, problems would be seen when sshd is socket- activated, e.g. on the first connection attempt to a given server. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2111226/+subscriptions -- Mailing list: https://launchpad.net/~debcrafters-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~debcrafters-packages More help : https://help.launchpad.net/ListHelp
