In diesem letzten Teil der Serie geht es um genau diese Dinge. Und um einen Mailserver, den es nicht mehr gab, an den mein DNS aber weiterhin brav alle E-Mails geschickt hat.

Voraussetzungen

• Ein eigener Mailserver – bei mir mailcow, eine Open-Source-Mailserver-Suite auf Docker-Basis, die schon länger für eine andere Domain läuft
• Zugriff auf das DNS der Domain (bei mir Cloudflare)
• Das Hugo-Projekt aus Teil 3

Beispielwerte: example.com ist die Blog-Domain, mail.example.net mein mailcow-Server und ich@example.net mein persönliches Postfach.

Teil A: Eine Kontaktadresse, die wirklich ankommt

Die Entscheidung

Für die Kontaktadresse gab es drei Möglichkeiten: meine normale Adresse, eine Weiterleitung auf meiner anderen Domain oder eine Adresse auf der Blog-Domain selbst. Ich habe mich für die dritte entschieden: kontakt@example.com. Sie passt zur Seite, verrät nichts über meine anderen Domains, und ich kann sie jederzeit umleiten, ohne das Impressum zu ändern.

Ein eigenes Postfach braucht es dafür nicht. Ein Alias (eine Weiterleitungsadresse) auf mein bestehendes Postfach genügt.

Die Domain in mailcow anlegen

In mailcow: E-Mail → Konfiguration → Domains → Domain hinzufügen. Beschreibung, Limits – für einen Alias spielen die Standardwerte keine Rolle. Neuere mailcow-Versionen erzeugen dabei gleich den DKIM-Schlüssel mit (Selektor dkim, 2048 Bit). Die Relay-Optionen bleiben leer.

Danach zeigt mailcow bei jeder Domain über den Button „DNS“ eine Übersicht: welche DNS-Einträge es erwartet und was im DNS tatsächlich steht.

Gescheitert, aber rechtzeitig gemerkt: der Geister-Mailserver

Diese Übersicht hat mich kurz stutzen lassen. Die Spalte „Current State“ war nämlich nicht leer:

Für meine Blog-Domain gab es also schon Mail-Einträge – und die zeigten auf einen alten Mailserver, den es nicht mehr gab. Das heißt: Jede E-Mail an eine Adresse dieser Domain lief ins Leere.

Wäre der alte Server noch in Betrieb gewesen, hätte ich jetzt sehr vorsichtig sein müssen: erst alle Adressen in mailcow anlegen, alte Mails übernehmen (mailcow kann das per Sync-Job direkt vom alten Server), dann erst umstellen. So konnte ich direkt aufräumen.

Learning: Vor jeder DNS-Änderung erst nachsehen, was jetzt drinsteht. Die DNS-Übersicht von mailcow ist dafür ideal, dig tut es auch:

dig +short MX example.com @1.1.1.1
dig +short TXT example.com @1.1.1.1

Aufräumen bei Cloudflare

In der Cloudflare-Übersicht fanden sich noch mehr Reste. Hier die Liste, Zeile für Zeile:

Gelöscht: die A- und AAAA-Einträge für mail – sie zeigten auf den alten Server.

Geändert:

Neu angelegt:

Alle Einträge stehen auf DNS only, also ohne Cloudflare-Proxy. Zwei weitere Altlasten eines früheren Domain-Anbieters (ein Eintrag für dessen Konfigurationsdienst und eine alte Domain-Verifizierung) habe ich stehen lassen – sie stören nicht.

SPF, DKIM und DMARC in drei Sätzen

Diese drei Einträge sorgen dafür, dass niemand so leicht E-Mails im Namen meiner Domain fälschen kann:

• SPF (Sender Policy Framework) legt fest, welche Server Mails für die Domain verschicken dürfen. v=spf1 mx -all heißt: nur der Server aus dem MX-Eintrag, alle anderen werden abgelehnt. Für www und alle anderen Subdomains (*) steht v=spf1 -all – von dort kommt nie eine Mail, also darf auch niemand so tun.
• DKIM (DomainKeys Identified Mail) signiert jede ausgehende Mail. Den öffentlichen Schlüssel zum Prüfen veröffentlicht der dkim._domainkey-Eintrag.
• DMARC sagt anderen Mailservern, was sie tun sollen, wenn SPF oder DKIM nicht passen. p=quarantine heißt: in den Spam damit. adkim=s und aspf=s verlangen eine exakte Übereinstimmung der Domain. Weil meine Domain ausschließlich über mailcow mit DKIM verschickt, kann ich von Anfang an streng sein.

Ein Tipp zum DKIM-Schlüssel: nicht aus einem Screenshot abtippen. Der Schlüssel ist eine lange Zeichenkette, in der l und I fröhlich durcheinandergehen. In mailcow steht er unter Konfiguration → ARC/DKIM-Schlüssel als markierbarer Text.

Nach ein paar Minuten zeigte die DNS-Übersicht von mailcow überall grüne Haken – auch beim DKIM-Schlüssel. Damit ist auch geprüft, dass er exakt stimmt.

Der Alias

In mailcow: E-Mail → Konfiguration → Aliasse → Alias hinzufügen:

• Alias-Adresse: kontakt@example.com
• Ziel: ich@example.net
• „Allow to send as this alias“ ✓ – damit kann ich auch als kontakt@ antworten, sauber mit DKIM signiert
• „Internal“ leer lassen – sonst könnte mir von außen niemand schreiben

Dazu habe ich gleich noch postmaster@example.com auf dasselbe Ziel angelegt. Eine postmaster-Adresse sollte jede Maildomain haben, dorthin schreiben andere Mailserver bei Problemen.

Der Test: eine Mail von einem fremden Anbieter an kontakt@example.com – nach wenigen Sekunden war sie in meinem Postfach.

Teil B: Impressum

Brauche ich das als privater Blog?

Kurz: ja. Ich bin kein Anwalt, aber die Lage ist ziemlich klar. Ein Blog, der für die Öffentlichkeit gedacht ist, braucht nach § 18 Abs. 1 Medienstaatsvertrag (MStV) mindestens Name und Anschrift. Sobald er „geschäftsmäßig“ betrieben wird – und dafür reichen schon Werbebanner oder Affiliate-Links –, gelten zusätzlich die Pflichten aus § 5 Digitale-Dienste-Gesetz (DDG), dem Nachfolger des alten Telemediengesetzes. Dann braucht es unter anderem einen schnellen elektronischen Kontaktweg und einen zweiten Weg zur Kontaktaufnahme.

Die Anschrift muss ladungsfähig sein, also eine Adresse, an die Behörden Schriftstücke zustellen können. Ein Postfach reicht dafür nicht.

Meine Entscheidungen

• Adresse: Ich habe meine Privatanschrift genommen. Die Alternative wäre ein Impressum-Service, der eine eigene Adresse stellt. Das schützt die Wohnadresse, ist rechtlich aber nicht ganz unumstritten. Für mich war die sichere Variante wichtiger.
• Aufbau: Werbung gibt es hier nicht, Affiliate-Links schließe ich für später aber nicht aus. Deshalb ist das Impressum gleich so aufgebaut, dass es auch nach § 5 DDG passt. Eine Telefonnummer als zweiter Kontaktweg kommt dazu, falls es so weit ist.
• Kontakt: die neue Adresse kontakt@example.com.

In Hugo ist das Impressum einfach eine Markdown-Seite, content/impressum.md:

---
title: "Impressum"
url: "/impressum/"
ShowReadingTime: false
ShowToc: false
ShowBreadCrumbs: false
ShowPostNavLinks: false
---

## Angaben gemäß § 5 DDG und § 18 Abs. 1 MStV

Vorname Nachname\
Straße Hausnummer\
PLZ Ort\
Deutschland

## Kontakt

E-Mail: kontakt@example.com

## Verantwortlich für den Inhalt nach § 18 Abs. 2 MStV

Vorname Nachname, Anschrift wie oben

Der Backslash am Zeilenende erzwingt in Markdown einen Zeilenumbruch, ohne dass ein neuer Absatz entsteht – praktisch für Adressen. Dazu kommt bei mir noch ein kurzer Absatz zur Haftung für externe Links.

