sshd cannot bind to IPv4 interfaces

Bug #2080216 reported by Vasya Pupkin
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
openssh (Ubuntu)
Fix Released
Medium
Unassigned
Noble
Fix Committed
Undecided
Unassigned

Bug Description

[Impact]

The default listening sockets for sshd are different depending on whether socket activation is used or not, even when /etc/ssh/sshd_config is the default. E.g.:

# Socket-activated

root@n2:~# systemctl status ssh.socket
● ssh.socket - OpenBSD Secure Shell server socket
     Loaded: loaded (/usr/lib/systemd/system/ssh.socket; enabled; preset: enabled)
     Active: active (listening) since Tue 2024-10-01 20:36:15 UTC; 12min ago
   Triggers: ● ssh.service
     Listen: [::]:22 (Stream)
     CGroup: /system.slice/ssh.socket

Oct 01 20:36:15 n2 systemd[1]: Listening on ssh.socket - OpenBSD Secure Shell server socket.
root@n2:~# lsof -i :22
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd 1 root 47u IPv6 2781411 0t0 TCP *:ssh (LISTEN)

# Non-socket-activated

root@n2:~# systemctl disable --now ssh.socket
Removed "/etc/systemd/system/ssh.service.requires/ssh.socket".
Removed "/etc/systemd/system/sockets.target.wants/ssh.socket".
root@n2:~# ln -s /dev/null /etc/systemd/system-generators/sshd-socket-generator
root@n2:~# systemctl enable --now ssh.service
Synchronizing state of ssh.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable ssh
Created symlink /etc/systemd/system/sshd.service → /usr/lib/systemd/system/ssh.service.
Created symlink /etc/systemd/system/multi-user.target.wants/ssh.service → /usr/lib/systemd/system/ssh.service.
root@n2:~# lsof -i :22
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd 798 root 3u IPv4 2793622 0t0 TCP *:ssh (LISTEN)
sshd 798 root 4u IPv6 2793624 0t0 TCP *:ssh (LISTEN)

By default, we have net.ipv6.bindv6only=0 sysctl, and BindIPv6Only=both on ssh.socket, which means usually users can connect over IPv4 regardless. However, the fact remains that the resulting listening sockets are different in these two cases, and socket-activated ssh does not accurately reflect the settings in /etc/ssh/sshd_config.

[Test Plan]

1. Check that on a noble system, without custom sshd_config, sshd is listening on both IPv4 and IPv6 on port 22:

$ lsof -i :22

2. Check that setting AddressFamily to e.g. inet results in only an IPv4 socket:

$ echo "AddressFamily inet" >> /etc/ssh/sshd_config.d/custom.conf
$ systemctl daemon-reload
$ systemctl restart ssh.socket
$ lsof -i :22

There should only be one listener now.

3. Check the same thing with inet6, and a custom port for good measure:

$ echo "AddressFamily inet6" >> /etc/ssh/sshd_config.d/custom.conf
$ echo "Port 1234" >> /etc/ssh/sshd_config.d/custom.conf
$ systemctl daemon-reload
$ systemctl restart ssh.socket
$ lsof -i :1234

4. The new tests in debian/tests/sshd-socket-generator should all pass in autopkgtest.

[Where problems could occur]

The fix requires new default settings in the [Socket] section of ssh.socket, and handling for new defaults in sshd-socket-generator. It would be more likely to see problems with the generator as opposed to the changes in ssh.socket. However, new subtests were added to debian/tests/sshd-socket-generator to help avoid this.

[Original Description]

After upgrading from 22.04 to 24.04 I noticed that my sshd only listening on IPv6 interface (::), while previously it was listening both IPv4 (0.0.0.0) and IPv6 (::). I tried to explicitly specify ListenAddress 0.0.0.0 (assuming it would bind to IPv4 only) but after restart sshd was still listening on IPv6 only.

This problem affects other packages as well, for example, openvpn.

Rebuilding applications from sources seems to fix the issue.

Setting net.ipv6.bindv6only=0 also helps, but that's not a solution.

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: openssh-server 1:9.6p1-3ubuntu13.5
ProcVersionSignature: Ubuntu 6.8.0-41.41-generic 6.8.12
Uname: Linux 6.8.0-41-generic x86_64
ApportVersion: 2.28.1-0ubuntu3.1
Architecture: amd64
CasperMD5CheckResult: unknown
Date: Tue Sep 10 16:45:54 2024
ProcEnviron:
 LANG=C.UTF-8
 PATH=(custom, no user)
 SHELL=/bin/bash
 TERM=screen.xterm-256color
