Ein Befehl, eine IDE,
eine Session

Das Problem mit mehreren Rechnern

Ich entwickle auf drei verschiedenen Linux-Rechnern: einem Desktop zuhause, einem zweiten Arbeitsplatz und einem Notebook unterwegs. Alle drei laufen unter Linux Mint. Das Problem: Ich möchte überall am gleichen Projekt weiterarbeiten können — ohne Setup-Overhead, ohne offene Dateien nachzuziehen, ohne mich zu fragen, wo ich gestern aufgehört habe.

Die Lösung ist ein einzelner Befehl. Ich tippe partyplaner ins Terminal — und VSCodium öffnet sich, die richtige tmux-Session auf dem Entwicklungsserver ist aktiv, alle Dateien sind da. Egal an welchem der drei Rechner ich sitze.

Das Fundament: Proxmox und ein LXC-Container

Der Kern des Setups ist ein Proxmox-Server im lokalen Netz. Proxmox ist ein Hypervisor — ein System, das virtuelle Maschinen und Container verwaltet. Ich nutze keinen Cloud-Anbieter, kein gemietetes VPS, kein Kubernetes. Alles läuft auf eigener Hardware, unter meiner Kontrolle.

Auf diesem Proxmox-Host läuft ein einziger LXC-Container (Linux Containers) mit Debian — das ist dockerdev. Darin laufen alle meine Entwicklungsprojekte, jedes in seinem eigenen Unterordner unter /root/projects/. Der Container läuft rund um die Uhr, braucht wenig Ressourcen, ist schnell gestartet und einfach zu sichern.

SSH-Zugang einrichten: Public Key Auth

Damit der Alias-Trick reibungslos funktioniert, muss jeder Client-Rechner seinen SSH-Public-Key auf dockerdev hinterlegt haben — sonst fragt das System bei jedem Verbindungsaufbau nach einem Passwort.

Schritt 1: Key generieren (einmalig pro Client)

ssh-keygen -t ed25519 -C "mein-rechner"
# Erzeugt ~/.ssh/id_ed25519 (privat) und ~/.ssh/id_ed25519.pub (öffentlich)

Schritt 2: Public Key auf dockerdev eintragen

ssh-copy-id root@dockerdev
# Oder manuell: Inhalt von ~/.ssh/id_ed25519.pub
# in /root/.ssh/authorized_keys auf dockerdev einfügen

Schritt 3: Berechtigungen auf dockerdev korrekt setzen

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys

Diese Berechtigungen sind nicht optional — SSH verweigert den Key-Zugang, wenn authorized_keys zu offen ist.

Schritt 4: Root-Login per SSH erlauben

In /etc/ssh/sshd_config auf dockerdev:

PermitRootLogin yes
PubkeyAuthentication yes

Danach: systemctl restart sshd

Diesen Schritt führt man einmalig pro Client durch. Danach ist der Zugang passwortlos und der _proj-Alias funktioniert ohne Unterbrechung.

Der Alias-Trick: _proj und VSCodium SSH Remote

VSCodium (die Open-Source-Variante von VS Code, ohne Microsoft-Telemetrie) hat eine SSH Remote Extension. Mit ihr öffnet sich die IDE direkt im Dateisystem des Remote-Hosts — als wäre der Entwicklungsserver der lokale Rechner.

Um das bequem zu machen, habe ich eine einzige Bash-Funktion in meinen Dotfiles:

function _proj() {
    local name="$1" host="$2" path="$3"
    ssh -o ConnectTimeout=5 root@"$host" \
        "tmux new-session -A -d -s '$name' -c '$path' 2>/dev/null; true"
    codium --folder-uri "vscode-remote://ssh-remote+root@${host}${path}"
}

Und für jedes Projekt einen kurzen Alias:

function partyplaner() { _proj partyplaner dockerdev /root/projects/partyplaner; }
function wsai()        { _proj wsai        dockerdev /root/projects/wsai; }
function hermesagent() { _proj hermesagent dockerdev /root/projects/hermesagent; }