Teil C: Eine Datenschutzerklärung, die stimmt

Erst die Technik, dann der Text

Mein Grundsatz für die Datenschutzerklärung: Es steht nur drin, was technisch auch so ist. Klingt selbstverständlich, ist es aber nicht – viele Vorlagen versprechen Dinge, die der eigene Server gar nicht tut. Oder sie verschweigen Dinge, die er sehr wohl tut.

Bei mir ist die Lage dank der Entscheidungen aus den vorherigen Teilen übersichtlich:

• Keine Cookies, kein Tracking, keine externen Inhalte. Das erzwingt die Content-Security-Policy aus Teil 2 sogar technisch.
• Keine Zugriffsprotokolle – Caddy schreibt sie standardmäßig nicht.
• Kein Cloudflare-Proxy – Cloudflare beantwortet nur DNS-Anfragen.

Ein Punkt war aber offen: Auch ohne Zugriffsprotokolle schreibt das System Logs, in denen IP-Adressen stehen können – Fehlermeldungen des Webservers, abgewiesene Verbindungen an der Firewall, SSH-Anmeldeversuche. Wie lange werden die aufbewahrt? Bei Debian standardmäßig, bis das Journal eine bestimmte Größe erreicht. Das ist keine Frist, die man in eine Datenschutzerklärung schreiben kann.

Also habe ich eine festgelegt:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/10-retention.conf > /dev/null <<'EOF'
[Journal]
MaxRetentionSec=14day
EOF
sudo systemctl restart systemd-journald

Und geprüft, dass es keine klassischen Logdateien daneben gibt, für die das nicht gelten würde:

ls -la /var/log/syslog /var/log/auth.log /var/log/ufw.log 2>&1
dpkg -l rsyslog 2>/dev/null | grep ^ii

Bei Debian 13 gibt es standardmäßig kein rsyslog mehr – alles landet im Journal, und die 14 Tage gelten für alles. Jetzt kann in der Datenschutzerklärung stehen: „wird nach 14 Tagen automatisch gelöscht“. Und es stimmt.

Was drinsteht

Meine Datenschutzerklärung (content/datenschutz.md) ist in der Du-Form geschrieben, passend zum Rest des Blogs, und gliedert sich so:

1. Verantwortlicher – Name, Anschrift, Kontaktadresse
2. Hosting – der VPS-Anbieter mit Anschrift, Rechenzentrum in Deutschland, Vertrag zur Auftragsverarbeitung
3. Aufruf der Website – welche Daten der Browser technisch überträgt, keine Zugriffsprotokolle, Systemprotokolle mit 14 Tagen Aufbewahrung, Rechtsgrundlage Art. 6 Abs. 1 lit. f DSGVO
4. Verschlüsselung – TLS
5. Speicherung im Browser – PaperMod merkt sich die Wahl zwischen hellem und dunklem Design im Local Storage des Browsers (Eintrag pref-theme). Der Wert bleibt auf dem Gerät. Weil er für eine ausdrücklich gewünschte Funktion nötig ist, braucht es keine Einwilligung (§ 25 Abs. 2 Nr. 2 TDDDG).
6. Kontakt per E-Mail – was mit Mails passiert und wo der Mailserver steht
7. Deine Rechte – Auskunft, Berichtigung, Löschung usw. und die zuständige Datenschutz-Aufsichtsbehörde
8. Stand

Ein Satz am Anfang fasst das Wichtigste zusammen: keine Cookies, kein Tracking, keine Inhalte von Drittanbietern. Wer nur den liest, weiß schon fast alles.

Wichtig: Kommt später etwas dazu – Affiliate-Links, ein Fediverse-Server, ein Kommentarsystem –, muss die Datenschutzerklärung mitwachsen.

Ins Menü

Beide Seiten müssen von überall leicht erreichbar sein. Bei PaperMod kommen sie einfach ins Hauptmenü, in die hugo.toml:

[[menu.main]]
  identifier = "impressum"
  name = "Impressum"
  url = "/impressum/"
  weight = 90
[[menu.main]]
  identifier = "datenschutz"
  name = "Datenschutz"
  url = "/datenschutz/"
  weight = 91

Teil D: Ein Favicon – das K mit dem Funken

Zum Schluss das Kleinste, aber Sichtbarste: das Symbol im Browser-Tab. Die Konsole hatte sich schon länger beschwert:

GET https://example.com/favicon.ico 404 (Not Found)
GET https://example.com/favicon-32x32.png 404 (Not Found)
GET https://example.com/favicon-16x16.png 404 (Not Found)

Drei Entwürfe

Für das Favicon gab es drei Entwürfe, alle in den Farben der Seite – dunkler Grund, helles Kabel, ein Funke in Bernstein:

• A: ein waagerechtes Kabel mit Bruchstelle, blankem Kupfer an den Enden und einem Funken dazwischen
• B: dieselbe Idee, diagonal
• C: ein „K“, dessen Bein gebrochen ist, mit dem Funken in der Lücke

A und B erzählen die Geschichte des Namens schöner. Aber ein Favicon wird in 16 × 16 Pixeln angezeigt, und da bleibt von einem Kabel mit Bruchstelle nur ein Strich mit einem orangen Fleck. Das K blieb selbst in dieser Größe eindeutig lesbar. Also wurde es C. Der wichtigste Test bei Favicons ist deshalb: die kleinste Größe ansehen, nicht die größte.

Die Dateien

PaperMod verlinkt im <head> standardmäßig diese Dateien, die einfach in den Ordner static/ kommen:

Als Grundlage dient eine einzige SVG-Datei. Daraus lassen sich alle Größen mit zwei Python-Bibliotheken erzeugen – CairoSVG zum Rendern und Pillow für die ICO-Datei:

import io, cairosvg
from PIL import Image

def render(svg, size):
    png = cairosvg.svg2png(url=svg, output_width=size, output_height=size)
    return Image.open(io.BytesIO(png)).convert("RGBA")

render("favicon.svg", 16).save("static/favicon-16x16.png")
render("favicon.svg", 32).save("static/favicon-32x32.png")
render("favicon-apple.svg", 180).convert("RGB").save("static/apple-touch-icon.png")
render("favicon.svg", 48).save("static/favicon.ico", sizes=[(16, 16), (32, 32), (48, 48)])

Für das Apple-Icon nehme ich eine Variante ohne abgerundete Ecken – iOS rundet selbst ab, sonst gibt es doppelte Rundungen. Und die Safari-Version ist einfarbig schwarz ohne Hintergrund, die Farbe setzt Safari selbst.

Nach dem Push waren die 404-Meldungen weg, und im Tab leuchtet seitdem das K mit dem Funken. Manche Browser halten ein altes Favicon übrigens hartnäckig im Cache – ein privates Fenster hilft beim Testen.

Nebenbei: languageCode ist veraltet

Bei jedem Build meldete Hugo zuletzt:

WARN  deprecated: project config key languageCode was deprecated in Hugo v0.158.0 [...] Use locale instead.

Die Lösung ist eine Zeile in der hugo.toml:

locale = "de-DE"   # statt: languageCode = "de-de"

PaperMod liest die Sprache für RSS und OpenGraph inzwischen ohnehin aus locale. Die Warnung war damit weg, sonst hat sich nichts geändert.

Stolperfallen & Learnings

• Vor DNS-Änderungen den Ist-Zustand ansehen. Bei mir zeigte der MX auf einen Server, den es nicht mehr gab.
• Einen alten Mailserver erst ablösen, wenn alle Adressen und Mails umgezogen sind – falls er noch läuft.
• SPF auch für Subdomains setzen, von denen nie Mail kommt: v=spf1 -all.
• DKIM-Schlüssel als Text kopieren, nicht abtippen.
• Impressum: ladungsfähige Anschrift, kein Postfach. Mit Werbung oder Affiliate-Links gelten die strengeren DDG-Pflichten.
• Die Datenschutzerklärung beschreibt die Technik – nicht umgekehrt. Erst die Log-Aufbewahrung festlegen, dann die Frist hineinschreiben.
• Favicons in 16 Pixeln beurteilen.

Fazit der Serie