SourcePackage: openssh
UpgradeStatus: Upgraded to noble on 2024-09-10 (0 days ago)

Related branches

Revision history for this message
Vasya Pupkin (shadowlmd) wrote :
Revision history for this message
Nick Rosbrook (enr0n) wrote (last edit ):

Is sshd not accessible at all over ipv4? How did you notice that sshd was not listening on ipv4?

In the default case, we should end up with ssh.socket listening on [::]:22, but with IPV6_V6ONLY=0 so that sshd is still accessible over ipv4.

> Setting net.ipv6.bindv6only=0 also helps, but that's not a solution.

I think this is the default on Ubuntu, no?

If your system does have net.ipv6.bindv6only=1, and you don't want to change it, a workaround for now should be to do:

$ mkdir -p /etc/systemd/systemd/ssh.socket.d/
$ cat > /etc/systemd/system/ssh.socket.d/bindipv6only-both.conf << EOF
[Socket]
BindIPv6Only=both
EOF

which has the effect of setting IPV6_V6ONLY to 0 for this particular socket.

We should probably fix sshd-socket-generator to automatically do this in certain cases.

Changed in openssh (Ubuntu):
importance: Undecided → Medium
status: New → Incomplete
status: Incomplete → Confirmed
tags: added: rls-nn-incoming
Revision history for this message
Vasya Pupkin (shadowlmd) wrote :

I first noticed that I could not ssh to my host, was getting connection refused error. Then I tried to connect over IPv6 address and it worked. I checked with `ss -tlnp | grep 22` and found out that sshd was only listening on [::]:22. Then I tried almost everything to bind it to 0.0.0.0 without any luck. Even when I only specified 0.0.0.0 as bind interface, it was still binding to [::] instead.

I also noticed that my manually compiled sslh behaved the same way. Last time it was compiled on Ubuntu 22.04, so I decided to rebuild it on 24.04 and it started to work properly.

I believe, there was some change in libc which either requires all network related software recompiled from source. Because like I said, almost every network related software behaves the same.

While net.ipv6.bindv6only=0 is the default, it doesn't explain why net.ipv6.bindv6only=1 works incorrectly. It is not supposed to replace 0.0.0.0 with [::], it is supposed to stop applications to bind to IPv4 interfaces when they are configured to bind to [::] only explicitly. Also, it doesn't explain why recompiling applications from source fixes the issue.

tags: added: foundations-todo
removed: rls-nn-incoming
Revision history for this message
Vasya Pupkin (shadowlmd) wrote :

Some more details. Here's a part of my sslh config:

listen:
(
    { host: "0.0.0.0"; port: "443"; },
    { host: "::"; port: "443"; }
);

And here's how it's working:

# ss -tlnp | grep sslh
LISTEN 0 50 0.0.0.0:443 0.0.0.0:* users:(("sslh-fork",pid=2557,fd=3),("sslh-fork",pid=2556,fd=3),("sslh-fork",pid=2551,fd=3))
LISTEN 0 50 [::]:443 [::]:* users:(("sslh-fork",pid=2557,fd=4),("sslh-fork",pid=2556,fd=4),("sslh-fork",pid=2551,fd=4))

You can see that it's listening on both 0.0.0.0 and [::] interfaces.

Now here's a piece of my sshd_config:

AddressFamily any
ListenAddress 0.0.0.0
ListenAddress ::

And here's how it's working:

# ss -tlnp | grep sshd
LISTEN 0 8192 [::]:22 [::]:* users:(("sshd",pid=843,fd=3),("systemd",pid=1,fd=69))

As you can see, it doesn't listen on IPv4 interface at all.

This is clearly a packaging bug because only precompiled binaries are affected. My sslh binary compiled under Ubuntu 22.04 was doing the same and was fixed once I compiled it under Ubuntu 24.04.

Revision history for this message
Rob (robtinkers) wrote :

I have the same issue on a clean install of 24.04.1.

From ubuntu-24.04-live-server-amd64.iso I chose "Ubuntu Server (minimized)" and "Install OpenSSH server".

