When beginners get a new VPS, their first instinct is often to set up the environment and launch a website, leaving security hardening for last. However, an unprotected VPS exposed to the public internet will be detected by automated scanners within minutes. Brute-force attacks, port scanning, and vulnerability probing—these aren't just possibilities; they are happening right now.

Hardening your server doesn't require advanced technical skills or a massive, one-time configuration overhaul. By following a few basic steps in order, you can reduce the risk of a breach by over 90%. This article provides a hardening checklist for beginners, complete with specific commands and verification methods for each step.

Three Golden Rules of Security Hardening

Keep these three principles in mind before you start. Each addresses a common mistake made by beginners.

Rule 1: Don't disable password login until key-based login is verified. Many users disable password authentication immediately after setting up SSH keys, only to find a configuration error that locks them out of their server. The correct approach: after configuring the keys, open a new terminal window to log in using the key; once you confirm the connection works, then disable password login.

Rule 2: Don't enable the firewall before allowing the SSH port. Enabling UFW (Uncomplicated Firewall) defaults to blocking all incoming traffic. If you run `ufw enable` without first allowing the SSH port, your current connection will drop immediately, and you won't be able to reconnect. Always allow the SSH port in the firewall rules before enabling the firewall itself.

Rule 3: Keep your current session open when making changes that could disconnect SSH. Do not close your active SSH session while modifying SSH configurations, firewall rules, or network settings. If a configuration error prevents reconnection, you can use the active session to revert the changes.

Step 1: Update the system and apply patches

A newly provisioned VPS may not have been updated for months—or even longer—leaving it vulnerable to numerous known security flaws. This is the most fundamental step, yet it is also the one most frequently skipped.

After logging in via SSH, run the following commands:

Ubuntu / Debian

apt update && apt upgrade -y

CentOS / Rocky Linux

yum update -y

This step updates all system packages to their latest versions. If a reboot is required (e.g., after a kernel update), run the `reboot` command. Do not skip this step—many compromised servers were breached simply because they hadn't been patched for months.

Step 2: Create a standard user and stop logging in directly as root

Never use the root account for routine tasks. Root privileges are excessive; if the account falls victim to a brute-force attack, the entire server could be completely compromised.

Create a standard user (using `deploy` as an example):

adduser deploy

usermod -aG sudo deploy

Switch to the new user and verify sudo privileges:

su ​​- deploy

sudo whoami

If the output is `root`, the configuration was successful.

Step 3: Configure SSH key-based authentication

Password-based logins are prime targets for brute-force attacks. Switching to key-based authentication fundamentally eliminates the possibility of such attacks.

Generate a key pair on your local machine (Mac/Linux/WSL):

ssh-keygen -t ed25519 -C "your_email@example.com"

Simply press Enter through the prompts. The private key is saved at `~/.ssh/id_ed25519`; never share this file with anyone.

Upload the public key to the server:

ssh-copy-id -p 22 deploy@your_server_ip

If this step fails, you can copy it manually: run `cat ~/.ssh/id_ed25519.pub` locally, copy the output, and then run the following commands on the server:

mkdir -p ~/.ssh

echo "paste_public_key_content_here" >> ~/.ssh/authorized_keys

chmod 600 ~/.ssh/authorized_keys

Crucial verification step: Do not close your current session. Open a new terminal window and log in using the key:

ssh -i ~/.ssh/id_ed25519 deploy@your_server_ip

Proceed to the next step only after confirming you can connect successfully.

Step 4: Modify SSH configuration to disable password login

You can now safely modify the SSH configuration. Edit the configuration file:

sudo vim /etc/ssh/sshd_config

Locate and modify the following settings:

Disable root login

PermitRootLogin no

Disable password authentication

PasswordAuthentication no

KbdInteractiveAuthentication no

ChallengeResponseAuthentication no

Enable key-based authentication

PubkeyAuthentication yes

After saving, check the configuration syntax for errors:

sudo sshd -t

If there are no errors, restart the SSH service:

sudo systemctl restart sshd

Important: Do not close your current session after restarting. Open a new terminal and verify the connection using your key. If you can connect, the configuration was successful.

Step 5: Configure the firewall to open only necessary ports

The firewall principle is: deny all inbound traffic by default and allow only the ports required for your services.

For Ubuntu / Debian, use UFW:

Allow the SSH port first (default is 22 unless you changed it)

sudo ufw allow 22/tcp

If you have deployed web services, allow ports 80 and 443

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

Set default policies

sudo ufw default deny incoming

sudo ufw default allow outgoing

Enable the firewall

sudo ufw enable

Check the rules after enabling:

sudo ufw status numbered

For CentOS / Rocky Linux, use firewalld:

sudo firewall-cmd --permanent --add-port=22/tcp

sudo firewall-cmd --permanent --add-port=80/tcp

sudo firewall-cmd --permanent --add-port=443/tcp

sudo firewall-cmd --reload

Verification: After enabling the firewall, open a new terminal and attempt an SSH connection. If successful, the SSH port has been correctly allowed.

Step 6: Install Fail2Ban to automatically block brute-force attacks

Even if password login is disabled, Fail2Ban is still worth installing; it automatically blocks suspicious IPs making repeated connection attempts, reduces log noise, and lowers the risk of being scanned.

Installation:

Ubuntu / Debian

sudo apt install fail2ban -y

CentOS / Rocky Linux

sudo yum install fail2ban -y

Configure SSH protection. Do not modify `jail.conf` directly (it will be overwritten during upgrades); instead, create `jail.local`:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

sudo vim /etc/fail2ban/jail.local

Locate the `[sshd]` section and modify it as follows:

[sshd]

enabled = true

port = 22

filter = sshd

logpath = /var/log/auth.log

maxretry = 3

bantime = 3600

findtime = 600

Parameter explanation: `maxretry` is the maximum number of failed attempts (3), `bantime` is the duration of the ban (3600 seconds = 1 hour), and `findtime` is the detection window (600 seconds = 10 minutes). If you have changed the SSH port, update the `port` setting accordingly.

Start the service and enable it to launch on boot:

sudo systemctl restart fail2ban

sudo systemctl enable fail2ban

View the list of banned IPs:

sudo fail2ban-client status sshd

Step 7: Enable automatic security updates

It is easy to forget to apply patches manually. Enable automatic security updates to allow the system to install critical security patches in the background.

Ubuntu / Debian:

sudo apt install unattended-upgrades -y

sudo dpkg-reconfigure --priority=low unattended-upgrades

Select "Yes" in the pop-up interface to enable automatic updates.

CentOS / Rocky Linux:

sudo yum install dnf-automatic -y

sudo systemctl enable --now dnf-automatic.timer

Note: By default, automatic updates install only security patches and do not automatically reboot the system. If the kernel is updated, a manual reboot is required for the changes to take effect. It is recommended to periodically check for updates that require a reboot.

Why the choice of infrastructure layer is equally important

The seven steps above cover software-level hardening. However, the VPS's network quality and underlying security also determine its fundamental resilience against attacks.

A VPS with poor network connectivity—even one with a rigorously configured system—may suffer from frequent timeouts and packet loss due to inherent network link flaws. Conversely, a server connected to a high-quality network reduces the likelihood of interference from abnormal traffic right at the network layer. Jtti’s cloud server solutions provide robust support at the infrastructure level. Nodes in Hong Kong and the US connect via premium CN2 GIA lines with optimized direct routing across major carriers, maintaining a packet loss rate below 0.1% even during peak evening hours; this stable connection quality ensures that anomalous traffic is less likely to disrupt your normal business operations. Dedicated bandwidth comes standard across the entire product line, eliminating the risk of "collateral damage" where your server suffers because a neighboring server is under attack. Select nodes also include complimentary DDoS protection, adding an extra layer of network security for your business.

In terms of configuration, Jtti offers a comprehensive range of options, from entry-level 1-core/1GB plans to enterprise-grade 8-core/16GB setups. A "same-price renewal" policy ensures that the renewal cost matches the initial purchase price, allowing for predictable costs for servers requiring long-term, stable operation.

Security hardening is not a one-time task but an ongoing process. By completing the seven steps outlined above, you establish a fundamental line of defense for your VPS. The biggest pitfall is often not technical complexity, but the mindset that such measures are "unnecessary"—yet spending just 20 minutes on these steps can save you from countless future headaches. Visit the Jtti website to view full specifications and current promotions for Hong Kong and US CN2 cloud servers, and select a server with a solid foundation for your security hardening strategy.