Vier Teile, ein Abend – zugegeben, ein langer –, und aus einer Idee ist eine Website geworden, die ich verstehe und gern betreibe:

• ein kleiner, gehärteter VPS, auf dem sich niemand mit Passwort oder als root anmelden kann,
• Caddy mit automatischem HTTPS und Security-Headern, die fremde Inhalte konsequent draußen halten,
• eine Pipeline, die aus jedem git push in zehn Sekunden eine neue Seite macht – mit einem Runner im isolierten Netz und einem Schlüssel, der nur rsync darf,
• eine Kontaktadresse mit sauberem SPF, DKIM und DMARC,
• Impressum und Datenschutzerklärung, die zur Technik passen,
• und ein K mit Funken im Browser-Tab.

Alles mit Open-Source-Software, alles selbst betrieben. Und, ganz im Sinne des Mottos: mit einer ganzen Reihe von Fehlern unterwegs, aus denen ich mehr gelernt habe als aus den Schritten, die auf Anhieb geklappt haben.

Was als Nächstes kommt: Auf meiner Liste stehen eine automatische Prüfung der Content-Security-Policy in der Pipeline, damit mich das nächste Theme-Update nicht wieder mit Mond und Sonne überrascht, und ein Backup-Konzept für den VPS. Und die Idee, die ich in Teil 1 angedeutet habe: ein eigener kleiner Fediverse-Server. Aber das ist eine andere Geschichte.

Das klappt inzwischen. Vom Push bis zur fertigen Seite vergehen etwa zehn Sekunden. Wie das aufgebaut ist und warum ich dabei ziemlich paranoid war, zeigt dieser Teil.

Der Plan

Laptop ──git push──▶ Gitea (Homelab) ──▶ Runner (isoliertes LAB-Netz)
                                            │  hugo --minify
                                            ▼
                             rsync über SSH (nur ausgehend)
                                            ▼
                         VPS: Caddy ──▶ https://example.com

Die Bausteine:

• Gitea ist mein selbst gehosteter Git-Server, ein bisschen wie GitHub für zu Hause. Er läuft bei mir schon länger als Docker-Container im Homelab. Gitea bringt mit Gitea Actions eine eigene CI mit (Continuous Integration, also automatische Abläufe bei jedem Push), deren Syntax fast identisch zu GitHub Actions ist.
• Ein Runner führt diese Abläufe aus. Er bekommt bei mir eine eigene kleine VM.
• Hugo baut aus den Markdown-Dateien die fertige Seite.
• rsync über SSH schiebt die Seite zum VPS.

Das Schöne daran: Mein Heimnetz öffnet nach außen gar nichts. Der Runner baut zu Hause und verbindet sich von innen nach außen zum VPS. Es gibt keine Portfreigabe.

Voraussetzungen

Beispielwerte in diesem Artikel: git.example.com ist mein Gitea, 10.0.20.10 der Docker-Host, auf dem er läuft, 10.0.99.0/24 das LAB-Netz, 10.0.99.20 der Runner und 203.0.113.10 der VPS.

Schritt 1: Das Hugo-Projekt

Hugo installiere ich lokal direkt aus den offiziellen Releases, weil die Pakete der Distributionen oft hinterherhinken:

mkdir -p ~/.local/bin
URL=$(curl -s https://api.github.com/repos/gohugoio/hugo/releases/latest \
  | grep -o 'https://[^"]*hugo_extended_[0-9.]*_linux-amd64\.tar\.gz' | head -1)
curl -L "$URL" | tar -xz -C ~/.local/bin hugo
hugo version

Die Versionsnummer merke ich mir, denn genau diese Version bekommt später auch die Pipeline. Dann sehen die Seite lokal und live garantiert gleich aus.

In Gitea lege ich ein leeres, privates Repository an, klone es und erzeuge darin die Seite:

git clone ssh://git@git.example.com:2222/thomas/kabelbruch.git
cd kabelbruch
hugo new site . --force --format toml
git submodule add --depth=1 https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod

cat > .gitignore <<'EOF'
public/
resources/_gen/
.hugo_build.lock
EOF

Als Theme nutze ich PaperMod: schlicht, schnell, mit Hell-Dunkel-Modus, und es braucht weder Node.js noch externe Schriftarten. Mit hugo server -D sehe ich die Seite lokal unter http://localhost:1313 – inklusive Entwürfen.

Schritt 2: Ein Deploy-Schlüssel, der fast nichts darf

Die Pipeline braucht einen SSH-Schlüssel, um Dateien auf den VPS zu schieben. Dieser Schlüssel liegt später als Secret in Gitea und muss ohne Passphrase funktionieren, sonst kann ihn die Pipeline nicht nutzen. Genau deshalb soll er auf dem Server so wenig dürfen wie möglich.

Ein eigener Benutzer auf dem VPS

sudo apt install -y rsync
sudo adduser --system --group --shell /bin/sh --home /home/deploy deploy
sudo chown -R deploy:deploy /var/www/kabelbruch

Der Schlüssel

Auf dem Laptop, ohne Passphrase (-N ""):

ssh-keygen -t ed25519 -f ~/.ssh/kabelbruch_deploy -N "" -C "gitea-deploy-kabelbruch"
cat ~/.ssh/kabelbruch_deploy.pub

Der Trick: rrsync

Auf dem Server trage ich den öffentlichen Schlüssel mit zwei Einschränkungen ein:

sudo mkdir -p /home/deploy/.ssh
echo 'restrict,command="/usr/bin/rrsync /var/www/kabelbruch" ssh-ed25519 AAAA… gitea-deploy-kabelbruch' \
  | sudo tee /home/deploy/.ssh/authorized_keys
sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys

• restrict verbietet alles, was SSH sonst noch kann: Terminal, Port-Forwarding, Agent-Forwarding.
• command="/usr/bin/rrsync /var/www/kabelbruch" sorgt dafür, dass mit diesem Schlüssel ausschließlich rsync läuft, und zwar nur innerhalb dieses einen Verzeichnisses. rrsync („restricted rsync“) ist bei Debian im rsync-Paket enthalten. Es ist ein Python-Skript, python3 muss also installiert sein.

Selbst wenn jemand den Schlüssel stiehlt, kann er damit nur meine Website überschreiben. Ärgerlich, aber kein Weg auf den Server.

Der Gegentest

$ ssh -i ~/.ssh/kabelbruch_deploy deploy@203.0.113.10
PTY allocation request failed on channel 0
/usr/bin/rrsync error: Not invoked via sshd
Connection to 203.0.113.10 closed.

Genau so soll es aussehen: kein Terminal, keine Shell. Und der echte Upload:

rsync -av --delete -e "ssh -i ~/.ssh/kabelbruch_deploy" /tmp/kb-test/ deploy@203.0.113.10:

Wichtig ist der Doppelpunkt am Ende ohne Pfad. Das Zielverzeichnis legt rrsync auf dem Server fest.

Schritt 3: Der Runner – warum er in ein eigenes Netz kommt

Ein Runner führt Code aus dem Repository aus, und dafür bekommt er in der Regel Zugriff auf das Docker-Socket seines Hosts. Das heißt: Wer den Runner kontrolliert, ist auf dessen Host praktisch root. Mein Docker-Host im Homelab hat Dienste wie meinen Passwortmanager und meine Fotos. Da gehört so etwas nicht hin.

Deshalb bekommt der Runner eine eigene kleine VM in meinem LAB-Netz. Das ist ein VLAN für Testkram, das auf der Firewall vom Rest des Heimnetzes getrennt ist und nur DNS und Internet darf.

Die VM aus dem Cloud-Image

Statt Debian per Hand zu installieren, nehme ich das offizielle Debian-Cloud-Image und lasse cloud-init Benutzer und SSH-Schlüssel beim ersten Start einrichten. Auf dem Proxmox-Host:

mkdir -p /var/lib/vz/import && cd /var/lib/vz/import
wget https://cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2
echo 'ssh-ed25519 AAAA… thomas@laptop' > /root/runner.pub

