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
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 
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.
2 Likes
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…
This is the second change to SSH See Here - cannot disable Password Authentication
None of these changes have been visible to J.Average.Users like myself as we don’t lurk on Ubuntu forums and quite frankly reading change notes is tedious.
Both these changes are major changes to the security model / setup used by Ubuntu.
PUT NOTES INTO THE SSH_CONFIG file next to Ports, ListenAddress and the Password authentication settings ( plus any other settings you have changed ) warning users you have majorly altered basic functionality.
I personally lost several hours thinking it must be ISPConfig updates or some other security software messing with the systems. It never occurred to me to not trust package managers to refrain from altering settings which are almost as old as Linux.
But again - put notes next to major settings you have altered with big exclamation marks, capital letters and a warning sign. This has serious impact on basic Ubuntu security - as did the previous change to sshd usage mentioned above. It locks people out after an update, it changes settings behind people after they have performed best practice security setups. Thats bad process.
1 Like
Absolutely agree.
Using the new socket activation design without thorough documentation and comprehensive testing is both unwise and unreasonable. CrowdStrike serves as a cautionary example recently.
As described, the socket activation design can indeed reduce memory usage.
However, this design is currently not fully developed and has significant flaws. For example, sshd-socket-generator cannot correctly handle complex configurations like Match statements, leading to inconsistencies with the original design and potential security issues.
Given that the SSH server is a critical component of the system, any significant changes that impact its usage should be prominently displayed on the Ubuntu website, especially for LTS versions.
Additionally, since the socket activation design for sshd is not yet fully developed (sshd_config can not take effect as expected in some cases), I believe it is best to avoid making this the default behavior to minimize potential problems. Once the design is fully developed and free of major bugs, gradual implementation may be considered (with user consent, along with proper documentation and training).
1 Like
Ubuntu 24.04 disable socket activation of sshd quickly:
operation below may be needed, remember to backup
sudo rm -f /etc/systemd/system/ssh.service.d/*
sudo rm -f /etc/systemd/system/ssh.socket.d/*
described in /usr/share/doc/openssh-server/README.Debian.gz
sudo mkdir -p /etc/systemd/system-generators/
sudo ln -s /dev/null /etc/systemd/system-generators/sshd-socket-generator
sudo systemctl daemon-reload
sudo systemctl disable --now ssh.socket
sudo systemctl enable --now ssh.service
Caution:
sudo mkdir -p /etc/systemd/system-generators/
sudo ln -s /dev/null /etc/systemd/system-generators/sshd-socket-generator
sudo systemctl daemon-reload
is needed to ensure that it can take effect after reboot.
Sooo … my previous comments about ADDING DOCUMENTATION TO CHANGES!!! seems to be ignored as another massive change takes place.
I had updated the scripts, documentation, security practices for installing and securing new Ubuntu servers when I discovered you couldn’t chang eport in /etc/ssh/sshd_config any more , as they had added /etc/ssh/sshd_config.d/ 50-cloud-init.conf` file in with no warnings.
I just installed another new Ubuntu server, set up scripts to sort out that issue as well as fix the new issues with ports not changing (addressed by this thread).
the latest version of Ubuntu LTS installed on a Linode has no /50-cloud-init.conf file anymore.
There is no note about this in the etc/ssh/sshd_config file ( near the include directive would have been ideal).
While its not a huge deal it is another sign that there is a lack of actually putting notes and help where Jo(e) Average users will see there’s been a major shift in how we configure security in servers.
First there was no /50-cloud-init.conf file, then there was one and now there’s none again - all within two LTS versions.
This in no way resembles best practice and for folks like me trying to run secure systems by using scripts, strong documentation and strong practice of double checking settings - this is hugely disrupting of our good practice.
A note at the source of the disruption (e.g. sshd_config file) would be really appreciated as a bare minimum of good practice.