59 lines
4.2 KiB
Markdown
59 lines
4.2 KiB
Markdown
# 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.
|