qm create 108 --name ci-runner --ostype l26 \
  --cpu host --cores 2 --memory 4096 \
  --scsihw virtio-scsi-single \
  --scsi0 ZFS-Pool:0,import-from=/var/lib/vz/import/debian-13-genericcloud-amd64.qcow2,discard=on,iothread=1 \
  --ide2 ZFS-Pool:cloudinit \
  --boot order=scsi0 \
  --net0 virtio,bridge=vmbr0,tag=99,firewall=1 \
  --serial0 socket --vga serial0 \
  --agent enabled=1 \
  --ciuser thomas --sshkeys /root/runner.pub \
  --ipconfig0 ip=dhcp --ciupgrade 1 \
  --onboot 1

qm disk resize 108 scsi0 32G
qm config 108 | grep net0

ZFS-Pool ist der Name meines Speichers und tag=99 steht hier für die VLAN-ID des LAB-Netzes – beides an die eigene Umgebung anpassen. Aus der letzten Zeile notiere ich mir die MAC-Adresse, denn die VM soll per DHCP-Reservierung immer dieselbe IP bekommen.

Noch nicht starten – erst kommt die Firewall.

Gescheitert, Teil 1: .qcow2.1

wget meldete beim Download: Saving to: 'debian-13-genericcloud-amd64.qcow2.1'. Eine Datei mit demselben Namen lag schon im Verzeichnis, von einem früheren Versuch. Hätte ich das übersehen, hätte qm create das alte Image importiert. Also erst aufräumen:

mv -f debian-13-genericcloud-amd64.qcow2.1 debian-13-genericcloud-amd64.qcow2

Eine einzige Ausnahme in der Firewall

Der Runner muss genau zwei Dinge können: ins Internet (Container-Images, GitHub, SSH zum VPS) und mein Gitea erreichen. Das Internet ist im LAB-Netz ohnehin erlaubt. Für Gitea braucht es eine einzige, möglichst schmale Ausnahme: nur diese eine IP, nur zum Gitea-Host, nur HTTPS.

Auf meiner FortiGate sieht das so aus (Objektnamen an die eigene Konfiguration anpassen):

config firewall address
    edit "H_CI_RUNNER"
        set subnet 10.0.99.20 255.255.255.255
    next
end
config firewall policy
    edit 0
        set name "RUNNER-to-GITEA"
        set srcintf "VL99_LAB"
        set dstintf "VL20_SERVER"
        set srcaddr "H_CI_RUNNER"
        set dstaddr "H_DOCKER_HOST"
        set action accept
        set schedule "always"
        set service "HTTPS"
        set utm-status enable
        set ips-sensor "default"
        set logtraffic all
    next
end

Die Warnung „The no-inspection profile doesn’t perform SSL inspection“ beim Speichern ist hier gewollt. Der IPS-Sensor schaut trotzdem mit.

Den Code holt der Runner übrigens per HTTPS mit einem Token, das Gitea für jeden Lauf automatisch erzeugt. Einen SSH-Zugang zu Gitea braucht er nicht.

Eine ehrliche Einschränkung: Gitea läuft bei mir hinter einem Reverse Proxy, der auf derselben IP noch andere Dienste ausliefert. Rein vom Netz her könnte der Runner also auch deren Login-Seiten erreichen – Zugangsdaten hat er natürlich keine. Wer es ganz dicht will, legt im Reverse Proxy zusätzlich eine Zugriffsliste an, die die Runner-IP nur für Gitea zulässt.

VM starten und einrichten

qm start 108

Nach etwa einer Minute ist die VM erreichbar. Vom Laptop aus ein kurzer Test, ob das Netz so funktioniert wie gedacht:

ssh thomas@10.0.99.20
getent hosts git.example.com                    # DNS
curl -sI https://git.example.com | head -n 1     # Gitea: Firewall-Ausnahme
curl -sI https://github.com | head -n 1          # Internet

Dann Updates, Gast-Agent, automatische Sicherheitsupdates und Docker aus dem offiziellen Repository:

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y qemu-guest-agent unattended-upgrades curl ca-certificates
sudo systemctl enable --now qemu-guest-agent
sudo dpkg-reconfigure -plow unattended-upgrades

sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo docker run --rm hello-world

Schritt 4: Den Runner registrieren

Kleine Begriffsverwirrung vorweg: Der Runner hieß früher act_runner und wurde 2026 in Gitea Runner umbenannt. Das alte Docker-Image gitea/act_runner ist als veraltet markiert, aktuell ist gitea/runner.

Den Runner registriere ich nur für dieses eine Repository, nicht für die ganze Gitea-Instanz. Dann führt er auch nur Jobs aus diesem Repository aus. Den Registrierungs-Token gibt es in Gitea unter Repository → Einstellungen → Actions → Runners → „Neuen Runner erstellen“.

sudo mkdir -p /opt/runner && cd /opt/runner

sudo tee compose.yaml > /dev/null <<'EOF'
services:
  runner:
    image: gitea/runner:latest
    container_name: gitea-runner
    restart: unless-stopped
    environment:
      - GITEA_INSTANCE_URL=https://git.example.com
      - GITEA_RUNNER_REGISTRATION_TOKEN=${RUNNER_TOKEN}
      - GITEA_RUNNER_NAME=ci-runner
      - GITEA_RUNNER_LABELS=ubuntu-latest:docker://docker.gitea.com/runner-images:ubuntu-latest
    volumes:
      - ./data:/data
      - /var/run/docker.sock:/var/run/docker.sock
EOF

echo "RUNNER_TOKEN='<TOKEN_AUS_GITEA>'" | sudo tee .env > /dev/null
sudo chmod 600 .env
sudo docker compose up -d
sudo docker logs -f gitea-runner

Die einfachen Anführungszeichen um den Token in der .env sind Absicht: Sie schützen Sonderzeichen wie $, die Docker Compose sonst als Variable interpretieren würde.

Im Log steht dann zuerst .runner is missing or not a regular file – das ist beim ersten Start normal, die Registrierungsdatei gibt es ja noch nicht – und danach Runner registered successfully.

Den Token wieder loswerden

Der Token wird nur für die Registrierung gebraucht. Danach liegt alles Nötige in data/.runner. Also weg damit:

sudo rm .env
sudo sed -i '/GITEA_RUNNER_REGISTRATION_TOKEN/d' compose.yaml
sudo docker compose up -d
sudo docker logs gitea-runner

Lässt man die Zeile in der compose.yaml stehen, warnt Compose bei jedem Start The "RUNNER_TOKEN" variable is not set. Harmlos, aber unnötig. Wichtig ist, dass beim Neustart keine neue Registrierung im Log auftaucht, sondern nur declare successfully.

In Gitea steht der Runner jetzt mit dem Status Idle unter Einstellungen → Actions → Runners.

Ein kurzer Funktionstest

# .gitea/workflows/runner-test.yml
name: Runner-Test
on: workflow_dispatch
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: head -n 5 hugo.toml

workflow_dispatch heißt: Der Workflow startet nur auf Knopfdruck (Actions → Runner-Test → Workflow ausführen). Beim ersten Lauf lädt der Runner einmalig das Ubuntu-Image, danach war der Test nach 20 Sekunden grün.

Schritt 5: Secrets und der Host-Schlüssel

Die Pipeline braucht zwei Dinge aus Gitea:

1. Den privaten Deploy-Schlüssel als Secret. Einstellungen → Actions → Secrets, Name DEPLOY_KEY, Wert: der komplette Inhalt von ~/.ssh/kabelbruch_deploy inklusive der BEGIN- und END-Zeilen.

2. Den Host-Schlüssel des VPS als Variable. Die Pipeline soll sich nur mit meinem Server verbinden und keinen fremden akzeptieren. Der bequeme Weg wäre StrictHostKeyChecking=no – genau den will ich nicht. Stattdessen hole ich den Host-Schlüssel einmal ab und prüfe ihn gegen:

# auf dem Laptop
ssh-keyscan -t ed25519 203.0.113.10 2>/dev/null | tee /tmp/kb_known_hosts
ssh-keygen -lf /tmp/kb_known_hosts

# auf dem VPS
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Nur wenn beide SHA256:…-Fingerprints übereinstimmen, kommt die Zeile aus /tmp/kb_known_hosts als Variable KNOWN_HOSTS in Gitea. Ein Secret ist dafür nicht nötig, der Host-Schlüssel ist öffentlich.

