What are we building?

By the end, your domain (YOUR_DOMAIN) points to your server IP via an A record (IPv4) and – if your server has IPv6 – an AAAA record, including www. You can verify this yourself with dig and understand why a change isn’t always visible immediately. Optionally you also set up reverse DNS (PTR) – important as soon as your server sends emails. This lays the foundation for all publicly reachable services.

Prerequisites

• A set-up server with a known public IP address
• A registered domain (at netcup, another registrar, or included in your hosting package)
• Access to the DNS management of your domain (at netcup: the customer account CCP)

Step by step

Step 1: Find the server IP

Connect via SSH and display the public IP addresses:

ip -4 addr show scope global
ip -6 addr show scope global

The IPv4 address is after inet (e.g. 203.0.113.10), any IPv6 address after inet6 (does not start with fe80::, that would only be link-local). Alternatively you’ll find both in the netcup Server Control Panel (SCP) in the server overview.

Step 2: Create A and AAAA records

Open the DNS management of your domain. There you enter resource records – the mapping of names to addresses. Create:

• @ stands for the domain itself (YOUR_DOMAIN), www for the subdomain www.YOUR_DOMAIN.
• A points to an IPv4 address, AAAA to an IPv6 address. The name “AAAA” comes from an IPv6 address being four times as long as an IPv4 address.
• For individual services you can later create specific subdomains (e.g. cloud, git) – following the same pattern.

Step 3: Understand TTL and propagation

Every record has a TTL (Time To Live) in seconds – e.g. 3600 (one hour). It tells resolvers worldwide how long they may cache the answer before asking again.

From this follows the notorious propagation: if you change a record, some resolvers see the new value immediately, others only after the old TTL expires. “DNS propagating” means nothing more than these caches expiring one by one. In everyday use, reckon with minutes up to an hour, occasionally longer.

Step 4: Verify with dig

Wait a few minutes, then check from your own machine where the domain points. dig is the standard tool for that:

dig +noall +answer YOUR_DOMAIN A

This is what a correct answer looks like (example for this site’s real domain):

serverkueche.de.	600	IN	A	46.38.243.234

The number 600 is the remaining TTL, followed by the target IP. For IPv6, do the same with AAAA. If you only want it very brief:

dig +short YOUR_DOMAIN

46.38.243.234

If your correct server IP appears, the domain is connected. Also check www:

dig +short www.YOUR_DOMAIN

Here too, the same server IP as for the apex should come back as a plain line:

46.38.243.234

Step 5: Set reverse DNS (PTR) – optional but recommended

The A record answers the question “Which IP belongs to this name?”. Reverse DNS – the PTR record – answers the opposite direction: “Which name belongs to this IP?”. For a plain website you don’t need this. But as soon as your server sends emails – even if only notifications from Nextcloud, Gitea & co. – it’s practically mandatory: the receiving mail servers reject mail from IPs without a matching PTR or treat it as spam.

The crucial difference from the previous records: you enter the PTR not at your DNS provider, but where the IP address is managed – i.e. at your VPS provider. At netcup you’ll find it in the Server Control Panel (SCP) in the Netzwerk (Network) tab – there’s a Reverse DNS field per address (IPv4 and IPv6). Enter a hostname there that points to the same server via an A record – either directly YOUR_DOMAIN or your own name like server.YOUR_DOMAIN (shown as an example in the screenshot) – and click Save.

If you have IPv6, set the PTR for both addresses – IPv4 and IPv6. The IPv6 PTR is easily forgotten, and that’s exactly what some mail servers trip over after all.

You can check the result with dig and the -x option (reverse lookup) – for IPv6 do the same with YOUR_SERVER_IPV6:

dig +short -x YOUR_SERVER_IPV4

Your hostname with a trailing dot should come back:

serverkueche.de.

If nothing comes back, or still the provider’s default name (at netcup something like v220….bestsrv.de), the PTR is not (correctly) set yet – or, as with every DNS entry, the change still needs some time.

When things go wrong

Maintenance & backups

• DNS is low-maintenance. Once set correctly, the A/AAAA record rarely changes. Exception: a server migration – then the TTL trick from step 3 applies.
• Document your records. Keep track somewhere of which names (@, www, cloud, …) point to which IP. With several services you otherwise lose the overview.
• No classic backup needed, but a screenshot or export of your DNS zone doesn’t hurt in case you switch providers.
• Carry reverse DNS along on an IP change. If the server gets a new IP (migration, new product), you have to reset the PTR at the VPS provider – it’s tied to the IP, not the domain.

