Meine Entwicklungsumgebung: ein Server ohne offene Ports

Ich entwickle nicht auf meinem Laptop. Gearbeitet wird auf einem kleinen Cloud-Server mit Ubuntu, und Laptop, Tablet und Smartphone sind nur Fenster dorthin. Projekte, Terminals und laufende Programme bleiben auf dem Server. Ich kann den Laptop also an einem Ort zuklappen und an einem anderen Gerät genau dort weitermachen, wo ich aufgehört habe.

Auf so einem Server liegen Code, Zugangstokens und alles, was zum Deployen nötig ist. Deshalb folgt die Einrichtung einer einzigen Idee: Aus dem offenen Internet ist er gar nicht erst zu sehen. Hier steht, wie das Schicht für Schicht aussieht. Am Ende findest du einen Prompt zum Kopieren, mit dem dich ein Assistent durch dasselbe Setup auf deinem eigenen Server führt.

1. Das Netz: nur privat

Der Server hängt in einem privaten Netz, aufgebaut mit Tailscale. Jedes Gerät, von dem aus ich arbeite, ist in diesem Netz und erreicht den Server über eine verschlüsselte Verbindung, egal wo es gerade ist. Für alle anderen gibt es dort nichts, womit sie reden könnten.

• Die Firewall (ufw) weist alles ab, was aus dem Internet kommt, und lässt nur Verkehr durch, der über das private Netz ankommt.
• Die Firewall des Hosting-Anbieters vor dem Server hat ebenfalls keine eingehenden Regeln. Selbst ein Fehler auf dem Server würde also keine Tür öffnen.
• Überhaupt keine offenen Ports. Kein SSH, kein Webserver, nichts lauscht auf der öffentlichen Adresse. Ein Port, den es nicht gibt, lässt sich nicht angreifen, egal welche Sicherheitslücke als Nächstes auftaucht.
• Nur Geräte, die wirklich genutzt werden, bleiben im privaten Netz, denn jedes Gerät darin kann den Server erreichen.

2. SSH: nur Schlüssel, nur private Adresse

SSH gibt es weiterhin für die Momente, in denen es gebraucht wird, aber gut abgeschlossen:

• Es lauscht nur auf der Adresse im privaten Netz, nicht auf der öffentlichen.
• Passwörter sind aus. Rein kommt man nur mit Schlüssel, und Root kann sich gar nicht anmelden.
• X11- und TCP-Forwarding sind aus, damit ein gestohlener Login nicht zum Tunnel woandershin wird.
• Auf der Tailscale-Seite verlangt SSH regelmäßig eine frische Bestätigung des Logins.

3. Terminals: Sessions, die weiterlaufen

Im Alltag nutze ich kein nacktes SSH, sondern Rex, einen Terminal-Multiplexer. Er hält meine Sessions, Tabs und Panes auf dem Server. Verbinde ich mich von einem anderen Gerät, ist alles noch da: der laufende Build, der offene Editor, der Verlauf.

Rex läuft als Login-Server: Ein kleiner Dienst auf dem Server prüft, wer sich verbindet, und startet die Session unter dem eigenen Linux-Konto dieser Person. Auch er ist nur über das private Netz erreichbar, per Tailscale Serve, und nur meine eigene Tailscale-Identität kommt rein.

Warum ein Multiplexer das Herzstück dieses Setups ist und wie ich damit von iPhone und iPad aus arbeite, steht in Terminal-Multiplexer.

4. Updates: immer die neueste stabile Version

Gerade auf einem Entwicklungsserver sollten sich keine alten Versionen ansammeln:

• Sicherheitsupdates installieren sich selbst, jeden Tag (unattended-upgrades).
• Alles andere bleibt auf dem neuesten stabilen Release: die Systempakete, Node.js und npm, Bun und der Terminal-Server, jeweils aus der offiziellen Paketquelle.
• Nach Updates prüfe ich, welche Programme noch die alte Version ausführen, und starte sie neu. Ein Update schützt erst, wenn der neue Code auch wirklich läuft.
• Was niemand nutzt, ist aus. Ein Beispiel ist Multipath TCP, eine Kernel-Funktion für Geräte mit mehreren Verbindungen gleichzeitig, etwa ein Smartphone mit WLAN und Mobilfunk. Ein Server im Rechenzentrum hat eine Verbindung und hat nichts davon. Abgeschaltet fällt Code weg, in dem irgendwann eine Lücke stecken könnte.

