SSHd now uses socket-based activation (Ubuntu 22.10 and later)

Thanks @geenat for your comment.
It took me like an hour trying to figure out why I couldn’t set a custom SSH port, then read about the “issue” and then get the official revert commands to work. The official documentation in regards to reverting is pretty much worthless, as it only mentions 3 out of 5 steps, and have I not found this thread I’d still be wondering what I’m doing wrong.


How does SSHd on socket respond with Cockpit installed? As remote server connections with Cockpit are handled by SSHd, cause if Cockpit is expecting it as a service then well, YIKES if it doesn’t start in time by socket.

I hope fixes are in place upstream for Cockpit as this is software which can likely be irritated by this change.

I can confirm this does NOT work when running in a container. The transient directory /run/sshd is NOT getting created in the start process and therefore sshd dies on boot.

The place to report bugs against the package is (or using ‘ubuntu-bug openssh-server’).

The /run directory is created by /usr/lib/tmpfiles.d/openssh-server.conf and this has been verified to work in containers.

The README.Debian in openssh-server has been updated as of version 1:9.3p1-1ubuntu1 in mantic to include a complete and up-to-date set of instructions for reverting socket-based activation.

Point taken however that the README is wrong in existing stable releases, and this post pointed to that README. Post updated to detail the correct steps, instead.

1 Like

In the end this worked for me.
Edit /etc/systemd/system/ .
then amend


In 24.04 LTS it should be sufficient to declare your ports in sshd.conf.

1 Like

Imagine, for a moment, you are a sysadmin having just set up your Ubuntu 24 host.

You sit back in your chair, sipping your coffee, and relax – because you have either changed the Port directive in /etc/ssh/sshd_config or run “sudo service ssh stop”, maybe even “sudo systemctl stop ssh” – as you have done for over a decade.

Then you spit your coffee out as you run “lsof” and discover “systemd” is still running ssh server, and still listening on port 22. You scour /usr/share/openssh/sshd_config but find no mention of anything new related to ports. You check the man page - nothing. You even run sshd -D interactively and that shows the correct port!

Eventually you give up, fire up your 3G modem, and painfully wait for this discussion to load, and wish you could get the last hour of your life back.

This is, of course, a hypothetical scenario which I am certain would not happen to anyone in real life. It is meant as a lighthearted and whimsical anecdote to diffuse and de-escalate any possible tensions, and inspire creative thinking.

I am just one of those, who went in this trap. Even in man sshd_config does the options Port and ListenAddress do not give a hint about these changes.

The manpage does not mention this because the implementation changed since this discourse post was originally written. As noted already at SSHd now uses socket-based activation (Ubuntu 22.10 and later) - #32 by vorlon, you do NOT have to manage your ports under /etc/systemd anymore, you just need to manage sshd.conf as before.

I have updated the main post to clarify this.

Well, I had my first ubuntu 24 steps today (coming from ubuntu14->ub16->ub20) on a fresh installation. First steps went well and I configured the system to my needs. So I came along the sshd config. Adding my additional ssh port to /etc/ssh/sshd_config, then restarting sshd and started wondering. Using netstat, I didnt see the sshd process owning the sshd-ports - instead its owned by init - and restarting sshd does not add additional sshd port from the config /etc/ssh/sshd_config - but restarting the complete system does. thats somehow weird. The manpage did not give a hint to the changed behavoir.
I appreciate your and ubuntu’s devs work to enhance the os. but I cant read your mind :wink:

1 Like

Could you file a bug report about the fact that changes aren’t picked up on service restart?

Behavior changes between releases of an operating system are to be expected.

However, this is a prominent behavior change that should have been documented in the 24.04 LTS release notes - but due to oversight was not.

This has now been corrected.

As mentioned in the preceding comment, the fact that a service restart is insufficient to pick up changes to the ports in the sshd config is unintended behavior (though retrospectively it is straightforward to understand how this behavior has come to pass) and we should handle this as a bug in the package.

I created a bug report.


So I was questioning my sanity the other day.

sshd reinstalled itself on port 22 after upgrade from previous LTS to 24.04. Changing port in sshd_config and restarting sshd did not help. Breaking sshd_config and restarting demostrates that config file is actually being read - it fails to restart as expected. Then ps ax|grep sshd, changing port, then restarting, then ps ax|grep sshd clearly demonstrates that sshd is actually restarted and yes it actually reads the sshd_config.

Except it still bound to port 22.

Then I have found this thread…