Your domain now points to the server – with that, the last prerequisite is met for serving services publicly with automatic HTTPS via the reverse proxy Traefik.

What are we building?

You get to know the netcup Server Control Panel (SCP) – the web interface to your server – and create a snapshot there: a complete image of your server disk, to which you return in a few minutes if a mishap happens. By the end you know when a snapshot is your rescue – and why it’s still no substitute for a real backup.

Prerequisites

• A netcup server, e.g. your first VPS.
• Your SCP credentials – they are in the netcup welcome email and are different from your SSH login.

Step by step

Step 1: Log into the SCP and find the server

Open servercontrolpanel.de and log in with your SCP credentials. You land in the server list; a click on your server opens the overview with product, status and hardware. At the top you see the tabs through which you control everything – snapshots are under “Media”.

Step 2: Create a snapshot

Go to Media → Snapshots. Under Create snapshot you fill in:

• Name: name it after the why, not the date alone – e.g. before-update-2026-07. That way you later know what it was for.
• Description: one sentence of context (optional, but helpful).
• Disk: usually vda (your system disk).
• Type: here lies the most important decision – see below.

Offline or online snapshot?

• Offline snapshot: the server is briefly shut down for the capture. This guarantees a consistent state – the right choice when databases are running, and when you can afford the brief downtime.
• Online snapshot: capture while running, without downtime. Convenient, but with active writes (e.g. a database mid-write) the image can be inconsistent.

A click on Create starts the process; depending on the amount of data it takes a few minutes. It runs in the background – the creation date and type then appear in the list above once it’s done. Best schedule the brief downtime of an offline snapshot for a quiet time; after that your return point is set and you can tackle the planned change.

Step 3: Restore a snapshot

If something went wrong, you find the snapshot in the list under Snapshots; in the Actions column there’s Restore.

Step 4: The other safety lines in the SCP

The SCP has more than snapshots – good to know for an emergency:

• Display (VNC console): direct screen access to the server, even when SSH refuses – the safety line from the SSH tutorial.
• Rescue system: boots the server into an emergency Linux to repair a broken installation.
• Media → Images / DVD drive: install a different operating system.

When things go wrong

Maintenance & backups

• Snapshot ≠ backup – the most important point. A snapshot lives at netcup, under your account, in one slot and is meant as a momentary snapshot. If the account, the data center or your access fails, it’s gone too. It’s a quick safety net, not an off-site backup.
• Snapshot before every risky action. Before big updates, migrations or delicate config changes: snapshot first, then start. Afterwards you can calmly replace it with the next one.
• Snapshots age. A months-old snapshot brings you back to a long-outdated state – when in doubt, worse than no snapshot. Renew it specifically before every larger action; a fresh return point is worth more than an old one.
• For real safety you need both. Complement the snapshot with encrypted off-site backups – how that works is shown in the tutorial on backups with Restic. Rule of thumb: snapshot for the quick return, Restic for “my server is gone”.

What are we building?

In the netcup SCP we build a network firewall from composable policy templates: a base template (that every server needs), one for SSH, and one for web (HTTP/HTTPS). You assign these building blocks to your server as needed – a web server gets base + SSH + web, a server without a website only base + SSH. By the end, everything inbound is blocked except what you deliberately allow.

A netcup-specific detail makes the difference: for UDP the firewall works statelessly – which is why services like DNS and NTP need their own inbound rule, otherwise they suddenly get stuck. Why that is and how the base template solves it is shown in step 2.

Prerequisites

• A netcup server, e.g. your first VPS.
• Your SCP credentials (customer number + SCP password from the netcup welcome email – different from your SSH login).
• Clarity about your SSH port: the default is 22, and it stays that way when hardening SSH. If you changed it elsewhere, use your real port – otherwise you lock yourself out when activating.

Step by step

Step 1: Open Firewall Policies in the SCP

Log into the Server Control Panel and open the Firewall Policies menu item at the top. Here you create reusable rule sets (“policies”) – independent of the individual server. You only assign them later.

Step 2: Build the base template

Click Create firewall policy, give it the name Serverküche Base and, via Add rule, create these four rules – all INBOUND and ACCEPT:

Two things that make the difference here:

• DNS/NTP via the Src Port, not the destination port. Your server queries DNS/NTP (outbound); the reply comes back from port 53 or 123. Because UDP is stateless, you need this inbound rule – otherwise there’s no name resolution and no time synchronization, even though “everything else” seems to work.
• Never forget ICMPv6. Without Neighbor Discovery, IPv6 breaks completely. ICMP (v4) on top is useful for ping and path MTU discovery. netcup’s default policy “Ping allow” does already cover ICMP – it’s deliberately in the base template again so your foundation stays complete even if you ever remove the netcup defaults.

