CheckPoint VPS-Projekt — Zusammenfassung & Lernhinweise

Ausgangslage

VPS bei IONOS (Typ VPS 6-8-240: 6 vCore, 8 GB RAM, 240 GB NVMe SSD).
Alter Zustand: unsauber gewachsen — ein Git-Server und eine unfertige App lagen ohne Struktur durcheinander. Ziel: kompletter sauberer Neuaufbau, kein Reparieren des Bestehenden.
Datenschutz-Vorgabe für die geplante App (CheckPoint Ehrenamt): EU-Hosting, eigener Server (= dieser VPS).

Kompletter Wipe statt Reparatur — bereits umgesetzt, VPS ist neu installiert.
Reihenfolge: Desktop zuerst sauber (Anker-Maschine), dann VPS, Laptop zuletzt.
LLM-Zugriff (Desktop als lokaler LLM-Host) läuft künftig über VPN, nicht über einen SSH-Tunnel via VPS.
SSH-Keys: pro Gerät ein eigenes ed25519-Keypair (Desktop, Laptop). Private Key verlässt das Gerät nie.
Shell: Analyse gemacht, finale Entscheidung noch offen (siehe Lernhinweise + Status).

„Permission denied" = Verbindung steht, Dienst läuft — nur die Authentifizierung scheitert (Key / User / Berechtigung).
„Connection refused" = auf dem Port antwortet niemand → Dienst gestoppt/abgestürzt oder etwas blockt davor (Firewall / Fail2ban).
Die Reihenfolge „erst denied, dann refused" ist ein typisches Fail2ban-Muster: erst Fehlversuche, dann IP-Bann.
ssh -v (verbose) zeigt, wie weit der Verbindungsaufbau kommt → trennt Netzwerk-/Firewall-Problem von Auth-Problem.

Bannt nach mehreren Fehlversuchen die IP. Weitere Blind-Versuche können den Bann verlängern/erneuern → nicht „auf Verdacht" wiederholt probieren.
Die Web-Konsole des Hosters ist der Rettungsweg, wenn SSH gesperrt ist.

Ein Wipe ist endgültig. Entscheidend ist nur, ob Daten nur an einem Ort existieren (single-copy).
Wenn man bewusst „frisch" neu macht (Keys und LLMs regeneriert man ohnehin), muss das Backup nur das Unwiederbringliche sichern: echte Daten/Dokumente, single-copy-Repos, Passwort-Tresor/2FA-Seeds, ggf. GPG-Keys.
In diesem Fall gelöst: Repo-Klone liegen auf der zweiten Laptop-Partition → Wipe war risikofrei.

Das sind zwei getrennte Entscheidungen, die nur wie eine aussehen.
Interaktive Shell = persönlicher Komfort. Per chsh -s … wechselbar, jederzeit reversibel, berührt das System nicht (Arch: /bin/sh → Bash; Systemskripte laufen darüber, unabhängig von der Login-Shell).
Skriptsprache = die einzige „klebende" Entscheidung: Alles, was den VPS anfasst oder reproduzierbar sein soll, muss Bash/POSIX sein. Der VPS hat kein Fish; Fish-Skripte laufen dort nicht.
Fish: exzellente Ergonomie out-of-the-box, aber nicht-POSIX (set -x VAR x statt export, $status statt $?, Listen 1-indiziert). Eingefügte Bash-Befehle (aus Doku/KI-Tools) brechen gelegentlich.
Zsh: Bash-kompatibel (gleiche Sprache wie die Server) + Fish-ähnliche Plugins (zsh-autosuggestions, zsh-syntax-highlighting) → bester Kompromiss für server-zentriertes Arbeiten.
Bash + ble.sh / atuin / fzf: maximal gängig, fast gleicher Komfort.

Pro Gerät ein eigenes Keypair → ein Gerät verloren/kompromittiert = nur dessen Public Key vom Server entfernen, Rest bleibt unberührt.
ed25519 als moderner Standard.
Public Keys wandern auf den VPS, Private Keys bleiben lokal.

„VPN" zum Erreichen des eigenen Desktops = Mesh / Self-Hosted (WireGuard, Tailscale, Netbird) — nicht ein kommerzielles Privacy-VPN (das macht das Gegenteil).
Passt zur Eigen-Server-/Datenschutz-Philosophie.

Der VPS soll mehrere Apps parallel hosten. Zu entscheidende Achsen:

Isolation: Container (Docker/Podman) vs. systemd-Services + venvs.
Reverse Proxy: Caddy (Auto-HTTPS, simpel) vs. Nginx vs. Traefik.
Domains/Subdomains-Organisation.
Backup-Strategie für die Zukunft (automatisiert).
Hardening: SSH key-only, Fail2ban sinnvoll konfigurieren, Firewall — und die IONOS-Web-Konsole bewusst als Recovery-Weg behalten, um erneutes Aussperren zu vermeiden.