Basic server protection: SSH, firewall, fail2ban

A fresh, unconfigured VPS is an open door: bots hammer SSH with password guesses around the clock and probe for holes. The good news — basic protection takes 15–20 minutes and blocks the vast majority of automated attacks. Below is a step-by-step minimum with commands for two OS families: Ubuntu / Debian (package manager apt, firewall ufw) and AlmaLinux / Rocky / CentOS (package manager dnf, firewall firewalld).

Where to start

• Update the system right after creating the server.
• Create a separate user with admin rights — do not work as root.
• Set up SSH key login and disable password login.
• Enable the firewall and leave only the needed ports open.
• Install fail2ban and automatic security updates.

Order matters. First set up and verify key login for the new user, and only then disable the password and root — otherwise you can accidentally lock yourself out. Keep a second SSH session open until you are sure the new login works.

1. System updates

Ubuntu / Debian

sudo apt update && sudo apt upgrade -y

AlmaLinux / Rocky / CentOS

sudo dnf upgrade -y

Then enable automatic security updates so critical patches install themselves.

Ubuntu / Debian

sudo apt install -y unattended-upgrades sudo dpkg-reconfigure -plow unattended-upgrades   # choose "Yes"

AlmaLinux / Rocky / CentOS

sudo dnf install -y dnf-automatic # in /etc/dnf/automatic.conf set: apply_updates = yes sudo systemctl enable --now dnf-automatic.timer

2. A separate user instead of root

Working as root is dangerous: any mistake or breach immediately gives full control. Create a regular user and grant admin rights. Note: on Ubuntu/Debian this is the sudo group, on AlmaLinux/Rocky/CentOS — the wheel group.

Ubuntu / Debian

sudo adduser myuser sudo usermod -aG sudo myuser

AlmaLinux / Rocky / CentOS

sudo useradd myuser sudo passwd myuser sudo usermod -aG wheel myuser

Check that the new user can run commands via sudo before restricting root.

3. SSH key login

A key is more reliable than a password and cannot be brute-forced. The commands below are the same for all OSes. If you do not have a key yet, create one on your own computer:

ssh-keygen -t ed25519 -C "my-laptop"

Copy the public key to the server (for the needed user):

ssh-copy-id myuser@server_IP # then verify key login: ssh myuser@server_IP

Never share the private key. Only the public key (.pub) is uploaded to the server. The private one stays on your device.

4. Hardening SSH settings

Once key login works, disable root and password login. The config file /etc/ssh/sshd_config is the same for all OSes. Set (or uncomment) the parameters:

PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes

Apply the changes. Important: the SSH service is called ssh on Ubuntu/Debian and sshd on AlmaLinux/Rocky/CentOS.

Ubuntu / Debian

sudo systemctl restart ssh

AlmaLinux / Rocky / CentOS

sudo systemctl restart sshd

Do not close the current session right away. Open a new SSH connection and make sure key login works. If something is wrong, you can revert the settings in the open session.

Changing the default port 22 to a non-standard one is optional, but it reduces the noise from bots in the logs. If you change the port, open it in the firewall (and on RHEL with SELinux enabled — also allow the port: sudo semanage port -a -t ssh_port_t -p tcp <port>).

5. Firewall

The rule is simple: close everything, open only what is needed (usually SSH and web ports). On Ubuntu/Debian this is ufw, on AlmaLinux/Rocky/CentOS — firewalld.

Ubuntu / Debian (ufw)

sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow OpenSSH        # or your SSH port sudo ufw allow 80 sudo ufw allow 443 sudo ufw enable sudo ufw status

AlmaLinux / Rocky / CentOS (firewalld)

sudo systemctl enable --now firewalld sudo firewall-cmd --permanent --add-service=ssh sudo firewall-cmd --permanent --add-service=http sudo firewall-cmd --permanent --add-service=https sudo firewall-cmd --reload sudo firewall-cmd --list-all

Allow SSH first, then enable the firewall. If you close incoming traffic without a rule for SSH, you can lose access to the server.

6. Brute-force protection (fail2ban)

fail2ban reads the logs and bans IPs that guess passwords. On Ubuntu/Debian it installs directly; on AlmaLinux/Rocky/CentOS you need the EPEL repository.

Ubuntu / Debian

sudo apt install -y fail2ban sudo systemctl enable --now fail2ban

AlmaLinux / Rocky / CentOS

sudo dnf install -y epel-release sudo dnf install -y fail2ban sudo systemctl enable --now fail2ban

Check the status and banned SSH addresses (the same everywhere):

sudo fail2ban-client status sshd

Configuration is in /etc/fail2ban/jail.local. There you set the ban time and the number of attempts. On RHEL, to protect SSH create an [sshd] section with enabled = true and backend = systemd (or logpath = /var/log/secure); on Ubuntu/Debian the SSH jail is enabled by default.

7. Remove the extras

• Fewer services — fewer risks. Disable what you do not use: sudo systemctl disable --now <service>.
• Check open ports: sudo ss -tulpn — only what is necessary should face outward (the command works on all OSes).
• Do not install software "to try it out" on a production server and remove unused packages.

SELinux on AlmaLinux/Rocky/CentOS — do not disable it. It adds a layer of protection. Keep the enforcing mode (check with getenforce). On Ubuntu/Debian, AppArmor, enabled by default, plays a similar role.

8. Backups are part of security

Even a perfectly protected server is worth being able to restore. Backups are protection against ransomware, mistakes and failures.

• Snapshots of the server in the serverplus panel — a quick rollback.
• Uploading data to serverplus S3 object storage — a copy separate from the server.
• The 3-2-1 rule: three copies, on two media, one off the server.

Test your restores. A backup you have never restored from is not yet a backup. Periodically try deploying a copy.

Short checklist

• The system is updated, automatic security updates are on.
• There is a separate admin user (sudo or wheel), root over SSH is disabled.
• SSH key login, SSH password disabled.
• The firewall is on (ufw or firewalld), only the needed ports are open.
• fail2ban is working.
• SELinux/AppArmor is in working mode; snapshots and S3 backups are set up.

FAQ

Is it mandatory to disable password login?

It is strongly recommended. A password can be guessed, a key practically cannot. If you need a password as a fallback, make it long and unique and be sure to install fail2ban.

The commands do not match my OS.

The article has two sets: apt/ufw for Ubuntu/Debian, dnf/firewalld for AlmaLinux/Rocky/CentOS. To find your system: cat /etc/os-release.

Should I change the default SSH port?

It is not "protection" in itself, but it reduces the flow of automated attacks and the clutter in the logs. On RHEL with SELinux, do not forget to allow the new port (see the SSH section). Useful together with keys and fail2ban, not instead of them.

I accidentally locked myself out of SSH. What do I do?

Use the web console (VNC) in the serverplus panel — it gives access to the server bypassing SSH. Through it you can revert the sshd_config settings or the firewall rules.

How do I know if someone tried to hack the server?

Look at the login logs and the fail2ban status. The login log is /var/log/auth.log on Ubuntu/Debian and /var/log/secure on AlmaLinux/Rocky/CentOS (or sudo journalctl -u ssh / sshd). Many failed attempts are normal for the internet; with keys and a firewall they are fruitless.