5. GitHub und Deploys: enge Zugänge

Der Server spricht mit GitHub über einen Fine-grained Token, der nur die Repositories erreicht, an denen ich dort arbeite. Git läuft über HTTPS mit diesem Token, nicht mit einem breiten Schlüssel, der alles öffnet.

Deployt wird gar nicht vom Server aus: Cloudflare ist mit dem GitHub-Repository verbunden und veröffentlicht diese Seite, sobald etwas auf main landet. Der Server braucht also nie Zugangsdaten für die Live-Seite.

6. Selbst aufsetzen: ein Prompt zum Kopieren

Ein KI-Assistent mit Zugriff auf das Terminal deines Servers kann dich durch dasselbe Setup führen. Kopiere diesen Prompt, fülle aus, was in eckigen Klammern steht, und füge ihn ein. Er erklärt jeden Schritt, bevor er ihn ausführt, und sperrt dich unterwegs nicht aus.

Du hilfst mir, einen sicheren Entwicklungsserver einzurichten. Ich bin
per SSH auf einem frischen Ubuntu-Server (Version: [z. B. 24.04]) bei
einem Cloud-Anbieter ([Name des Anbieters]) angemeldet. Mein
Linux-Benutzer ist [Benutzername] und hat sudo.

Ziel: ein Server OHNE offene Ports. Ich erreiche ihn nur über ein
privates Tailscale-Netz, von diesen Geräten: [Laptop/Smartphone/Tablet].

Geh die Schritte unten einzeln durch. Für jeden Schritt:
- erkläre in einfachen Worten, was er macht und warum,
- zeig mir die genauen Befehle, bevor du sie ausführst,
- warte auf mein OK,
- prüfe danach, ob es geklappt hat.
Tu nichts, was mich aussperren könnte, bevor wir bestätigt haben, dass
der Zugang über Tailscale funktioniert. Schlägt ein Schritt fehl,
halte an und erkläre, was passiert ist.

1. System aktualisieren und automatische Sicherheitsupdates
   (unattended-upgrades) einschalten.
2. Tailscale installieren, meinem Tailnet beitreten und prüfen, dass
   ich den Server von einem anderen Gerät über seine
   Tailscale-Adresse erreiche.
3. SSH absichern: nur auf den Tailscale-Adressen lauschen, nur
   Schlüssel, keine Passwörter, kein Root-Login, kein X11- und kein
   TCP-Forwarding. Meine aktuelle Session bleibt offen, während wir
   einen zweiten Login testen.
4. Firewall (ufw) einrichten: eingehenden Verkehr standardmäßig
   ablehnen, alles auf dem Interface tailscale0 erlauben. Danach zeigen,
   dass nichts auf der öffentlichen Adresse lauscht (ss -tulpn).
5. Erklären, wie ich die Firewall meines Cloud-Anbieters auf keine
   eingehenden Regeln stelle.
6. Optional Tailscale SSH mit Check-Modus einschalten.
7. Den Terminal-Multiplexer Rex installieren, damit meine Sessions
   Verbindungsabbrüche überleben: Rex als Login-Server, nur über
   Tailscale Serve erreichbar, und nur meine eigene
   Tailscale-Identität kommt rein.
8. Meine Entwicklungswerkzeuge aus den offiziellen Quellen in der
   neuesten stabilen Version installieren: [z. B. git, Node.js, Bun,
   GitHub CLI].
9. GitHub-Zugang mit einem Fine-grained Token einrichten, beschränkt
   auf die Repositories, die ich brauche, mit git über HTTPS.
10. Kernel-Funktionen abschalten, die ein Server nicht braucht,
    angefangen mit Multipath TCP (net.mptcp.enabled = 0, gespeichert
    in /etc/sysctl.d/).
11. Zum Schluss eine kurze Checkliste, was eingerichtet ist, und die
    Befehle, mit denen ich später prüfen kann, ob alles aktuell ist.

Jedes Setup ist ein bisschen anders: ein anderer Anbieter, andere Werkzeuge, mehr Leute, die Zugriff brauchen. Wenn du Hilfe beim Aufsetzen einer solchen Entwicklungsumgebung für dein Team möchtest, melde dich.