An important thing to know is that most automated exploitation techniques are only effective against old and outdated software. It's very rare someone will burn a 0day on the public internet.

My personal recommendations, ordered by importance, sort of, maybe:

- Minimize attack service: don't install it if you don't need it

- Assume you'll be compromised at some point. NSA servers get hacked. FSB servers get hacked. You're not better than them. Think of what you'll do when you get hacked: do you need to rotate keys, change passwords, delete tokens? It's better to have a plan, even if it's a vague idea, just in case.

- Think about who might hack you, and how. Are you an activist? You may have opponents that want to attack you directly. Are you just some guy with a blog? Focus on defending against your most probable attackers, like botnets and automated scripts. You can make grand plans for when the NSA tries to break into your secure server network, but in practice you should probably be fine if you just defend against botnets. You can find entire threat analysis guides on the internet but a quick think about "who will attack me why and how will they do it" will probably do.

- You probably won't get hacked. Don't become too paranoid; just taking the bare basic steps to prevent getting hacked will make you more secure than millions or even billions of hosts on the web.

- Install software in a way that automatic security updates will take care of common vulnerabilities (i.e. prefer apt-install over ./configure && make && sudo make install or curl | bash).

- Check how quickly your upstream sources (Termux, in this case) are issuing patches. I haven't checked Termux' security stats myself, but I'd personally try a Debian chroot over a Termux environment just because Debian has more funds available to provide timely updates.

- Principle of least privilege: barely anything needs root anymore. Ignore outdated guides and use separate users (or even random user IDs with systemd), it'll probably work. If your server provider gives you a root account, create a normal account, give it sudo permissions, and disable remote root login; root should only be for system maintenance and repair!

- Read the manual for suspicious config you copy/paste. Sometimes config is just data (hostnames etc.) but sometimes config disables or overrides default config; for those cases, think "why is this not on by default"

- When in doubt, update. Auto-update if you have to. I've run sudo apt update && sudo apt upgrade -y" in a cron job for years but there are better options for most server OS's. On Ubuntu (and probably Debian) run sudo dpkg-reconfigure unattended-upgrades to configure automatic security updates

- If you do install stuff manually (downloading a binary, curl2bash, etc.) then find out how to update such software and think of ways to automate the process

- Listen to warning messages. For example, many old Ubuntu guides will have you add PPAs in a manner that will give the security keys of a PPA the ability to sign packages from the main system repos. You'll get warnings if you use this method on a modern system and you should probably heed those.

- Reboot your server after important kernel updates. If you can afford the downtime, reboot after every update just to be sure; if you can't, check if any important patches were released during the past few days. You can often monitor the reboot status file (/var/run/reboot-required, for example) to see if a reboot is necessary.

- Make sure your services come back up after a reboot. One of my servers has a nasty firewall configuration bug somewhere that I haven't been able to track down that causes the firewall to refuse to start on boot. Better to find out that your server isn't reboot safe during a planned maintenance window than when you need the service and it suddenly stops working!

- An important file doesn't exist unless it's at three places, at least two which are in a different geographical location. Make backups!

- Test if you can recover from backups. An untested backup is a non-functional backup.

- Back up recovery/security keys to a safe location. Your fancy, unbreakable hard drive encryption is useless if you forget your password!

- When using Docker, make sure to update regularly. It's very easy to deploy a docker application and forget to update it for years!

- Even if nothing is going on, log in every now and then and check how your server is doing.

- Keep an eye on exploit/security lists for software that you expose publicly, especially if you're not updating them automatically. There are websites that will list all important new vulnerabilities for only certain projects (I use the RSS feed provided by the Dutch government, but others likely exist).

- When you see your server might be vulnerable, don't panic. Vulnerability descriptions often start with "an unauthenticated user may execute code and take over the system and turn the sky red and..." and end with "if the administrator has enabled the enable_apple_II_compatibility setting". For example, the Samba/SMB bug that allowed code execution on NAS devices only applied when the optional AppleTalk extension was enabled, which was commonly disabled by default.