Step 3: Small building blocks for SSH and web

Instead of one big rule monolith, you create atomic templates that you freely combine. Create two more policies following the same pattern:

• Serverküche SSH – one rule: INBOUND, TCP, ACCEPT, destination port 22.
• Serverküche Web – two rules: INBOUND, TCP, ACCEPT, destination port 80 and 443.

The gain: the base rules appear only once, not duplicated in every policy. If a service is added later (e.g. a mail server or WireGuard), you build another small template for it and plug it in – without touching the existing ones.

Step 4: Assign templates to the server

Switch to Server → your server → “Firewall” tab and click Edit firewall policies. Move the appropriate ones from Available firewall policies to Selected: for a web server Serverküche Base + Serverküche SSH + Serverküche Web.

Confirm with Apply and then Save. Check that the “Firewall active” switch is turned on. The assigned rules now appear in the list – together with netcup’s default policies (more on those below).

Step 5: Ready-made templates for common services

Exactly following the pattern from step 3, here are ready-made templates for the most common self-hosting services. Each is its own small template, all rules are INBOUND and ACCEPT. Build only the ones you really need and plug them, as in step 4, into Serverküche Base + Serverküche SSH.

Mail server (mailcow & co.)

Two things that additionally belong to a mail server:

• Web UI and certificates: mailcow needs 80/443 for the web interface and the Let’s Encrypt retrieval – just assign the Serverküche Web template along with it.
• Enable outbound SMTP: a mail server must be able to deliver on port 25 outbound. netcup blocks that with the default policy “netcup Mail block” – you have to remove it on the server (see “When things go wrong”). And without a correct PTR/reverse-DNS entry your mails land in spam.

WireGuard VPN

51820 is the usual default – use the value from your ListenPort. Only this one inbound rule is needed; the replies to the clients go out outbound.

OpenVPN

The default is UDP 1194. The TCP rule only if you deliberately run OpenVPN over TCP (some additionally put it on TCP 443 to get through restrictive foreign networks) – otherwise leave it out.

Zabbix monitoring

Here it depends on the server’s role:

The Zabbix server additionally needs 80/443 for the web frontend (Serverküche Web). If you run active checks, the agent connects outbound to the server on 10051 – for that, no inbound rule is needed on the agent host.

Checkmk

In the default pull mode, the Checkmk server fetches the data actively – so it connects outbound to 6556 of the agents. Inbound, therefore, only the monitored host needs port 6556. The Checkmk server itself gets by with 80/443 (Serverküche Web); 8000 and 6557 only if you use push mode or distributed monitoring.

Coturn / TURN server (Nextcloud Talk, Matrix)

The large UDP relay range is the default – the actual audio/video streams run over it. You can narrow it in the coturn configuration (min-port/max-port) and then set the firewall rule to the same, smaller range.

Your own DNS server (AdGuard Home, Pi-hole, Unbound)

Careful, this is exactly the opposite direction to the base template: there Src 53 allows the replies to your own DNS queries; here Dst 53 allows the queries of foreign clients to your DNS server. Both exist side by side without problems.

Remote database access (emergency only)

When things go wrong

Maintenance & backups

• Test access after every change. Firewall rules are the classic way to lock yourself out. Keep a second session open, check a new connection, only then finish.
• New services = new template. If you later need another port (game server, WireGuard VPN over UDP, database), create a small template of your own and assign it additionally. The existing building blocks stay untouched.
• Mind the order. netcup evaluates the rules top to bottom; the first matching rule wins. For pure ACCEPT rules that doesn’t matter – but as soon as you use your own DROP rules, watch the order relative to the ACCEPTs.
• Know netcup’s default policies. “netcup Mail block” (outbound SMTP on ports 25/465/587 blocked) and “netcup Ping allow” are predefined. Via Restore default policies you can, in an emergency, get back to a known, working baseline if you locked yourself out with your own rules – together with the VNC console, your second safety net.

What are we building?

By the end you log in with an SSH key instead of a password, and neither root login nor password login is possible from outside. This makes the automated password-guessing attacks that hit every publicly reachable server around the clock run completely into the void. Tested with OpenSSH on Debian 13.

Prerequisites

• A set-up server with a sudo user
• Access to the VNC console in the netcup SCP as a safety line in case you lock yourself out