Kleiner Stolperstein im Eingabefeld: Die Zeile ist so lang, dass Gitea sie optisch umbricht. Ob das nur die Anzeige ist oder ein echter Zeilenumbruch, der den Eintrag kaputtmachen würde, sieht man nicht. Mein Trick: Cursor hinter ssh-ed25519, mit Entf alles bis zum AAAA… heranziehen, ein Leerzeichen setzen. Dann ist es garantiert eine Zeile.

Schritt 6: Der Deploy-Workflow

Das Herzstück, .gitea/workflows/deploy.yml:

name: Build & Deploy
on:
  push:
    branches: [main]
  workflow_dispatch:

concurrency:
  group: deploy
  cancel-in-progress: false

env:
  HUGO_VERSION: "0.169.0"

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout (inkl. Theme)
        uses: actions/checkout@v4
        with:
          submodules: recursive

      - name: Werkzeuge installieren
        run: |
          apt-get update -qq
          apt-get install -y -qq rsync openssh-client
          curl -fsSL "https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz" \
            | tar -xz -C /usr/local/bin hugo
          hugo version

      - name: Seite bauen
        run: hugo --minify --gc

      - name: SSH vorbereiten
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
          KNOWN_HOSTS: ${{ vars.KNOWN_HOSTS }}
        run: |
          install -m 700 -d ~/.ssh
          printf '%s\n' "$DEPLOY_KEY" > ~/.ssh/deploy_key
          chmod 600 ~/.ssh/deploy_key
          printf '%s\n' "$KNOWN_HOSTS" > ~/.ssh/known_hosts
          ssh-keygen -lf ~/.ssh/known_hosts

      - name: Deploy
        run: |
          rsync -rltcz --delete --chmod=D755,F644 \
            -e "ssh -i $HOME/.ssh/deploy_key -o StrictHostKeyChecking=yes -o UserKnownHostsFile=$HOME/.ssh/known_hosts" \
            public/ deploy@203.0.113.10:

      - name: Key entfernen
        if: always()
        run: rm -f ~/.ssh/deploy_key

Was die Details bewirken:

• on: push auf main: Jeder Push veröffentlicht. Mit workflow_dispatch geht es zusätzlich per Knopfdruck.
• concurrency: Zwei schnelle Pushes hintereinander deployen nacheinander, nicht gleichzeitig.
• HUGO_VERSION fest gepinnt: Dieselbe Version wie auf dem Laptop – keine Überraschungen nach einem Hugo-Update.
• Secrets über env: statt direkt im Skript: Gitea setzt den Wert nicht in den Befehlstext ein, sondern übergibt ihn als Umgebungsvariable. Sonderzeichen können so den Befehl nicht verbiegen.
• ssh-keygen -lf schreibt den Fingerprint ins Log. So sehe ich bei jedem Lauf, dass der richtige Host-Schlüssel benutzt wird.
• rsync -rltcz: -c vergleicht Prüfsummen statt Zeitstempel. Hugo erzeugt bei jedem Build neue Dateien, mit -c werden trotzdem nur wirklich geänderte übertragen. --delete räumt alte Dateien auf dem Server weg, --chmod setzt saubere Rechte.
• if: always(): Der private Schlüssel wird auch dann gelöscht, wenn ein Schritt vorher fehlschlägt.

Gescheitert, Teil 2: Der verschwundene Ordner

Den Test-Workflow wollte ich im selben Zug loswerden und habe zuerst git rm .gitea/workflows/runner-test.yml ausgeführt und danach die neue deploy.yml angelegt. Ergebnis:

bash: .gitea/workflows/deploy.yml: No such file or directory

Git hatte mit der einzigen Datei auch den nun leeren Ordner entfernt. Committet und gepusht wurde nur das Löschen. Ein mkdir -p .gitea/workflows davor, und es lief.

Gescheitert, Teil 3: Der Artikel, der nicht erschien

Als Teil 1 dieser Serie fertig war, habe ich ihn committet, gepusht, die Pipeline lief grün durch – und die Seite lieferte 404.

Erster Verdacht: Timing. Der curl kam vielleicht, bevor das Deployment fertig war. War es aber nicht. Die Pipeline hatte sauber gebaut, denn andere Änderungen aus demselben Commit waren live.

Die Ursache stand in der ersten Zeile, die man immer übersieht: Der Artikel war im Commit noch auf draft: true. Ich hatte ihn zwar auf veröffentlicht umgestellt, im Projekt war aber eine ältere Fassung der Datei gelandet. Und Hugo macht genau, was es soll: Entwürfe werden beim Build einfach übersprungen – ohne Warnung, ohne Fehler, die Pipeline bleibt grün.

Seitdem prüfe ich vor dem Veröffentlichen, was wirklich im Commit steht, und nicht, was ich glaube, gespeichert zu haben:

git show HEAD:content/posts/mein-artikel.md | grep '^draft'

Stolperfallen & Learnings

• Den Runner isolieren. Er führt Code aus und hat über das Docker-Socket Root-Rechte auf seinem Host.
• Eine Firewall-Ausnahme, so schmal wie möglich: eine Quell-IP, ein Ziel, ein Dienst.
• Deploy-Schlüssel mit restrict und rrsync einschränken. Dann ist ein gestohlener Schlüssel kein Weg auf den Server.
• Host-Schlüssel prüfen statt StrictHostKeyChecking=no. Einmal den Fingerprint vergleichen, dann ist Ruhe.
• Registrierungs-Token nach dem ersten Start entfernen.
• wget hängt .1 an, wenn die Datei schon existiert. Vor dem Import prüfen.
• git rm löscht leere Ordner mit.
• Eine grüne Pipeline heißt nicht, dass der Artikel online ist. Hugo überspringt Entwürfe stillschweigend.

Fazit & Ausblick

Die Pipeline ist der Teil, der mir am meisten Spaß macht: Ich schreibe, pushe – und zehn Sekunden später ist der Artikel online. Dabei hat jeder Baustein nur genau die Rechte, die er braucht. Der Runner steht in einem isolierten Netz mit einer einzigen Ausnahme. Der Deploy-Schlüssel kann nur rsync in ein Verzeichnis. Und die Pipeline spricht nur mit einem Server, dessen Schlüssel sie kennt.

Was als Nächstes kommt: In Teil 4 geht es um die Dinge, die eine Website erst „fertig“ machen: eine funktionierende Kontaktadresse (inklusive eines Mailservers, der nur noch im DNS existierte), SPF, DKIM und DMARC, Impressum und Datenschutzerklärung – und ein Favicon.

Voraussetzungen

• Der gehärtete VPS aus Teil 1 mit Debian 13, Firewall ufw (Ports 22, 80 und 443 offen)
• Eine eigene Domain, deren DNS bei einem Anbieter liegt, bei dem man A- und AAAA-Einträge setzen kann (bei mir: Cloudflare)
• Später für den CSP-Teil: Hugo 0.169.0 mit dem Theme PaperMod

In den Beispielen steht example.com für meine Domain, 203.0.113.10 für die IPv4- und 2001:db8::10 für die IPv6-Adresse des Servers.

Schritt 1: DNS – und warum die Wolke grau bleibt

Meine Domain liegt bei Cloudflare. Cloudflare kann Einträge entweder nur als DNS beantworten (graue Wolke, „DNS only“) oder den ganzen Verkehr als Proxy durch die eigenen Server leiten (orange Wolke). Der Proxy ist standardmäßig an. Ich habe ihn bewusst ausgeschaltet:

• Datenschutz: Mit Proxy läuft jeder Seitenaufruf inklusive IP-Adresse über ein US-Unternehmen, das den TLS-Verkehr zudem entschlüsselt. Das müsste ich in der Datenschutzerklärung erklären – und genau solche Abhängigkeiten wollte ich vermeiden.
• Durchschaubarkeit: Ohne Proxy holt sich der Webserver seine Zertifikate selbst, und ich sehe direkt, was zwischen Browser und Server passiert.
• Zukunft: Ich plane einen eigenen Fediverse-Server. Fediverse-Server sprechen direkt miteinander, und Bot-Schutz im Proxy blockt solche Anfragen gern.