$ sudo apt update && sudo apt upgrade -y && shutdown -r now
...
$ lsb_release -d
No LSB modules are available
Description: Ubuntu 24.04.1 LTS
$ sudo apt install net-tools iputils-ping
...
$ netstat -an | grep '^tcp.*LISTEN'
tcp 0 0 127.0.0.54:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=3.62ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=3.09ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=3.36ms
^C
$ sysctl net.ipv6.bindv6only
net.ipv6.bindv6only = 0

(This is inside VirtualBox. Pinging the ubuntu IP4 address from the Windows also host works.)

Creating /etc/systemd/system/ssh.socket.d/bindipv6only-both.conf as suggested above does not fix the issue.

$ sudo systemctl disable --now ssh.socket
$ sudo systemctl daemon-reload
$ sudo systemctl enable --now ssh.service

does fix the issue.

Revision history for this message
Nick Rosbrook (enr0n) wrote :

Okay, I am not sure why the ipv6 socket is not accepting ipv4, because AFAICT (and when I test on my machine) the way IPV6_V6ONLY is being set in the default case, it should allow ipv4.

However, I do think there is a case to be made about the socket unit being more aligned with the contents of /etc/ssh/sshd_config, and non-socket activated sshd. E.g., with the default contents of /etc/ssh/sshd_config, and *non-socket-activated* ssh, we will have two separate listening addresses, [::]:22 and 0.0.0.0:22 (explicitly, not via ipv6). We should do the same for socket-activated SSH by default. And, while we are at it, we need to make sshd-socket-generator honor AddressFamily.

Nick Rosbrook (enr0n)
Changed in openssh (Ubuntu):
status: Confirmed → Triaged
Nick Rosbrook (enr0n)
description: updated
Nick Rosbrook (enr0n)
Changed in openssh (Ubuntu):
status: Triaged → Fix Committed
Nick Rosbrook (enr0n)
Changed in openssh (Ubuntu Noble):
status: New → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openssh - 1:9.7p1-7ubuntu4

