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.
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.
- Install all updates first
- Work as a sudo user, not as root
- SSH keys instead of passwords
- A firewall that denies by default
- Automatic security updates
- Backups you have tested
The first-hour checklist
Work through the steps in this order. Each one is explained below.
1. Update the system
Install every pending update and reboot if the kernel changed.
2. Create a sudo user
Do daily work as a named user and use sudo for administration.
3. Add your SSH key
Create an Ed25519 key on your computer and copy the public key to the server.
4. Close password and root logins
Allow SSH keys only and stop direct root logins.
5. Turn on a firewall
Deny incoming traffic by default and allow SSH and the services you run.
6. Enable automatic security updates
Let the server install security fixes by itself.
7. Check the clock and the services
Keep time in sync and switch off services you do not use.
8. Back up and test a restore
Keep copies away from the server and prove that you can restore them.
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.
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.
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: timedatectl shows whether time synchronisation is active. List the services that listen on the network with sudo ss -tulpn and disable those you do not need. To slow down password guessing against services that still accept passwords, a tool such as Fail2ban can block addresses that fail repeatedly.
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. Take a snapshot before risky changes where your plan offers snapshots, schedule regular database dumps and file backups to another location, and restore one to a test system to check that it works.
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 $3.33/mo -
Linux VDS Hosting
Linux VDS Hosting is scalable and high-performance, utilizing virtual dedicated servers to cater to your Linux-based projects.
Starting from $23.76/mo -
Nested Dedicated Server Hosting
Nested Dedicated Servers provide dedicated server performance within a virtual environment, offering scalability and cost-efficiency.
Starting from $43.89/mo -
America Dedicated Server Hosting
With Dedicated Server Hosting, you have exclusive access to a physical server, providing high performance and customization options.
Starting from $90.00/mo
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, code signing and Apple's licence rules.
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.
Questions before you order?
Send us a message and our team will help you choose the right service.