# How to secure a new Linux server in the first hour

> First-hour checklist for a new Linux VPS or dedicated server: updates, a sudo user, SSH keys, no root or password logins, a firewall, updates and backups.

Difficulty: Beginner\
Tested on: Ubuntu 24.04 LTS, Ubuntu 26.04 LTS, Debian 12, Debian 13, AlmaLinux 10, Rocky Linux 10

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](/guides/connect-to-linux-server-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.

| Task | Ubuntu and Debian | RHEL family |
|---|---|---|
| Install updates | `apt update` and `apt full-upgrade` | `dnf upgrade` |
| Administrator group | `sudo` | `wheel` |
| Restart SSH | `systemctl restart ssh` | `systemctl restart sshd` |
| Firewall | UFW | firewalld |
| Automatic security updates | unattended-upgrades | dnf-automatic |

## Step 1: Update the system

Start with a fully patched system:

```bash
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:

```bash
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 alex@203.0.113.10`, 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:

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

On Windows, see [SSH keys](/guides/ssh-keys) for the PowerShell alternative to `ssh-copy-id`.

**Verify:** `ssh alex@203.0.113.10` 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:

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

```text
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
```

> **Note**
>
> **Exception for Coolify:** servers managed by Coolify need `PermitRootLogin prohibit-password` instead of `no`, because Coolify connects as root with its own SSH key. Keep `PasswordAuthentication no`, so root can log in with a key only, never with a password. See [install Coolify](/guides/install-coolify).

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

```bash
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 root@203.0.113.10` is refused, and `ssh alex@203.0.113.10` 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`.

```bash
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](/guides/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:

```bash
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](/guides/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:

```bash
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](/guides/fail2ban-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](/guides/backup-strategy-3-2-1).

## 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](/guides/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](/guides/locked-out-after-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](/guides/ssh-hardening).
- Block repeated login attempts: [Fail2ban and CrowdSec](/guides/fail2ban-crowdsec).
- Point your domain to the server: [point a domain to your server](/guides/point-domain-to-server).

## Frequently 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.

### What if I lose my SSH key?

Log in through the web console if your service page shows one, or open a support ticket. Then add a new public key and remove the lost one from 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.

### 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; watch instead for successful logins you do not recognise.

### 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. Take a snapshot or backup before larger upgrades.

---

Source: <https://hyperdc.com/guides/security/secure-a-new-linux-server>\
Updated: 2026-10-09