---
title: "How to Secure Your Linux VPS (2026 Guide)"
description: "Secure your Winheberg Linux VPS, system updates, SSH key authentication, firewall, and CrowdSec, whatever your distribution."
category: vps
subcategory: vps-linux
icon: tabler:file-text
date: 2026-07-24
author: Winheberg
slug: "secure-linux-vps-2026"
order: 2
image: /statics/images/docs/en/vps-linux/secure-linux-vps-2026.webp
tags: [vps, security, ssh, crowdsec, firewall]
keywords: [secure linux vps, ed25519 ssh key, ufw firewalld iptables, crowdsec vps, vps security guide 2026]
link_fr: "/docs/vps-linux/securiser-vps-linux-2026"
---

## Context

You just rented a **Linux VPS** at Winheberg and want to secure it properly? Good news, a few simple steps are enough to block the vast majority of automated attacks targeting servers exposed on the Internet.

This step-by-step guide is designed for beginners. Every command is explained, and you'll understand why each step matters. It covers every distribution we offer, namely Debian 11/12/13, Ubuntu 23.10/24.04/25.04, AlmaLinux 9/10, Rocky Linux 9/10, Fedora 41/42, and Alpine Linux 3.22.

## Why secure your Linux VPS?

As soon as a VPS goes online, it becomes a target. Thousands of bots constantly scan the Internet looking for misconfigured servers. Within just a few hours, your server can face several types of attacks.

- **SSH brute-force attempts**, where bots try thousands of passwords
- **Port scans** to detect vulnerable services
- **Exploits of vulnerabilities** in outdated software

A compromised VPS can be used to send spam, mine cryptocurrency, or take part in DDoS attacks, often without you even noticing.

> [!IMPORTANT]
> Follow this guide as soon as you first connect to your VPS, before even installing your services on it.

## Prerequisites

- An active **Linux VPS** at Winheberg
- Root SSH access to your server
- A local PC to generate an SSH key pair

## 1. Update the system

The very first step is to update all installed packages. This fixes known security vulnerabilities and gives you the latest stable versions of your software.

### Connect to your VPS via SSH

```bash
ssh root@YOUR_VPS_IP
```

> [!NOTE]
> Your server's IP address was sent to you in the delivery email when you ordered, or is available in the IP Address section of your client area. Replace `YOUR_VPS_IP` with that address (for example `ssh root@82.153.202.xx`).

### Run the update

:::MdTabs
::MdTab{label="Debian and Ubuntu"}
```bash
apt update && apt dist-upgrade -y
```

> [!TIP]
> Why `dist-upgrade` and not `upgrade`? The `apt upgrade` command can hold back certain critical updates (particularly Linux kernel updates or packages with new dependencies). `apt dist-upgrade` (or its equivalent `apt full-upgrade`) is more thorough and applies every security update without exception. It's the recommended command for a server.
::
::MdTab{label="AlmaLinux, Rocky Linux, and Fedora"}
```bash
dnf upgrade --refresh -y
```

The `--refresh` option forces a refresh of repository metadata before applying updates, to make sure nothing is missed.
::
::MdTab{label="Alpine Linux"}
```bash
apk update && apk upgrade
```
::
:::

> [!TIP]
> Get into the habit of running this command every week to keep your VPS up to date.

## 2. Secure SSH access

SSH is your VPS's main entry point. It's also the number one target for attacks. Here are the best practices to apply.

### ❌ Why changing the SSH port is pointless

Many tutorials recommend changing the default SSH port (22) to another port (for example 2222). That's a false good idea.

This is security through obscurity, you're hiding the service instead of actually protecting it. A modern scanner like `nmap` or `masscan` will find your new port within seconds. In the end, this change mostly complicates your administration (you need to specify the port on every connection), breaks certain tools that assume port 22 by default, and gives you a false sense of security.

Keep port 22 and apply the real protections below instead.

### 2.1 Set up SSH key authentication

Key-based authentication is much safer than a password. A private key is nearly impossible to guess through brute force, unlike a password, which can be attacked for days on end.

