I share services with the public, so… strong passwords on everything, MFA, host scanning, SSH MAC/KEX/ciphers tweaked to ultra modern set and exposed only with keys with f2b activating on first failure, constant backups and automatic updates and scheduled reboots. Has worked great for a decade+.
Did you buy chance do a release upgrade? I had this happen in a headless VM I run, upgrading from 20.04 to 22.04 VM would become unresponsive (go to sleep) and I would have to wake it up. For whatever reason, a full desktop gui and accessories had been installed. So I ripped all that out via apt and everything was ok after that. This VM has been upgraded over before from 18, and has been running for years so I had not seen this issue before (it runs my Plex server and a bunch of accessory docker containers).
Nextcloud coupled with the Collabora (CODE) application suite.
Permissive mode is definitely a life saver. My path was usually exercising the application in permissive mode for a few days then running the SELinux scanner on the log file to determine what roles needed to be setup. Same with the Debian/Ubuntu equivalent.
Good luck!
What is the reason to shy away from Ubuntu? It is pretty solid in terms of automatic updating and rebooting. I used to be hardcore centos but I gave up after all of the hubbub around 8. I just need to server to update, reboot when necessary and keep running all my stuff so I don’t have to touch it. In my old age, I don’t care to tinker anymore - I just want my services running and I want reports given to me about health and status.
Also, if you’re concerned about privilege escalation, running a MAC is probably a good idea. SELinux saved my hide one a dozen years ago with a php bug where I did not sandbox an app properly. Thankfully, SELinux caught this and prevented anything bad from happening.
Secure SSH. You should disable all password login capability and tighten the ciphers, KEX and MAC requirements. This will force modern SSH terminal use, something a lot of bots don’t do, so they won’t even get to the point of key exchange.
On your client, you can define an SSH config with a list of friendly host names that include direct IP addresses, the key to use to initiate login and whatever other properties you need. This way, you can just type in “ssh” and you don’t need to specify the key or IP address every time.
Finally, configure Fail2Ban to ban/block on first failed SSH attempt. You won’t be falling to login if you’ve configured a config definition file and are using keys.
It’s new enough that you don’t need torrents. Just grab it from Usenet.