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

## Getroffene Entscheidungen
- **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).

---

## Lernhinweise

### SSH-Diagnose
- **„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.

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

### Backup-Philosophie
- 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.

### Shell: interaktiv vs. Skript (die wichtigste Einsicht)
- 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.

### SSH-Key-Architektur
- **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 für LLM-Zugriff
- „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.

---

## Offene Designfrage: Multi-App-Struktur (noch nicht besprochen)
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.