Skip to content
Guide

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.

At a glance

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.

Checklist

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-upgrade

On 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 alex

On 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.

Reference

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.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Check 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 enable

On 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.

  1. Snapshot before risky changes

    Take a snapshot before upgrades and other risky changes, where your plan offers snapshots.

  2. Schedule regular backups

    Schedule database dumps and file backups to a location away from the server.

  3. Restore to a test system

    Restore a backup to a test system to check that it works, and repeat the test regularly.

Avoid these

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/lu
  • 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/lu
  • Nested Dedicated Server Hosting

    Nested Dedicated Servers provide dedicated server performance within a virtual environment, offering scalability and cost-efficiency.

    Starting from $55.00/lu
  • 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/lu

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 more

Choosing a macOS server for iOS CI

Xcode and macOS versions, Apple silicon, sizing, the CI runner and code signing.

Learn more

Move a website without downtime

A step-by-step plan for files, databases, DNS, SSL and email.

Learn more

DNS basics for a new domain

Nameservers, records, TTL and the email records every domain needs.

Learn more

Choose a data center location

How distance becomes latency, how to measure it and what data rules mean for location.

Learn more
FAQ

Frequently asked questions

Still have a question? Send us a message and our team will reply by email.
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.

Generare Parolă

Please confirm