Sorry if I’m missing the obvious, but documentation in Ubuntu in general is so terrible to find…
After changing the port in /etc/systemd/system/ssh.socket.d, what do I need to do to make it take effect ? (without rebooting the machine that is)
1 Like
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 
Disabling the system socket thing makes it work:
systemctl disable --now ssh.socket
systemctl enable --now ssh.service
Now it is listening to the new port.
1 Like
A bit more searching and this stack overflow question answered it:
I needed to add and extra “ListenAddress=” line, with an empty address !? Yes … those undocumented mysteries … But then it works.
1 Like
Breaks SSH access for anyone using /etc/ssh/sshd_config on Ubuntu 22.10, 23.04, 23.10…
RIP those who block Port 22. Hope ya’ll had backups or physical access. 
@vorlon
NEEDS to be added to the OP… make this google-able.
To go back to previous SSH behavior:
sudo rm /etc/systemd/system/ssh.service.d/00-socket.confsystemctl disable --now ssh.socketsystemctl enable --now ssh.servicesudo systemctl daemon-reloadsudo systemctl restart ssh
Thanks
7 Likes
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.
2 Likes
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 https://bugs.launchpad.net/ubuntu/+source/openssh/+filebug (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.
https://askubuntu.com/questions/1483893/unable-to-change-ssh-port-on-ubuntu
Edit /etc/systemd/system/sockets.target.wants/ssh.socket .
then amend
[Socket]
ListenStream=2222
Accept=no
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 
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.
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…