← Back to team overview

debcrafters-packages team mailing list archive

[Bug 2111226] Re: sshd socket activation does not support AF_VSOCK

 

** 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 'ssh@.service' 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 '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.
+ 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 '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.

** 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 'ssh@.service'.
+ Actual Result: The connection hangs.
  
  [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.

** 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 '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]
+ 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 '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.
+ 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



References