Was passiert, wenn ich partyplaner tippe:

tmux: der stille Held

Warum tmux? Ein normales SSH-Terminal stirbt, wenn die Verbindung abbricht. Mit tmux nicht.

tmux ist ein Terminal-Multiplexer: Er erzeugt Sessions, die auf dem Server weiterläufen, auch wenn der Client getrennt wird. Ein laufender Entwicklungsserver, ein offenes Log-Fenster, ein Prozess der rechnet — alles bleibt, wenn ich den Laptop zuklappe.

Das new-session -A im _proj-Befehl ist der Schlüssel:

tmux new-session -A -d -s 'partyplaner' -c '/root/projects/partyplaner'

-A bedeutet: attach if exists — hänge dich an die bestehende Session, statt eine neue zu erstellen. Das heißt: Wenn ich am zweiten Arbeitsplatz weiterarbeite, sitze ich in exakt der gleichen Session mit dem gleichen Zustand, den ich am Desktop verlassen habe.

Ein weiterer Vorteil: Ich kann von zwei Rechnern gleichzeitig in die gleiche Session schauen. Nützlich beim Debuggen — beide Bildschirme zeigen dasselbe Terminal.

Dotfiles und Gitea: alle Rechner synchron

Die _proj-Funktion und alle Projekt-Aliases leben in ~/dotfiles/bashrc_shared — einem Bash-Skript, das per Symlink als ~/.bashrc eingebunden wird. Das Dotfiles-Repo liegt auf einem eigenen Gitea-Server im lokalen Netz.

Das bedeutet: Wenn ich auf einem Rechner einen neuen Alias anlege, sind alle anderen mit zwei Befehlen auf dem Stand:

git -C ~/dotfiles pull && source ~/.bashrc

Fertig. Der neue Alias ist auf jedem Rechner verfügbar, ohne dass man irgendetwas manuell kopieren müsste. Gitea ist der einzige Ort, an dem die Aliases gepflegt werden — kein rsync, kein manuelles Verteilen. Wer keinen eigenen Gitea-Server betreibt, kann dasselbe mit GitHub oder einem anderen Git-Remote erreichen.

Neues Projekt anlegen: Claude übernimmt

Hier kommt das Setup in seiner ganzen Stärke zum Vorschein. Wenn ich ein neues Projekt anlegen will, sage ich Claude einfach:

„Lege ein neues Projekt mit dem Namen neuprojekt an."

Claude führt daraufhin automatisch alle notwendigen Schritte aus:

1. Gitea-Repo erstellen — via Gitea API
2. Git auf dockerdev initialisieren — per SSH, mit Initial Commit und Remote-Verknüpfung
3. VSCodium tmux-Integration anlegen — .vscode/settings.json mit automatischem tmux-Session-Start
4. Alias in bashrc_shared eintragen — function neuprojekt() { _proj neuprojekt dockerdev /root/projects/neuprojekt; }
5. Dotfiles committen und pushen — damit alle anderen Rechner den Alias beim nächsten git pull bekommen

Ich muss keine einzige dieser Dateien selbst anfassen. Das Konzept funktioniert, weil alle Regeln für neue Projekte in der CLAUDE.md im Dotfiles-Repo dokumentiert sind — Claude liest diese Datei und weiß genau, was zu tun ist.

Fazit: Einmal denken, überall arbeiten

Dieses Setup ist kein Luxus für Infrastruktur-Nerds. Es ist eine praktische Antwort auf eine alltägliche Frage: Wie komme ich von jedem Rechner sofort in mein Projekt, ohne Setup-Stress?

Ein LXC-Container der immer läuft. Ein tmux der die Session hält. Ein Alias der alles zusammenbringt. Gitea als Synchronisationsschicht. Claude als Assistent der neue Projekte auf Zuruf anlegt. Kein Cloud-Anbieter, keine monatliche Rechnung, keine Daten bei Dritten.

Einmal aufgesetzt, ist es unsichtbar. Und das ist genau der Punkt.