As of version 1:9.0p1-1ubuntu1 of openssh-server in Kinetic Kudu (Ubuntu 22.10), OpenSSH in Ubuntu is configured by default to use systemd socket activation. This means that sshd will not be started until an incoming connection request is received. This has been done to reduce the memory consumed by Ubuntu Server instances by default, which is of particular interest with Ubuntu running in VMs or LXD containers: by not running sshd when it is not used, we save at least 3MiB of memory in each instance, representing a savings of roughly 5% on an idle, pristine kinetic container.
At Canonical we care about making Ubuntu as efficient as possible on your hardware and in the cloud, which is why this change has been landed as part of a larger effort to reduce the default memory footprint of our images. A default Ubuntu 22.04 LXD image at release time used 65MiB of RAM, which in kinetic now uses 58MiB after this OpenSSH change; and more improvements are in progress, with the intention of backporting the safer changes to our Ubuntu 22.04 images to improve memory usage for the greatest number of users.
On new installs of Ubuntu 22.10 or later, the OpenSSH change in behavior should be completely transparent to users.
On upgrades from Ubuntu 22.04 LTS, users who had configured Port settings or a ListenAddress setting in /etc/ssh/sshd_config will find these settings migrated to /etc/systemd/system/ssh.socket.d/addresses.conf. As an exception, if more than one ListenAddress setting is declared, the configuration is not migrated because systemd’s ListenStream has different semantics: any address configured which is not present at boot time would cause the ssh.socket unit to not start. Because it is not possible to reliably determine at upgrade time whether ssh.socket could fail to start on reboot, if you have more than one ListenAddress configured, your system will not be migrated to socket-based activation but instead the daemon will be started on boot as before.
Socket activation is recommended wherever possible, but if for any reason you find after migration that this is incompatible with your configuration, it is still possible to revert to the previous non-socket-activated behavior by running:
Works well for me. One thing I verified is that the hosts_access(5) (libwrap) remains the same: it does. I do have a couple of suggestions:
We still ship sshd_config with #ListenAddress and #Port lines, with no warning about them not being honored anymore by default. Users editing those will be surprised that they have no effect. I think they should be replaced or complemented by a comment explaining the new way for specifying the listen address and port (maybe by pointing to openssh-server.README.Debian, see below). I see that this requires patching upstream’s sshd_config, which is a bit annoying.
There’s useful info about socket-based activation in README.Debian, but I initially failed to find it because it gets installed by the openssh-client package, as it’s the first package specified in d/control. Consider moving the socket activation bits to d/openssh-server.README.Debian in the source package.
Thanks for the feedback. It was intended to document in the default sshd_config that these options are unused, but that didn’t get done yet. I’ll make sure that’s handled in the next upload.
As far as finding README.Debian, openssh-server has a strict versioned dependency on openssh-client because /usr/share/doc/openssh-server is a symlink to /usr/share/doc/openssh-client - so I’m not sure why this prevented you from finding it?
As I was inspecting the package more in general I had a look at the files installed by openssh-server and didn’t see README.Debian. This is not what users will (and should) normally do, I think the current approach is good, thanks for pointing me to it.
Hello,
So in simple terms, how can we change the ssh port on a new install of Ubuntu 22.10?
(I cannot find the right way to do it, after editing the port in /lib/systemd/system/ssh.socket, the port ssh.socket is listening to changed as excepted and it starts successfully, however whenever I try to SSH, ssh.socket on the server side will fail immediately and refuse connections.)
These options may be specified more than once, in which case incoming traffic on any of the sockets will trigger service activation, and all listed sockets will be passed to the service,
regardless of whether there is incoming traffic on them or not. If the empty string is assigned to any of these options, the list of addresses to listen on is reset, all prior uses of any
of these options will have no effect.
in some cases when updating /etc/systemd/system/ssh.service.d/00-socket.conf is created.
This file forces the use of ssh.socket. You might also check the existence of this file and delete it followed by a systemctl daemon-reload
I’m trying to bind to an IP address assigned by DHCP by mac and that fails, apparently the socket is created before the IP is set up.
I want to exclude all but this interface from being served sshd. How am I going about that with ssh.socket?
What is the benefit of ssh.socket? The price is that ssh configuration is now split between the actual ssh daemon and systemd. I rarely read ssh documentation or even the comments in sshd_config anymore and was just baffled first that my settings are ignored, then that there was not /etc/systemd/system/ssh.socket.d but an ssh.service.d that apparently was not used. ssh.socket.d does of course not use sshd_config syntax. The package is named ssh, the documentation is named openssh. I had to find out that the actual documentation is in systemd.socket. All that was a bit annoying, since I had something else to accomplish and just wanted to log into that box.
It sounds like in the near future, ssh.service will be deprecated or somehow disabled, so I’m not sure if it’s a good idea to just ignore it and revert to ssh.service.
There must be some substantial benefit of using the socket mechanism? I didn’t find any mention anywhere what that in the case of sshd might be…
The problem with not using “/etc/ssh/sshd_config” is that if you stop sshd (sshd stop service), and start it (sshd start service) it takes the port from the “/etc/ssh/sshd_config” configuration file, and not from “/etc/systemd/system/ssh.socket.d/listen.conf”!
For me this is not a very good solution because it generates human errors!
A small comment in the config file on “#Port” would be a minimum and welcome
If you like a comment … to avoid the admin to waste their time
I am still wondering why Ubuntu would change something that has been working since the last century. For me the fixes didn’t work until I reverted back to the old configuration. So for me, this is 3 strikes.
1 strike for changing it in the first place.
2nd for the socket-based fix not working
3rd strike for inadequate documentation.
I did a search as to why socket based activation is “superior”. Supposedly it is there to minimize memory usage. Allegedly this reduces memory from 65MiB to 58Mib. I guess if this makes the ppl at Canonical happy but even a Raspberry PI 3B has 1 GB of memory.
I’m having similar issues with sshd on my ubuntu 22.10 installation. I have followed the instructions in /usr/share/doc/openssh-server/README.Debian.gz:
Sorry, it appears the documenation became inaccurate once we added /etc/systemd/system/ssh.service.d/00-socket.conf. If you remove this file (or rename it to be inactive) and then run the other two commands, it works as expected. Opened https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2017434 to track resolution of the documentation bug.
According to /usr/share/doc/openssh-server/README.Debian.gz (again, documetnation is spread everywhere, it’s hours to find anything), to make it pick up on the new address should require systemctl daemon-reload.
Except it doesn’t work … nothing I do seems to make it listen to my selected port