Cloudflare beantwortet bei mir also nur noch DNS-Anfragen und sieht keine Besucher.

IPv6-Adresse herausfinden

Für den AAAA-Eintrag brauche ich die IPv6-Adresse des Servers:

ip -6 addr show scope global

Interessant: Die Adresse, die netcup automatisch vergibt, wird aus der MAC-Adresse der virtuellen Netzwerkkarte gebildet (man erkennt das am ff:fe in der Mitte). Sie bleibt stabil, solange die Netzwerkkarte nicht neu angelegt wird. Für den Anfang reicht das völlig.

Die Einträge

Prüfen, ob alles angekommen ist – direkt beim öffentlichen Resolver gefragt:

dig +short example.com A @1.1.1.1
dig +short example.com AAAA @1.1.1.1
dig +short www.example.com A @1.1.1.1

Kommen hier Adressen von Cloudflare zurück statt der eigenen, ist der Proxy noch an.

Schritt 2: Caddy installieren

Als Webserver nutze ich Caddy. Der große Vorteil: Caddy besorgt und erneuert TLS-Zertifikate von Let’s Encrypt komplett automatisch, die Konfiguration ist kurz und lesbar, und Caddy ist – natürlich – Open Source.

Debian hat zwar ein eigenes Caddy-Paket, das ist aber oft deutlich älter. Ich nehme deshalb das offizielle Repository des Projekts, dann kommen Updates ganz normal über apt:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl gnupg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg /etc/apt/sources.list.d/caddy-stable.list
sudo apt update && sudo apt install -y caddy
caddy version

Für den ersten Test lege ich ein Webverzeichnis mit einer Mini-Seite an:

sudo mkdir -p /var/www/kabelbruch
echo '<!doctype html><html lang="de"><meta charset="utf-8"><title>Kabelbruch</title><h1>Kabelbruch – hier entsteht was.</h1></html>' | sudo tee /var/www/kabelbruch/index.html

Schritt 3: Das Caddyfile

Die komplette Konfiguration steht in /etc/caddy/Caddyfile:

{
    email admin@example.com
}

www.example.com {
    header -Server
    redir https://example.com{uri} permanent
}

example.com {
    root * /var/www/kabelbruch
    encode zstd gzip
    file_server

    header {
        Strict-Transport-Security "max-age=31536000"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
        Permissions-Policy "camera=(), microphone=(), geolocation=()"
        Content-Security-Policy "default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'"
        -Server
    }
}

Was hier passiert:

• email ist die Adresse für Let’s Encrypt. Dorthin kommt nur Post, wenn mit den Zertifikaten etwas nicht stimmt.
• www leitet dauerhaft (301) auf die Domain ohne www um. So gibt es die Seite nur unter einer Adresse.
• encode zstd gzip komprimiert die Antworten.
• file_server liefert die Dateien aus /var/www/kabelbruch aus. Mehr braucht eine statische Seite nicht.

Und die Header im Einzelnen:

Noch ein angenehmer Standard: Caddy schreibt von sich aus keine Zugriffsprotokolle. Für den Datenschutz ist das genau richtig.

Bevor eine neue Konfiguration aktiv wird, lasse ich sie immer erst prüfen:

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Gescheitert: ein Link im Caddyfile

Mein erstes Caddyfile hatte ich aus einem Chatfenster kopiert. Beim Nachsehen stand in Zeile 5 plötzlich so etwas:

