Key takeaways
- Most break-ins on hosting servers start with a guessed password, an outdated package or one site that can read another, so fix those three first.
- Use SSH keys, turn password logins off and keep a second session open while you test the change, so a typo cannot lock you out.
- Open only the ports you serve (22, 80, 443 and mail if you run it) and let a tool such as fail2ban ban repeated failures.
- A hardened server you cannot restore is not safe: test one backup restore and keep a copy off the server.
Hardening a Linux server for hosting is mostly a list of small jobs that you do once and then check now and then. This guide is written for Ubuntu and Debian servers where you have root, and the same ideas apply to other distributions with different package names. For the longer, panel-neutral list see the hosting panel security checklist.
1. Lock down SSH
Create a key pair on your own computer, copy the public key to the server with ssh-copy-id, and confirm that you can log in with it. Only then change /etc/ssh/sshd_config (or a file under /etc/ssh/sshd_config.d/):
PasswordAuthentication noandKbdInteractiveAuthentication no, so only keys work. The OpenSSH manual lists both asyesby default, as of 30 October 2026 (sshd_config).PermitRootLogin prohibit-passwordis already the default, andnois stricter if you log in as a normal user with sudo.MaxAuthTries 3instead of the default of 6.
Check the file with sshd -t, reload with systemctl reload ssh, and keep your current session open while you log in from a second window. If the second login fails, you can still fix the file.
2. Close every port you do not serve
On Ubuntu, UFW is the simple front end to the firewall (Ubuntu firewall documentation). Allow SSH first, then what you host, then switch it on:
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
Add mail ports (25, 465, 587, 993) only if this server runs mail. Databases such as MariaDB and Redis should listen on 127.0.0.1 and never be open to the internet. Run ss -tlnp and make sure you can name every listening service.
3. Ban repeated failures
Install fail2ban (apt install fail2ban), copy /etc/fail2ban/jail.conf to jail.local, and enable the sshd jail. Add jails for your web server and mail server if you run them. Bans reduce noise and slow guessing, but they come after keys and the firewall in importance.
4. Update automatically
Install unattended-upgrades and enable it with dpkg-reconfigure -plow unattended-upgrades on Ubuntu or Debian. Security updates then install daily. A kernel update needs a reboot, so check /var/run/reboot-required weekly. Updates for PHP, your CMS and its plugins are separate and are where most hacked sites come from, so give them their own schedule.
5. Isolate every site
If every site runs as the same user, one hacked plugin can read every other customer's files. Give each site its own system user and its own PHP FPM pool, set file modes so other users cannot read it, and keep each site's database user limited to its own database. This is the biggest difference between a shared host that survives an incident and one that loses every customer at once. Panels do this for you; by hand it is a pool file per site.
6. Log and watch
Keep authentication and web logs for at least a few weeks, and send them somewhere other than the server when you can. Look for a rise in failed logins, new users, new cron jobs and files changed in /etc. A tool like auditd or a file integrity checker is worth adding once the basics are done.
7. Back up and test a restore
Take a daily backup of files, databases and mail, store it off the server, and encrypt it. Then restore one site to a spare place and time how long it takes. The test is the part most people skip, and it is the one that matters on the bad day.
8. Check from outside
Scan your own server from another machine with nmap -sV your.server.ip and confirm that only the ports you opened answer. Run ssh -o PubkeyAuthentication=no user@your.server.ip and confirm that it refuses a password. Repeat after every big change.
Where a panel helps
A panel such as RespireCloud does steps 4 to 7 per site for you (isolation, backups, logs), but it does not replace steps 1 to 3 on the operating system. Do those first, whichever panel you use.
Questions
Should I change the SSH port?
It cuts log noise from bots but is not security on its own. Keys, no password logins and a firewall matter far more. If you move it, allow the new port in the firewall before you restart sshd.
Is fail2ban enough?
No. It slows down guessing, but it does nothing about an outdated package or a weak site password. Treat it as one layer next to keys, updates and a firewall.
How often should I patch a hosting server?
Security updates should install automatically every day, and you should look at the server weekly for kernel updates that need a reboot. Panels, PHP and WordPress plugins need their own update routine.
Do I need to do this if I use a control panel?
Yes. A panel manages sites, not the operating system under it. Read your panel's own security notes and still lock down SSH, the firewall and updates.