> [!NOTE]
> "Nearly impossible" with today's computers. With the rise of quantum computing, some classical cryptographic algorithms (like RSA) may become vulnerable in the future. That's why **Ed25519** keys (used in this guide) are recommended today, more robust and already better prepared for the post-quantum era.

This step is identical regardless of your VPS's distribution, since it mostly happens on your local PC.

**On your local PC** (not on the VPS), generate a key pair.

```bash
ssh-keygen -t ed25519 -C "your_email@example.com"
```

Press Enter to accept the default location, then set a passphrase (a password protecting the key).

Then copy the public key to your VPS.

```bash
ssh-copy-id root@YOUR_VPS_IP
```

Test the connection.

```bash
ssh root@YOUR_VPS_IP
```

If you connect without being asked for a password (just the key's passphrase), everything works.

### 2.2 Disable password login

Now that key-based login works, disable password login to permanently block brute-force attacks.

Open the SSH configuration file, identical across every distribution.

```bash
nano /etc/ssh/sshd_config
```

Edit (or add) the following lines.

```
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
```

The `PermitRootLogin prohibit-password` option allows root only via SSH key, never via password. `PasswordAuthentication no` completely disables password authentication, and `PubkeyAuthentication yes` allows key-based login.

Save (`Ctrl+O`, Enter, `Ctrl+X`), then restart the SSH service. The service name differs depending on the distribution.

:::MdTabs
::MdTab{label="Debian and Ubuntu"}
```bash
systemctl restart ssh
```
::
::MdTab{label="AlmaLinux, Rocky Linux, and Fedora"}
```bash
systemctl restart sshd
```
::
::MdTab{label="Alpine Linux"}
```bash
rc-service sshd restart
```
::
:::

> [!WARNING]
> Don't close your current session before testing the new configuration in another terminal. If something's wrong, you could end up locked out of the server.

## 3. Install a firewall

Which firewall to use depends on your distribution.

:::MdTabs
::MdTab{label="UFW (Debian, Ubuntu)"}
UFW (*Uncomplicated Firewall*) is an easy-to-use firewall that lets you only allow the necessary ports on your server.

### Install UFW

```bash
apt install ufw -y
```

### Allow SSH (critical step)

**Before any other UFW command**, allow SSH. If you skip this step and enable the firewall, you'll be immediately disconnected from your VPS with no way back in.

```bash
ufw allow OpenSSH
```

### Set the base rules

Now that SSH is allowed, you can block all incoming traffic by default and allow outgoing traffic.

```bash
ufw default deny incoming
ufw default allow outgoing
```

The `default deny incoming` rule blocks everything coming in, except the exceptions you've defined (like SSH). The `default allow outgoing` rule lets your server keep communicating outward (updates, web requests, etc.).

### Allow other services (if needed)

If you're hosting a website, open the HTTP and HTTPS ports.

```bash
ufw allow 80/tcp
ufw allow 443/tcp
```

### Enable the firewall

```bash
ufw enable
```

Then check that everything is in order.

```bash
ufw status verbose
```

You should see your rules listed with `active` status.
::
::MdTab{label="firewalld (AlmaLinux, Rocky, Fedora)"}
firewalld is the default firewall in the Red Hat ecosystem. Unlike UFW, its default zone already blocks any incoming traffic not explicitly allowed, so there's no separate "deny incoming" rule to add.

### Check that firewalld is active

```bash
systemctl status firewalld
```

On AlmaLinux, Rocky, and Fedora, firewalld is usually active by default. If it isn't, start it and enable it at boot.

```bash
systemctl enable --now firewalld
```

### Allow SSH (critical step)

**Before anything else**, make sure SSH is allowed. It is by default on the `public` zone, but check anyway.

```bash
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload
```

### Allow other services (if needed)

If you're hosting a website, open the HTTP and HTTPS ports.

```bash
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
```

### Check active rules

```bash
firewall-cmd --list-all
```

You should see the allowed services listed in the active zone.
::
::MdTab{label="iptables (Alpine)"}
Alpine doesn't include UFW or firewalld, so firewall protection goes through `iptables`.

### Install iptables

```bash
apk add iptables
```

### Allow loopback, established connections, and SSH (critical step)

**Before applying a default block policy**, explicitly allow SSH, or you'll end up locked out of the server.

```bash
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
```

### Allow other services (if needed)

If you're hosting a website, open the HTTP and HTTPS ports.

```bash
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
```

### Block the rest of the incoming traffic by default

```bash
iptables -P INPUT DROP
```

### Make the rules persistent

By default, iptables rules are lost on reboot.

```bash
/etc/init.d/iptables save
rc-update add iptables
```

### Check active rules

```bash
iptables -L INPUT -n -v --line-numbers
```
::
:::

## 4. Install CrowdSec to block attacks

[CrowdSec](https://www.crowdsec.net/) is a modern alternative to Fail2Ban. It analyzes logs in real time to detect malicious behavior (brute-force attempts, scans, etc.) and automatically blocks suspicious IPs.

Its distinctive feature is that CrowdSec shares malicious IPs with a worldwide community, which lets it block attackers before they even attack your server.

> [!NOTE]
> On Alpine, CrowdSec doesn't have the same level of support as on other distributions. The automatic install wizard doesn't work (it assumes systemd, which Alpine doesn't have with OpenRC), and the packages are only available in the `edge/testing` repository, not in the stable repos. A manual install is possible but is beyond the scope of this guide. On Alpine, the iptables firewall set up in the previous step remains your main protection.

:::MdTabs
::MdTab{label="Debian and Ubuntu"}
### Install CrowdSec

```bash
curl -s https://install.crowdsec.net | sh
apt install crowdsec -y
```

The installer automatically detects the services to monitor (including SSH) and configures the necessary collections.

### Check the installation

```bash
systemctl status crowdsec
```

You should see `active (running)` in green.

To see the active detection scenarios, run the following command.

```bash
cscli collections list
```

### Install the bouncer

CrowdSec detects threats, but it needs a bouncer to actively block them.

```bash
apt install crowdsec-firewall-bouncer-iptables -y
```

The bouncer registers itself automatically with CrowdSec. Then check that it's active.

```bash
systemctl status crowdsec-firewall-bouncer
```
::
::MdTab{label="AlmaLinux, Rocky Linux, and Fedora"}
### Install CrowdSec

```bash
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | bash
dnf install crowdsec -y
```

> [!NOTE]
> If the repository installation fails asking for `pygpgme`, this package is no longer packaged on recent versions of AlmaLinux and Rocky. Check the official CrowdSec documentation for the manual repository install method for your exact version.

### Check the installation

```bash
systemctl status crowdsec
```

You should see `active (running)` in green.

To see the active detection scenarios, run the following command.

```bash
cscli collections list
```

### Install the bouncer

```bash
dnf install crowdsec-firewall-bouncer-iptables -y
systemctl enable --now crowdsec-firewall-bouncer
```

Then check that it's active.

```bash
systemctl status crowdsec-firewall-bouncer
```
::
:::

### Test and monitor CrowdSec

To list current decisions (blocked IPs), use this command.

```bash
cscli decisions list
```

To check alerts (detected attempts), run this one.

```bash
cscli alerts list
```

> [!TIP]
> Create a free account at [app.crowdsec.net](https://app.crowdsec.net) to view your alerts in a web dashboard and benefit from the community blocklist, which preemptively blocks IPs flagged as malicious by other users.

## Summary of good habits

After following this guide, your VPS is protected against most common attacks. To maintain this level of security over time, keep these habits in mind.

- Update the system regularly
- Only use SSH key authentication
- Keep your firewall enabled and only open the ports you actually need
- Check the CrowdSec logs from time to time (`cscli alerts list`), on distributions where it's installed

## Need help?

If you run into an issue while securing your VPS, our team is here. Open a ticket in the **Technical** department from your client area and fill in the **Related Product** field with the VPS in question.

You now have a secure Linux VPS, ready to host your projects with peace of mind 🔒