Step by step

Step 1: Generate an SSH key pair

If you don’t have a key yet, generate an Ed25519 key pair on your own machine (not on the server!):

ssh-keygen -t ed25519

You can accept the suggested storage location with Enter. Set a passphrase – it protects the key if your machine falls into the wrong hands. Two files are created: ~/.ssh/id_ed25519 (private, stays with you) and ~/.ssh/id_ed25519.pub (public, goes on the server).

Step 2: Transfer the public key

ssh-copy-id appends your public key to the ~/.ssh/authorized_keys file of your server user – with the correct file permissions:

ssh-copy-id koch@YOUR_SERVER_IP

Test right afterwards that key login works:

ssh koch@YOUR_SERVER_IP

You should now be logged in without a server password (only the passphrase of your key may be requested). Only once that works do we continue – in the next step we disable password login.

Step 3: Disable password login and root login

Open the SSH server configuration:

sudo nano /etc/ssh/sshd_config

Set (or uncomment) these two lines:

PermitRootLogin no
PasswordAuthentication no

PermitRootLogin no blocks direct root login completely, PasswordAuthentication no allows only key logins.

Step 4: Test the configuration and restart SSH

Check the configuration for syntax errors before you restart – a typo would otherwise take the SSH service down:

sudo sshd -t

No output means: all good. Then apply it:

sudo systemctl restart ssh

To verify: sudo systemctl status ssh should show active (running), and a login attempt as root must now be rejected with Permission denied (publickey).

When things go wrong

Maintenance & backups

• Back up the private key: Without ~/.ssh/id_ed25519 you can only reach the server via the VNC console. Back up the key encrypted (e.g. in a password manager) or add a second key from another device to authorized_keys.
• Keep an eye on logins: sudo journalctl -u ssh --since today shows you all login attempts. Failed attempts on port 22 are normal and, thanks to the key requirement, harmless – you can automatically ban such bots later with Fail2ban.
• Updates: OpenSSH gets its security updates through the normal apt upgrade – so keep the server up to date, ideally automated.

What are we building?

By the end of this tutorial, your VPS runs a current Debian 13 with all security updates, and you work with your own user with sudo rights instead of permanently as root. That’s the foundation for all the other recipes in the Serverküche – from hardening SSH to your first application.

Prerequisites

• An ordered netcup server with the credentials from your customer account
• A terminal on your machine (Linux/macOS) or an SSH client like PuTTY (Windows)

Not sure which server size you even need? The server calculator estimates the RAM and CPU you’ll need for your planned services and suggests a matching netcup plan.

Step by step

Step 1: Log in via SSH

Log in with your server’s IP address as root. You’ll find the IP and the password in the credentials from your customer account:

ssh root@YOUR_SERVER_IP

On the very first login, SSH asks whether you want to trust the server:

The authenticity of host 'YOUR_SERVER_IP' can't be established.
...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Answer yes – your machine remembers the server from now on. After that you land on a prompt like root@v12345:~#.

Step 2: Update the system

Freshly delivered images are rarely up to date. So the first thing to do is fetch all updates – security updates in particular should never wait:

apt update && apt upgrade -y

apt update fetches the current package lists, apt upgrade -y installs all available updates without prompting.

Step 3: Create a sudo user

Don’t work as root permanently: a typo with full rights can wreck the entire system, and having your own user is the prerequisite for disabling root login completely later. Create a user – we’ll call it koch (“cook”) here, but you can pick any name:

adduser koch

You’ll be asked for a password and a few optional details (you can skip the details with Enter). After that, give the user sudo rights:

usermod -aG sudo koch

Step 4: Test the new user

Check in a new terminal session (keep the root session open!) that login and sudo work:

ssh koch@YOUR_SERVER_IP
sudo whoami

After entering your password, sudo whoami should return root. From now on you continue working with this user.

When things go wrong

Maintenance & backups

• Updates: You should schedule sudo apt update && sudo apt upgrade at least weekly – or automate security updates with unattended-upgrades.
• Snapshots: Create a snapshot in the netcup Server Control Panel (SCP) before bigger changes. It’s your safety line while you don’t have a proper backup strategy yet – but a snapshot does not replace a backup outside the server.
• Credentials: Keep the root password safe (password manager). Via the VNC console in the SCP you can still reach the server even when SSH is stuck.

You’ll find both in the server overview of the SCP: the VNC console is under the “Bildschirm” (Display) tab, and the remaining snapshot quota is shown in the status block.