---------------
openssh (1:9.7p1-7ubuntu4) oracular; urgency=medium

  * Explicitly listen on IPv4 by default, with socket-activated sshd
    (LP: #2080216)
    - d/systemd/ssh.socket: explicitly listen on ipv4 by default
    - d/t/sshd-socket-generator: update for new defaults and AddressFamily
    - sshd-socket-generator: handle new ssh.socket default settings
  * d/p/systemd-socket-activation.patch: always close newsock fd before re-exec

 -- Nick Rosbrook <email address hidden> Tue, 01 Oct 2024 14:45:28 -0400

Changed in openssh (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Vasya Pupkin (shadowlmd) wrote :

Any estimate when the fixed version will be available in Ubuntu 24.04 without -proposal repos?

Revision history for this message
Nick Rosbrook (enr0n) wrote :

This is waiting on review from the SRU team. Many of the SRU team members are also busy with opening the archive for 25.04 and other things this week, but I will ping them.

Once it is accepted into noble-proposed, it will be at least a week until it moves to noble-updates.

Revision history for this message
Chris Halse Rogers (raof) wrote : Please test proposed package

Hello Vasya, or anyone else affected,

Accepted openssh into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openssh/1:9.6p1-3ubuntu13.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in openssh (Ubuntu Noble):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-noble
Revision history for this message
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (openssh/1:9.6p1-3ubuntu13.6)

All autopkgtests for the newly accepted openssh (1:9.6p1-3ubuntu13.6) for noble have finished running.
The following regressions have been reported in tests triggered by the package:

crmsh/unknown (i386)
debvm/unknown (amd64)
fence-agents/4.12.1-2~exp1ubuntu4 (amd64)
freedombox/unknown (amd64)
g10k/unknown (amd64)
gvfs/unknown (amd64)
libnet-scp-perl/unknown (amd64)
libnet-sftp-foreign-perl/unknown (amd64)
libnetapp-perl/unknown (amd64)
nova/unknown (i386)
pkg-perl-tools/0.78 (amd64, armhf)
rancid/unknown (amd64)
tinyssh/20240101-2 (amd64, armhf)
ubuntu-boot-test/2 (amd64)
vorta/unknown (amd64)
wcc/unknown (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/noble/update_excuses.html#openssh

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Revision history for this message
Vasya Pupkin (shadowlmd) wrote (last edit ):

After 8 hours the updated package is still not available in proposed repo:

# apt update
Hit:1 http://mirror.yandex.ru/ubuntu noble InRelease
Hit:2 http://mirror.yandex.ru/ubuntu noble-updates InRelease
Hit:3 http://mirror.yandex.ru/ubuntu noble-backports InRelease
Hit:4 http://mirror.yandex.ru/ubuntu noble-proposed InRelease
Hit:5 http://security.ubuntu.com/ubuntu noble-security InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

# apt install openssh-server
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
openssh-server is already the newest version (1:9.6p1-3ubuntu13.5).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

I'll try again later.

Revision history for this message
Nick Rosbrook (enr0n) wrote :

By default, the priority for -propsed is lower than -updates etc. Please try:

$ apt install openssh-server -t noble-proposed

to specify you want to install from noble-proposed.

Revision history for this message
Nick Rosbrook (enr0n) wrote :
Download full text (10.6 KiB)

I have verified the fix using openssh-server from noble-proposed.

I setup a container and enabled noble-proposed:

nr@six:~$ lxc launch ubuntu:noble noble
Launching noble
nr@six:~$ lxc exec noble bash
root@noble:~# cat > /etc/apt/sources.list.d/proposed.sources << EOF
> Types: deb
> URIs: http://us.archive.ubuntu.com/ubuntu/
> Suites: noble-proposed
> Components: main universe
> Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
> EOF
root@noble:~# apt update
Get:1 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
Hit:2 http://archive.ubuntu.com/ubuntu noble InRelease
Get:3 http://us.archive.ubuntu.com/ubuntu noble-proposed InRelease [265 kB]
Get:4 http://archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Get:5 http://archive.ubuntu.com/ubuntu noble-backports InRelease [126 kB]
Get:6 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages [15.0 MB]
Get:7 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages [433 kB]
Get:8 http://us.archive.ubuntu.com/ubuntu noble-proposed/main amd64 Packages [180 kB]
Get:9 http://us.archive.ubuntu.com/ubuntu noble-proposed/main Translation-en [48.6 kB]
Get:10 http://security.ubuntu.com/ubuntu noble-security/main Translation-en [93.2 kB]
Get:11 http://security.ubuntu.com/ubuntu noble-security/main amd64 Components [7152 B]
Get:12 http://security.ubuntu.com/ubuntu noble-security/main amd64 c-n-f Metadata [5816 B]
Get:13 http://us.archive.ubuntu.com/ubuntu noble-proposed/main amd64 Components [22.0 kB]
Get:14 http://security.ubuntu.com/ubuntu noble-security/universe amd64 Packages [555 kB]
Get:15 http://us.archive.ubuntu.com/ubuntu noble-proposed/main amd64 c-n-f Metadata [3556 B]
Get:16 http://us.archive.ubuntu.com/ubuntu noble-proposed/universe amd64 Packages [650 kB]
Get:17 http://us.archive.ubuntu.com/ubuntu noble-proposed/universe Translation-en [79.1 kB]
Get:18 http://security.ubuntu.com/ubuntu noble-security/universe Translation-en [148 kB]
Get:19 http://us.archive.ubuntu.com/ubuntu noble-proposed/universe amd64 Components [68.0 kB]
Get:20 http://us.archive.ubuntu.com/ubuntu noble-proposed/universe amd64 c-n-f Metadata [10.7 kB]
Get:21 http://security.ubuntu.com/ubuntu noble-security/universe amd64 Components [51.9 kB]
Get:22 http://security.ubuntu.com/ubuntu noble-security/universe amd64 c-n-f Metadata [13.5 kB]
Get:23 http://security.ubuntu.com/ubuntu noble-security/restricted amd64 Packages [388 kB]
Get:24 http://security.ubuntu.com/ubuntu noble-security/restricted Translation-en [74.8 kB]
Get:25 http://archive.ubuntu.com/ubuntu noble/universe Translation-en [5982 kB]
Get:26 http://archive.ubuntu.com/ubuntu noble/universe amd64 Components [3871 kB]
Get:27 http://security.ubuntu.com/ubuntu noble-security/res...

Revision history for this message
Vasya Pupkin (shadowlmd) wrote (last edit ):

Thanks, Nick!

I've installed version 1:9.6p1-3ubuntu13.6 and confirm that it fixed the issue.

Here's how I verified:

1. Install new version
2. Check what's listening on port 22 via ss command:
    $ sudo ss -tlnp | grep :22
    LISTEN 0 8192 0.0.0.0:22 0.0.0.0:* users:(("systemd",pid=1,fd=68))
    LISTEN 0 8192 [::]:22 [::]:* users:(("systemd",pid=1,fd=69))
3. Tried to connect on IPv4 interface to double check and it worked

Vasya Pupkin (shadowlmd)
tags: added: verification-done-noble
removed: verification-needed-noble
Revision history for this message
Nick Rosbrook (enr0n) wrote :

Thanks for verifying, Vasya!

Revision history for this message
Chris Halse Rogers (raof) wrote : Please test proposed package

Hello Vasya, or anyone else affected,

Accepted openssh into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openssh/1:9.6p1-3ubuntu13.7 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

tags: added: verification-needed-noble
removed: verification-done-noble
Revision history for this message
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (openssh/1:9.6p1-3ubuntu13.7)

All autopkgtests for the newly accepted openssh (1:9.6p1-3ubuntu13.7) for noble have finished running.
The following regressions have been reported in tests triggered by the package:

crmsh/4.6.0-1ubuntu2 (amd64)
crmsh/unknown (i386)
fence-agents/unknown (amd64)
keychain/unknown (i386)
openmpi/4.1.6-7ubuntu2 (amd64)
openssh/1:9.6p1-3ubuntu13.7 (ppc64el)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/noble/update_excuses.html#openssh

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Revision history for this message
Vasya Pupkin (shadowlmd) wrote :

Tested the same way as before, still works fine.

tags: added: verification-done-noble
removed: verification-needed-noble
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Thanks for your verification, Vasaya.

openssh is a critical package in ubuntu, and this update has already gone through one iteration. The original update was 1:9.6p1-3ubuntu13.6, which was tested in comment #14 according to the test plan from the bug description.

But then 1:9.6p1-3ubuntu13.7 was uploaded.

Given that it's a new version, and that in comment #12 we saw difficulties in getting the package from noble-proposed, we need to be absolutely sure that:

a) 1:9.6p1-3ubuntu13.7 from noble-proposed is the package that was tested, and not the previous 13.6 or something else
b) the test plan from the bug description was carried out in all its steps (1 through 3; 4 is autopkgtest that is performed automatically)

I will change the verification tag back to needed.

tags: added: verification-needed-noble
removed: verification-done-noble
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

I had an internal discussion about this SRU and decided that repeating the verification done for 13.6 on 13.7 is indeed not necessary, given the nature of the change introduced in 13.7.

tags: added: verification-done-noble
removed: verification-needed-noble
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openssh - 1:9.6p1-3ubuntu13.7

---------------
openssh (1:9.6p1-3ubuntu13.7) noble; urgency=medium

  * d/t/sshd-socket-generator: run test_match_on_port test
    The test case was added to verify the fix for LP: 2076023,
    but it is not actually executed at the moment. Now that
    it does run, fix the grep commands used.

openssh (1:9.6p1-3ubuntu13.6) noble; urgency=medium

  * Explicitly listen on IPv4 by default, with socket-activated sshd
    (LP: #2080216)
    - d/systemd/ssh.socket: explicitly listen on ipv4 by default
    - d/t/sshd-socket-generator: update for new defaults and AddressFamily
    - sshd-socket-generator: handle new ssh.socket default settings
  * sshd-socket-generator: do not parse server match config
    (LP: #2076023)
  * d/p/systemd-socket-activation.patch: don't clear rexec_flag
    (LP: #2071815)
  * d/p/sshd-socket-generator.patch: add note to sshd_config
    Explain that a systemctl daemon-reload is needed for changes
    to Port et al to take effect.
    (LP: #2069041)
  * debian/openssh-server.ucf-md5sum: add new checksums for sshd_config

 -- Nick Rosbrook <email address hidden> Wed, 23 Oct 2024 14:19:51 -0400

Changed in openssh (Ubuntu Noble):
status: Fix Committed → Fix Released
Revision history for this message
Andreas Hasenack (ahasenack) wrote : Update Released

The verification of the Stable Release Update for openssh has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

1:9.6p1-3ubuntu13.7 was moved back to noble-proposed due to a possible regression[1] that is being investigated. Setting the bug tasks back to fix committed.

1:9.6p1-3ubuntu13.5 was restored in noble-updates.

1. https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2087551

Changed in openssh (Ubuntu Noble):
status: Fix Released → Fix Committed
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Adding block-proposed-noble to avoid accidental release while the regression in https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2087551 is investigated.

tags: added: block-proposed-noble
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.