How to secure a new Linux server in the first hour
A new server is reachable from the internet the moment it boots. These steps close the most common gaps before you install anything else. Commands are shown for Ubuntu and Debian, with notes for AlmaLinux, Rocky Linux and other RHEL-family systems.
$ ssh [email protected]
Welcome to Ubuntu 26.04 LTS (GNU/Linux x86_64)
root@vps:~# apt update && apt upgrade -y
0 upgraded, 0 newly installed, 0 to remove.
root@vps:~# ufw allow 443/tcp
Rule added
root@vps:~# systemctl is-active nginx
active
root@vps:~#
The short answer
Update the system, create your own user with sudo rights and log in with an SSH key, then turn off password and root logins over SSH. Allow only the ports you need through a firewall, switch on automatic security updates and set up backups that you have restored at least once.
$ ssh [email protected]
Welcome to Ubuntu 26.04 LTS (GNU/Linux x86_64)
root@vps:~# apt update && apt upgrade -y
0 upgraded, 0 newly installed, 0 to remove.
root@vps:~# ufw allow 443/tcp
Rule added
root@vps:~# systemctl is-active nginx
active
root@vps:~#
The first-hour checklist
Work through the steps in this order. Each one is explained below.
Install all updates first
Install every pending update and reboot if the kernel changed.
Work as a sudo user, not as root
Do daily work as a named user and use sudo for administration.
SSH keys instead of passwords
Allow SSH keys only and stop direct root logins.
A firewall that denies by default
Deny incoming traffic by default and allow SSH and the services you run.
Automatic security updates
Let the server install security fixes by itself.
Backups you have tested
Keep copies away from the server and prove that you can restore them.
Update the system and create your user
1. Update the system
The commands below assume a user with sudo rights; if you are still logged in as root, leave out sudo. Start with a fully patched system. On Ubuntu and Debian:
sudo apt update
sudo apt full-upgradeOn AlmaLinux, Rocky Linux and other RHEL-family systems, run sudo dnf upgrade. Reboot if the kernel was updated.
2. Create a user with sudo rights
Working as root makes every typing mistake a system-wide risk. Create your own user and give it administrator rights:
adduser alex
usermod -aG sudo alexOn RHEL-family systems the administrator group is wheel: create the user with useradd -m alex, set a password with passwd alex and run usermod -aG wheel alex.
The same steps on Ubuntu, Debian and the RHEL family
Commands in this guide are for Ubuntu and Debian. The note under each one gives the equivalent on AlmaLinux, Rocky Linux and other RHEL-family systems.
| Install updates | sudo apt update && sudo apt full-upgradeRHEL family: sudo dnf upgrade |
|---|---|
| Administrator group | sudoRHEL family: wheel |
| Restart the SSH service | sudo systemctl restart sshRHEL family: sudo systemctl restart sshd |
| Firewall | UFWRHEL family: firewalld |
| Automatic security updates | unattended-upgradesRHEL family: dnf-automatic |
Lock down SSH
3. Log in with an SSH key
On your own computer, create a key pair and copy the public key to the new user. The private key stays on your computer; protect it with a passphrase.
ssh-keygen -t ed25519
ssh-copy-id [email protected]Open a new terminal and confirm that ssh [email protected] logs you in with the key before you change anything else.
4. Turn off password and root logins
Put your SSH settings in a file of their own. OpenSSH uses the first value it reads for each option, and current Ubuntu, Debian and RHEL-family releases read the files in /etc/ssh/sshd_config.d/ before the rest of the main configuration, so a file whose name sorts first takes effect:
sudo nano /etc/ssh/sshd_config.d/00-hardening.confPermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yesCheck the syntax with sudo sshd -t and list the settings that are really in effect with sudo sshd -T. Then restart the service: sudo systemctl restart ssh on Ubuntu and Debian, sudo systemctl restart sshd on RHEL-family systems. Keep your current session open and test a new login in a second terminal, so that a mistake cannot lock you out.
Keep a way back in
Test every SSH or firewall change in a second session before you close the first. If a change still locks you out, use the server console in the client area where your plan provides one, or open a support ticket.
Turn on the firewall and automatic updates
5. Turn on a firewall
Allow SSH first and then switch the firewall on, so that you do not cut your own connection. On Ubuntu, UFW is installed by default; on Debian, install it with sudo apt install ufw.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enableOn RHEL-family systems firewalld is the usual tool, and SSH is allowed in its default zone: open a service with sudo firewall-cmd --permanent --add-service=https and apply it with sudo firewall-cmd --reload. Open only the ports of services you actually run. Moving SSH to another port reduces log noise, but it is not protection on its own; keys and a firewall are.
6. Automatic security updates
Ubuntu installs unattended-upgrades by default and applies security updates automatically; confirm that it is enabled with sudo dpkg-reconfigure -plow unattended-upgrades. On Debian, install the same package first. On RHEL-family systems, install dnf-automatic, set apply_updates = yes in /etc/dnf/automatic.conf and enable it with sudo systemctl enable --now dnf-automatic.timer. Some updates, such as a new kernel, take effect only after a reboot, so plan a regular maintenance window.
7. Time, services and repeated login attempts
Keep the clock correct, because logs, certificates and two-factor codes depend on it.
| Time synchronisation | timedatectlShows whether time synchronisation is active |
|---|---|
| Services on the network | sudo ss -tulpnLists the services that listen; disable those you do not need |
| Repeated login attempts | Fail2banBlocks addresses that fail repeatedly on services that still accept passwords |
8. Backups you can restore
A backup is proven only once you have restored it. Follow the 3-2-1 idea: three copies of your data, on two different kinds of storage, with one copy away from the server.
-
Snapshot before risky changes
Take a snapshot before upgrades and other risky changes, where your plan offers snapshots.
-
Schedule regular backups
Schedule database dumps and file backups to a location away from the server.
-
Restore to a test system
Restore a backup to a test system to check that it works, and repeat the test regularly.
Common mistakes
Locking yourself out
Test every SSH or firewall change in a second session before you close the first.
Leaving password logins on
Automated scripts try common passwords against servers all over the internet.
Running everything as root
Give each application its own user with only the rights it needs.
Leaving test ports open
Close temporary ports and admin panels when you are done, or limit them to your own IP address.
Skipping updates
Many attacks use known flaws for which a fix already exists.
Untested backups
Restore regularly: a backup that cannot be restored does not protect you.
Linux servers with full root access
-
Linux VPS Hosting
Linux VPS Hosting grants you more control and freedom with virtual private servers, particularly suited for Linux-based projects, offering excellent performance and customization.
Starting from $4.20/m -
Linux VDS Hosting
Linux VDS Hosting is scalable and high-performance, utilizing virtual dedicated servers to cater to your Linux-based projects.
Starting from $29.90/m -
Nested Dedicated Server Hosting
Nested Dedicated Servers provide dedicated server performance within a virtual environment, offering scalability and cost-efficiency.
Starting from $55.00/m -
America Dedicated Server Hosting
With Dedicated Server Hosting, you have exclusive access to a physical server, providing high performance and customization options.
Starting from $100.00/m
More guides
VPS vs VDS vs dedicated server
What each term means, how to tell when you have outgrown a VPS, and when bare metal is worth it.
Learn moreChoosing a macOS server for iOS CI
Xcode and macOS versions, Apple silicon, sizing, the CI runner and code signing.
Learn moreMove a website without downtime
A step-by-step plan for files, databases, DNS, SSL and email.
Learn moreDNS basics for a new domain
Nameservers, records, TTL and the email records every domain needs.
Learn moreChoose a data center location
How distance becomes latency, how to measure it and what data rules mean for location.
Learn moreFrequently asked questions
Should I change the SSH port?
It reduces automated noise in your logs, but it does not stop a targeted attacker. Key-only authentication, a disabled root login and a firewall protect the server. If you change the port, allow the new port in the firewall first.
Do I need a firewall if only SSH and a web server are running?
Yes. A firewall that denies by default protects you from services you install later or forget about, and keeps what is reachable limited to the ports you chose.
How can I add two-factor authentication to SSH?
Use a hardware security key with an OpenSSH key type such as ed25519-sk, or a one-time password module for PAM. Keep a tested fallback way to log in.
What if I lose my SSH key?
Log in through the server console in the client area where your plan provides one, or contact support. Then add a new public key and remove the lost one from ~/.ssh/authorized_keys.
Which Linux distribution should I choose?
One you already know, or a long-term support release such as Ubuntu LTS, Debian or AlmaLinux. The order form lists the images available for each plan.
Should I turn off root login over SSH if I use keys?
Yes. With PermitRootLogin no, attackers cannot aim at the one account name every Linux server has, and administrative work runs through your own user and sudo, which records who did what in the logs. Make sure your own user can log in with its key and use sudo before you change the setting.
How often should I update my server?
Let automatic updates install security fixes as they are released, and plan a regular maintenance window, for example once a month, for reboots and other updates. Some updates, such as a new kernel, take effect only after a reboot. Before larger upgrades, take a snapshot where your plan offers one, or a backup, so that you can go back if something breaks.
How can I see who tried to log in to my server?
Read the log of the SSH service: journalctl -u ssh on Ubuntu and Debian, journalctl -u sshd on RHEL-family systems. Failed attempts from many addresses are normal background noise on the internet, and with key-only logins they cannot succeed. Watch instead for successful logins that you do not recognise.
Questions before you order?
Send us a message and our team will help you choose the right service.