[www.example.com](https://www.example.com) {

Der Chat hatte den Hostnamen automatisch in einen Markdown-Link verwandelt – und genau so war er in der Datei gelandet. caddy validate hätte das zum Glück abgefangen, bevor etwas kaputtgeht.

Der eigentliche Spaß kam beim Reparieren: Jeder sed-Befehl, in dem der Hostname vorkam, wurde beim Kopieren wieder zu einem Link. Ich habe die Klammer also mehrfach „repariert“, indem ich sie neu hineinkopiert habe. Gelöst hat es ein Befehl, der den Hostnamen gar nicht erst enthält, sondern nur die überflüssigen Zeichen in Zeile 5 entfernt:

sudo sed -i -e '5s/^\[//' -e '5s/](.*)//' /etc/caddy/Caddyfile

Und dann die nächste Falle: Als ich die Ausgabe von grep zur Kontrolle zurück in den Chat kopiert habe, sah sie wieder kaputt aus – weil der Chat den Hostnamen beim Anzeigen erneut verlinkt hat. Die Datei war längst in Ordnung. Ein Screenshot vom Terminal hat das am Ende geklärt. Ein Test, der den Hostnamen nicht enthält, hätte es auch getan:

grep -c '\[' /etc/caddy/Caddyfile    # 0 = keine eckigen Klammern mehr

Learning: Hostnamen in Befehlen, die man aus Chats oder Webseiten kopiert, immer kritisch anschauen. Und im Zweifel einen Screenshot vom Terminal machen statt Text zu kopieren.

Schritt 4: Testen

curl -I https://example.com
curl -I https://www.example.com

Die erste Anfrage liefert HTTP/2 200 mit allen Headern, die zweite eine 301-Weiterleitung. Ein gültiges Zertifikat gab es nach wenigen Sekunden, ohne dass ich irgendetwas dafür tun musste.

Dabei sind mir noch zwei Kleinigkeiten aufgefallen:

1. server: Caddy bei der Weiterleitung. Die Header-Regeln galten anfangs nur für den Hauptblock, nicht für den www-Block. Deshalb steht oben im Caddyfile auch dort ein header -Server.

2. HTTP/3 braucht UDP. In den Antworten steht alt-svc: h3=":443". Caddy bietet also HTTP/3 an, und das läuft über UDP Port 443. Die Firewall aus Teil 1 lässt aber nur TCP durch. Browser fallen dann still auf HTTP/2 zurück, es funktioniert also trotzdem – sauberer ist es aber, UDP auch freizugeben:

sudo ufw allow 443/udp

Und falls caddy validate meckert, die Datei sei „not formatted“: Das ist reine Kosmetik (Leerzeichen statt Tabs). sudo caddy fmt --overwrite /etc/caddy/Caddyfile räumt das auf.

Schritt 5: Mond und Sonne – die CSP schlägt zu

Ein paar Tage später – nun ja, ein paar Stunden – lief die echte Seite: gebaut mit Hugo und dem Theme PaperMod (wie sie dorthin kommt, zeige ich in Teil 3). Und oben neben dem Titel sah ich Mond und Sonne gleichzeitig. Eigentlich zeigt PaperMod nur eines der beiden Symbole, je nachdem, ob gerade das helle oder das dunkle Design aktiv ist. Umschalten ging auch nicht.

Die Browser-Konsole (F12) hat den Grund sofort verraten, viermal in Rot:

Executing inline script violates the following Content Security Policy
directive 'default-src 'self''. Either the 'unsafe-inline' keyword,
a hash ('sha256-…'), or a nonce ('nonce-…') is required to enable
inline execution.

PaperMod hat ein paar kleine Skripte direkt im HTML stehen („Inline-Skripte“), unter anderem für den Hell-Dunkel-Umschalter. Meine strenge CSP erlaubt aber nur Skripte aus eigenen Dateien. Lokal mit hugo server merkt man davon nichts, weil dort keine CSP gesetzt ist – erst auf dem echten Server.

Die bequeme Lösung – und warum ich sie nicht nehme

Am einfachsten wäre script-src 'self' 'unsafe-inline'. Damit wäre aber jedes Inline-Skript erlaubt, also auch eines, das jemand irgendwann einschleust. Das würde einen großen Teil des Schutzes der CSP aushebeln.

Die saubere Lösung: Hashes

Stattdessen erlaube ich genau diese Skripte über ihren SHA-256-Hash. Der Browser berechnet den Hash jedes Inline-Skripts und führt es nur aus, wenn er in der CSP steht. Ein verändertes oder fremdes Skript hat einen anderen Hash und wird weiter blockiert.

Die Hashes stehen zwar in der Fehlermeldung, aber abtippen wollte ich sie nicht: l und I, 0 und O – ein einziges falsches Zeichen, und der Hash ist wertlos. Also lasse ich sie aus einem lokalen Build berechnen. Das Ergebnis ist identisch, solange lokal und auf dem Server dieselbe Hugo-Version baut:

hugo --minify -D -d /tmp/kb-csp

python3 - <<'EOF'
import re, hashlib, base64, pathlib
hashes = set()
pattern = re.compile(r'<script(?![^>]*\bsrc=)(?![^>]*application/ld\+json)[^>]*>(.*?)</script>', re.S | re.I)
for f in pathlib.Path('/tmp/kb-csp').rglob('*.html'):
    for m in pattern.finditer(f.read_text(encoding='utf-8')):
        digest = hashlib.sha256(m.group(1).encode('utf-8')).digest()
        hashes.add("'sha256-" + base64.b64encode(digest).decode() + "'")
print(" ".join(sorted(hashes)))
EOF

• -D baut auch Entwürfe mit, damit auch Skripte erfasst werden, die nur auf Artikelseiten vorkommen.
• JSON-LD-Blöcke (application/ld+json) lasse ich aus. Das sind Daten für Suchmaschinen, die der Browser nicht ausführt.

Heraus kamen fünf Hashes, darunter die vier aus der Konsole. Die kommen in die CSP:

Content-Security-Policy "default-src 'self'; script-src 'self' 'sha256-<HASH_1>' 'sha256-<HASH_2>' 'sha256-<HASH_3>' 'sha256-<HASH_4>' 'sha256-<HASH_5>'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'"

Vorher sichere ich das Caddyfile, dann validate und reload:

sudo cp /etc/caddy/Caddyfile /etc/caddy/Caddyfile.bak
# CSP-Zeile anpassen, dann:
sudo caddy validate --config /etc/caddy/Caddyfile && sudo systemctl reload caddy

Seite neu geladen (Strg+Shift+R) – und schon war nur noch ein Symbol zu sehen, der Umschalter funktionierte, und die Konsole war leer.

Der Haken: Ändert sich durch ein Update von PaperMod oder Hugo eines dieser Skripte, stimmt sein Hash nicht mehr. Das merkt man an genau demselben Symptom: Mond und Sonne gleichzeitig. Dann einfach das Skript oben noch einmal laufen lassen und die CSP aktualisieren. Das automatisch in der Pipeline zu prüfen, steht auf meiner Liste.

Stolperfallen & Learnings

• Cloudflare-Proxy bewusst entscheiden. Er ist standardmäßig an und hat Folgen für Datenschutz und direkte Server-zu-Server-Verbindungen.
• caddy validate vor jedem reload. Das hat mich vor dem Link im Caddyfile bewahrt.
• Kopierte Hostnamen prüfen. Chats und Webseiten verwandeln sie gern in Links – auch beim Zurückkopieren der Ausgabe.
• Header gelten pro Block. Der www-Block braucht sein eigenes header -Server.
• HTTP/3 = UDP 443. In der Firewall freigeben.
• CSP mit Hashes statt unsafe-inline. Die Hashes berechnen statt abtippen, und nach Theme-Updates neu prüfen.

Fazit & Ausblick

Mit einer Handvoll Zeilen Caddyfile liefert der Server die Seite jetzt per HTTPS aus, mit automatisch erneuerten Zertifikaten, ohne Zugriffsprotokolle und mit Security-Headern, die fremde Inhalte konsequent draußen halten. Die CSP hat mich zwar kurz das Theme gekostet, aber genau dafür ist sie da: Sie hat sofort gezeigt, was auf der Seite eigentlich alles ausgeführt wird.

Was als Nächstes kommt: In Teil 3 baue ich die Pipeline. Ich schreibe Artikel auf meinem Laptop, pushe sie in meinen eigenen Git-Server im Homelab, ein Runner baut die Seite und schiebt sie zum VPS – über einen SSH-Schlüssel, der dort nichts anderes darf, als genau dieses eine Verzeichnis zu beschreiben.

Warum ein Blog – und warum „Kabelbruch“?

Ich bin ITler, mein Alltag dreht sich um Netzwerk und Security. Und „Kabelbruch“ passte eigentlich schon immer gut zu dem, was ich mache – ich fand den Namen einfach witzig. Ein Kabelbruch ist ja genau die Art Fehler, nach der man stundenlang sucht, obwohl die Konfiguration perfekt ist.

Den Blog gibt es, weil ich meine Projekte gern teilen möchte: was ich so baue, woran ich scheitere und welche Erfolge ich habe. Deshalb steht über allem das Motto: Basteln, ausprobieren, auch mal scheitern und darüber schreiben. Die Fehlschläge gehören hier ausdrücklich dazu – meistens lernt man aus denen sowieso mehr.

Außerdem bin ich ein großer Fan von Open Source und versuche, in meinem privaten Umfeld wo immer möglich darauf zu setzen. Das zieht sich auch durch diese Seite: Vom Betriebssystem über den Webserver bis zum Git-Server und dem Seitengenerator ist hier alles Open Source.

Und weil ein Blog über Homelab und Security irgendwo laufen muss, ist sein Aufbau gleich das erste Projekt. Daraus ist diese kleine Serie geworden:

1. Die Idee und der Server (dieser Teil)
2. Caddy, DNS und Security-Header
3. Die Pipeline: vom git push zur fertigen Seite
4. Mail, Impressum und Favicon

Die Grundsatzentscheidungen

Statisch statt WordPress

Ich wollte eine Seite, die ich verstehe, die wenig Pflege braucht und kaum Angriffsfläche bietet. Deshalb ist Kabelbruch eine statische Website, gebaut mit Hugo. Ein statischer Seitengenerator macht aus Markdown-Dateien fertige HTML-Seiten. Auf dem Server liegen am Ende nur noch Dateien – keine Datenbank, kein PHP, kein Login-Formular, das man angreifen könnte.

Die Artikel schreibe ich als Markdown-Dateien in einem Git-Repository. Das hat einen netten Nebeneffekt: Ich habe eine Versionsgeschichte für jeden Text und kann Code-Beispiele direkt mit Syntax-Hervorhebung einbauen.

Nicht im Homelab

Natürlich war die erste Idee, die Seite einfach zu Hause auf meinem Proxmox-Server laufen zu lassen. Ich habe mich trotzdem dagegen entschieden:

• Eine öffentliche Website im Heimnetz bedeutet eine Portfreigabe oder einen Tunnel, ein eigenes DMZ-Netz und deutlich mehr Monitoring. Das kann man machen, aber es muss gut durchdacht sein.
• Fällt zu Hause der Strom oder das Internet aus, wäre der Blog auch weg.

Mein Kompromiss: Gebaut wird die Seite im Homelab, ausgeliefert von einem kleinen Server im Rechenzentrum. Mein Heimnetz muss dafür nichts nach außen öffnen – die Verbindung geht nur von innen nach außen. Wie das genau funktioniert, zeige ich in Teil 3.

Welcher Hoster?

Meine erste Wahl wäre Hetzner gewesen. Allerdings hat Hetzner 2026 kräftig an der Preisschraube gedreht: Zum April stiegen die Cloud-Server-Preise im Schnitt um rund 32 Prozent, im Juni folgte für einige Server-Linien eine weitere Runde. Ganz allein ist Hetzner damit nicht – auch andere Anbieter haben erhöht, Grund sind vor allem die gestiegenen Preise für Arbeitsspeicher. Trotzdem wollte ich mir die Alternativen ansehen.

Die gute Nachricht: Für eine statische Seite braucht man fast nichts. Ich habe mich für einen kleinen VPS (Virtual Private Server, also eine eigene virtuelle Maschine beim Anbieter) bei netcup entschieden:

Für die Website allein ist das sogar überdimensioniert. Aber ich habe schon die nächste Idee im Hinterkopf (dazu am Ende mehr), und dafür ist ein bisschen Luft ganz praktisch.

Ein Tipp beim Preisvergleich: Manche Anbieter zeigen Preise netto, andere inklusive 19 % MwSt. Wer das nicht beachtet, vergleicht Äpfel mit Birnen.

Und noch etwas Rechtliches: Sobald personenbezogene Daten auf dem Server landen – und eine IP-Adresse zählt schon dazu –, gehört ein Vertrag zur Auftragsverarbeitung (AV-Vertrag nach Art. 28 DSGVO) mit dem Hoster dazu. Bei netcup lässt sich der im Kundenmenü abschließen. Ich bin kein Anwalt, aber das ist eine Sache von zehn Minuten und sollte man einfach machen.

Voraussetzungen

Was ich für diesen Teil benutzt habe:

• Einen VPS mit Debian 13 (frisch installiert, Root-Zugang per SSH)
• Einen Linux-Rechner mit OpenSSH-Client
• Einen vorhandenen SSH-Schlüssel vom Typ ed25519

In allen Beispielen steht 203.0.113.10 für die IP meines Servers und thomas für meinen Benutzer. Setz dort deine eigenen Werte ein.

Schritt 1: Den SSH-Schlüssel hinterlegen

Ein SSH-Schlüssel ist sicherer als jedes Passwort – sofern man den richtigen erwischt. Bei mir lagen schon zwei Schlüssel in ~/.ssh/, einer davon für meinen Git-Server. Mit ssh-keygen -lf sieht man, welcher Schlüssel welchen Kommentar trägt, und damit meistens auch, wofür er gedacht war:

ls ~/.ssh/*.pub
ssh-keygen -lf ~/.ssh/id_ed25519.pub

Den öffentlichen Teil (die .pub-Datei – der private Schlüssel verlässt den eigenen Rechner nie) kopiere ich auf den Server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

Damit ich mir die IP nicht merken muss, bekommt der Server einen Eintrag in der ~/.ssh/config auf meinem Rechner:

Host kabelbruch
    HostName 203.0.113.10
    User root
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

IdentitiesOnly yes sorgt dafür, dass genau dieser Schlüssel benutzt wird und SSH nicht der Reihe nach alle durchprobiert. Ab jetzt reicht ssh kabelbruch.

Schritt 2: Ein eigener Benutzer statt root

Als root zu arbeiten ist bequem, aber genau deshalb keine gute Idee. Ich lege mir einen eigenen Benutzer an, der per sudo Administratorrechte bekommt:

apt update && apt install -y sudo
adduser thomas
usermod -aG sudo thomas

mkdir -p /home/thomas/.ssh
cp /root/.ssh/authorized_keys /home/thomas/.ssh/
chown -R thomas:thomas /home/thomas/.ssh
chmod 700 /home/thomas/.ssh
chmod 600 /home/thomas/.ssh/authorized_keys

Das Passwort, das adduser abfragt, brauche ich später nur noch für sudo, nicht mehr zum Anmelden.

Wichtig: Bevor man irgendetwas am SSH-Zugang ändert, immer eine zweite Sitzung offen lassen. Das ist der Rettungsanker, falls man sich aussperrt.

Schritt 3: Passwörter und root-Login abschalten

Jetzt kommt der eigentliche Härtungsschritt. Ich lege die Einstellungen in einer eigenen Datei unter sshd_config.d ab, statt die Hauptkonfiguration zu bearbeiten:

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
EOF

sudo sshd -t && sudo systemctl reload ssh
sudo sshd -T | grep -E 'passwordauth|permitroot'

Die Ausgabe sollte passwordauthentication no und permitrootlogin no zeigen.

Warum 00- im Dateinamen? Bei sshd gewinnt der erste gefundene Wert. Manche Server-Images bringen eine eigene Datei mit, zum Beispiel 50-cloud-init.conf mit PasswordAuthentication yes. Mit 00- am Anfang wird meine Datei zuerst gelesen und setzt sich durch.

Gescheitert, Teil 1: Permission denied

Mein erster Versuch sah so aus:

cat > /etc/ssh/sshd_config.d/00-hardening.conf <<'EOF'
...
EOF

Ergebnis: Permission denied – und gleich danach sshd: command not found. Ich war schon als thomas angemeldet, nicht mehr als root. Und hier kommt eine klassische Falle: Ein sudo vor dem Befehl hilft bei der Umleitung > nicht, denn die Umleitung macht die Shell, und die läuft weiterhin als normaler Benutzer. Die Lösung ist sudo tee, wie oben im Beispiel. Das sshd: command not found hat übrigens einen ganz harmlosen Grund: sshd liegt in /usr/sbin, und das steht bei normalen Benutzern nicht im Pfad. Mit sudo davor wird es gefunden.

Gescheitert, Teil 2: Plötzlich komme ich nicht mehr rein

Nach der Härtung wollte ich mich testweise neu verbinden:

$ ssh kabelbruch
root@203.0.113.10: Permission denied (publickey).

Kurzer Schreckmoment. Dabei hat schlicht alles funktioniert: In meiner ~/.ssh/config stand noch User root – und root darf sich ja jetzt nicht mehr anmelden. Die Sperre hat also genau das getan, was sie sollte.

Ich habe dann grep auf die ~/.ssh/config losgelassen, um nachzusehen – allerdings im falschen Terminal, nämlich auf dem Server statt auf meinem Laptop. Dort gibt es diese Datei natürlich nicht. Eine Faustregel, die ich mir seitdem merke: Steht im Prompt der Name des Servers, bin ich auf dem Server. Alles rund um den eigenen SSH-Schlüssel und die SSH-Config passiert lokal.

Nachdem in der Config User thomas stand, ging es sofort. Der Gegentest gehört trotzdem dazu:

ssh kabelbruch            # klappt als thomas
ssh root@203.0.113.10     # wird abgelehnt

Schritt 4: Die Firewall

Als Nächstes kommt eine einfache Firewall. Ich nutze ufw (Uncomplicated Firewall), die macht ihrem Namen alle Ehre:

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Die Reihenfolge ist entscheidend: SSH erlauben, bevor man ufw enable ausführt. Sonst sperrt man sich mit dem Aktivieren selbst aus. ufw warnt beim Einschalten trotzdem, dass bestehende SSH-Verbindungen unterbrochen werden könnten. Diese Warnung kommt immer, egal welche Regeln existieren. Wenn die SSH-Regel drin ist, kann man sie mit y bestätigen.

Am Ende sind nur noch SSH (22), HTTP (80) und HTTPS (443) offen, für IPv4 und IPv6. Port 80 und 443 brauche ich in Teil 2 für den Webserver und die TLS-Zertifikate.

Schritt 5: Automatische Sicherheitsupdates

Ein Server, der sich nicht selbst aktualisiert, wird irgendwann vergessen. Debian bringt dafür unattended-upgrades mit:

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

Im Dialog „Ja“ wählen, fertig. Sicherheitsupdates werden ab jetzt täglich automatisch eingespielt.

Stolperfallen & Learnings

• Immer eine zweite SSH-Sitzung offen lassen, solange man am Zugang schraubt.
• sudo hilft nicht bei >, dafür gibt es sudo tee.
• 00- im Dateinamen unter sshd_config.d, weil der erste Wert gewinnt.
• Erst SSH in der Firewall erlauben, dann ufw enable.
• Auf den Prompt schauen: Laptop oder Server? Die Hälfte meiner Fehler an diesem Abend waren Befehle im falschen Terminal.
• Permission denied (publickey) nach der Härtung ist oft gar kein Fehler, sondern die neue Sperre bei der Arbeit. Erst die eigene SSH-Config prüfen.

Fazit & Ausblick

Nach etwa einer Stunde hatte ich einen Server, auf dem man sich nur noch mit meinem Schlüssel und nicht als root anmelden kann, bei dem nur drei Ports offen sind und der sich selbst mit Sicherheitsupdates versorgt. Das ist kein Hochsicherheitstrakt, aber eine solide Grundlage – und genau das, was ein öffentlicher Server mindestens braucht.

Was als Nächstes kommt: In Teil 2 installiere ich Caddy als Webserver, stelle das DNS ein und setze Security-Header. Dabei hat mich eine Content-Security-Policy eine Weile beschäftigt: Plötzlich waren auf meiner Seite Mond und Sonne gleichzeitig zu sehen.

Und die Idee im Hinterkopf, für die der Server ein bisschen Luft hat: ein eigener kleiner Fediverse-Server. Aber dazu mehr, wenn es so weit ist.