How to secure a new Linux server in the first hour

A new server is reachable from the internet the moment it boots, and automated scanners find it within minutes. These eight steps close the most common gaps before you install anything else. Commands are for Ubuntu and Debian, with notes for AlmaLinux, Rocky Linux and other RHEL-family systems. Replace alex with your user name and 203.0.113.10 with your server's address.

Before you start

• Log in as root with the details from the welcome email; see connect to your Linux server with SSH.
• Keep a second way in at hand, such as the web console if your service page shows one, in case an SSH or firewall change goes wrong.
• Work through the steps in order. Each one ends with a check.

Step 1: Update the system

Start with a fully patched system:

apt update
apt full-upgrade

On RHEL-family systems run dnf upgrade. Reboot if the kernel was updated (reboot), then log in again.

Verify: running the upgrade again reports nothing left to install.

Step 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: useradd -m alex, passwd alex and usermod -aG wheel alex.

Verify: in a second terminal, ssh [email protected], then sudo whoami prints root.

Step 3: Log in with an SSH key

On your own computer, create a key and copy it to the new user:

ssh-keygen -t ed25519
ssh-copy-id alex@203.0.113.10

On Windows, see SSH keys for the PowerShell alternative to ssh-copy-id.

Verify: ssh [email protected] logs you in with the key (it asks for the key's passphrase, not the account password).

Step 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 wins:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Check the syntax, show the settings that are really in effect, then restart SSH:

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
sudo systemctl restart ssh

On RHEL-family systems restart sshd. Keep your current session open and test a new login in a second terminal.

Verify: ssh [email protected] is refused, and ssh [email protected] still works.

Step 5: Turn on a firewall

Allow SSH first, then switch the firewall on, so you do not cut your own connection. UFW is installed on Ubuntu; 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

Open only the ports of services you actually run; leave out 80,443/tcp if there is no web server yet. On RHEL-family systems firewalld is the usual tool and SSH is allowed in its default zone: add a service with sudo firewall-cmd --permanent --add-service=https and apply it with sudo firewall-cmd --reload.

Verify: sudo ufw status verbose lists your rules, and a new SSH login still works. More options: UFW firewall.

Step 6: Turn on automatic security updates

Ubuntu installs unattended-upgrades by default and applies security updates automatically. On Debian, install it first. On both, confirm it is enabled:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

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. Details: automatic updates.

Verify: sudo unattended-upgrade --dry-run --debug runs without errors.

Step 7: Check the time and what is listening

Logs, certificates and two-factor codes depend on a correct clock, and every listening service is a door:

timedatectl
sudo ss -tulpn

timedatectl should report System clock synchronized: yes. ss -tulpn lists every listening service; stop and disable the ones you do not need with sudo systemctl disable --now and the service name. For services that must accept passwords, consider Fail2ban or CrowdSec.

Step 8: Back up, and test a restore

A backup is proven only once you have restored it. Follow the 3-2-1 idea: three copies of your data, on two kinds of storage, one of them away from the server. Take a snapshot before risky changes where your plan offers snapshots, schedule database and file backups to another location, and restore one to a test system regularly. See backup strategy.

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 every server on 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 IP address.
• Untested backups. A backup that cannot be restored does not protect you.

Troubleshooting

Permission denied (publickey) after Step 4. The key is not in the user's ~/.ssh/authorized_keys, or the permissions are wrong. Use your still-open session to fix it; see SSH connection problems.

The SSH session froze after ufw enable. SSH was not allowed. Use the console and follow locked out after a firewall change.

sudo: alex is not in the sudoers file. The user is not in the sudo (or wheel) group. As root, run usermod -aG sudo alex and log in again.

Next steps

• Go further with SSH: SSH hardening.
• Block repeated login attempts: Fail2ban and CrowdSec.
• Point your domain to the server: point a domain to your server.