JumpServer 5 selbst hosten: Bastion-Host und Privileged Access Management mit Docker

Verstreute SSH-Keys, RDP-Passwörter in Textdateien, keine Übersicht, wer wann welchen Server betreten hat: JumpServer führt als zentraler Bastion-Host alle Verbindungen (SSH, RDP, VNC, Telnet, Kubernetes, Datenbankprotokolle) über einen Web-Proxy. Administratoren arbeiten im Browser, sehen nie ein Klartext-Passwort, jede Session wird aufgezeichnet. Die Community Edition (GPLv3) startet per Docker in wenigen Minuten. Seit September 2026 ist Version 5 aktuell; diese Anleitung beschreibt v5.1.0 und zeigt am Ende den Umstieg von v4 sowie das Update von v5.0. Diese Anleitung führt vom leeren Linux-Server bis zur ersten gesicherten RDP-Verbindung, inklusive der Fallstricke eines zentralen Zugangstors.

Voraussetzungen

1. Linux-Server (z. B. Ubuntu 22.04/24.04 LTS, Debian 12 oder RHEL-kompatibel 8+, x86_64, Kernel >= 4.0), dedizierte VM oder VPS empfohlen. Die Images der Community Edition v5.1.0 gibt es nur für amd64 (geprüft am 17.10.2026), ARM-Server bleiben vorerst bei v4.10.
2. Mindestens 4 CPU-Kerne und 8 GB RAM, laut Herstellerdoku 100 GB Speicher; produktiv besser 8 Kerne / 16 GB RAM. Allein das All-in-One-Image v5.0.0 belegte entpackt rund 4,2 GB.
3. Dediziertes Volume für Session-Recordings (wachsen schnell)
4. Docker Engine (aktuelle stabile Version) auf dem Server installiert, Schritt für Schritt in der Anleitung Docker und Docker Compose auf Linux installieren
5. Root-Zugang oder sudo-Rechte auf dem Server
6. Internetzugang zu github.com und ghcr.io für Installer und Images (alternativ Offline-Tar-Paket von GitHub Releases)
7. Externe Datenbank optional: PostgreSQL ab 16 oder MySQL ab 8.0 sowie Redis ab 7.0; ohne Angabe richtet der Installer PostgreSQL 16 und Redis 7.4 als Container ein
8. Firewall: Ports 80/443 (Web-UI) und 2222 (SSH-Proxy), idealerweise nur aus VPN oder internem Netz
9. Optional: DNS-Eintrag oder statische IP, Reverse Proxy (nginx, Caddy) für HTTPS

Schritt 1: JumpServer-Architektur verstehen

JumpServer besteht aus mehreren Komponenten, die der Installer als Container betreibt. In v5 hat sich die Aufteilung geändert: Der eigene RDP-Container Lion entfällt, grafische Sitzungen laufen jetzt über KoKo.

1. Web (Container jms_web): nginx mit Lina (Verwaltungsoberfläche) und Luna (Web-Terminal)
2. Core und Celery: Django-Backend mit API, RBAC-Engine, Credential-Vault, Audit-Log und Hintergrundaufgaben
3. KoKo: Connector für SSH, Telnet und Kubernetes und seit v5 auch für RDP und VNC im Browser (Guacamole-Dienst im KoKo-Image, früher Lion); schreibt Kommandoprotokoll und Aufzeichnungen
4. Chen: Web-Datenbankclient der Community Edition
5. Kael: neu in v5, KI-Dienst für Befehlsvorschläge, Risikohinweise und Audit-Berichte; das Sprachmodell konfigurieren Sie selbst in Core
6. Nur Enterprise: Magnus (Datenbank-Proxy für lokale Clients), Razor (RDP-Proxy für native Clients), NEC (VNC-Proxy), XRDP und Video-Worker

Endnutzer melden sich nur am Web-UI an, sehen ihre berechtigten Assets und erhalten per „Verbinden“ Terminal oder RDP-Desktop im Browser, ohne je ein Passwort zu sehen; JumpServer nutzt intern die Zugangsdaten aus dem Credential-Vault.

Verifizieren: Der geplante Server erfüllt die Mindestanforderungen: uname -m liefert x86_64, nproc mindestens 4, free -g mindestens 8 GB Gesamtspeicher und df -h / mindestens 20 GB frei.

Schritt 2: One-Liner-Installation (empfohlener Weg)

Der offizielle Installer lädt alle Images, legt die Struktur unter /opt/jumpserver an, fragt den Installations-Pfad ab und erzeugt Zufallsschlüssel. Empfohlen für alle produktiven Deployments.

Wichtig für v5: Der Installer sucht die Images standardmäßig als jumpserver/core:v5.1.0-ce auf Docker Hub. Zum Start von v5.0 fehlten die CE-Images von Core, KoKo, Chen und Web dort (Stand 04.10.2026), am 17.10.2026 lagen sie für v5.0.0 und v5.1.0 sowohl auf Docker Hub als auch unter ghcr.io/jumpserver. Die Zeile mit IMAGE_PULL_PREFIX ist damit optional: Sie holt die Images aus der GitHub Container Registry und benennt sie lokal um.

# Als root auf einem frischen x86-Server ausführen (Version fest auf v5.1.0)
cd /opt
export IMAGE_PULL_PREFIX=ghcr.io/jumpserver
curl -sSL https://github.com/jumpserver/jumpserver/releases/download/v5.1.0/quick_start.sh | bash
# Für spätere Updates dauerhaft festhalten
echo 'IMAGE_PULL_PREFIX=ghcr.io/jumpserver' >> /opt/jumpserver/config/config.txt

Nach einigen Fragen (Verzeichnis, Datenbank, Ports, Sprache, Zeitzone) startet er alle Container, je nach Verbindung in fünf bis fünfzehn Minuten. Die Angaben zu IMAGE_PULL_PREFIX sind im Quelltext der Installer v5.0.0 und v5.1.0 und per Registry-Abfrage geprüft.

Verifizieren: Nach Abschluss des Installers den Status prüfen:

cd /opt/jumpserver-installer-v5.1.0
./jmsctl.sh status

Alle Dienste (core, celery, kael, koko, chen, web, postgresql, redis) sollten running bzw. healthy zeigen, docker images | grep v5.1.0-ce listet die umbenannten Images; unter http://<SERVER-IP> erscheint die Loginseite.

Schritt 3: Docker All-in-One (für Tests und kleine Umgebungen)

Zum Ausprobieren oder für sehr kleine Umgebungen startet das All-in-One-Image per docker run. Wichtig: SECRET_KEY und BOOTSTRAP_TOKEN immer durch echte Zufallswerte ersetzen.

docker run --name jms_all \
  -e SECRET_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | head -c 50) \
  -e BOOTSTRAP_TOKEN=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | head -c 24) \
  -v jsdata:/opt/data \
  -v pgdata:/var/lib/postgresql \
  -p 2222:2222 \
  -p 80:80 \
  --restart=unless-stopped \
  jumpserver/jms_all:v5.1.0

Das Image enthält alle Komponenten inklusive PostgreSQL und Redis in einem Container und liegt weiterhin auf Docker Hub, in v5.1.0 aber nur für amd64. Notieren Sie SECRET_KEY und BOOTSTRAP_TOKEN: Kael leitet seinen Signaturschlüssel aus dem BOOTSTRAP_TOKEN ab, bei einem Neustart mit neuen Zufallswerten sind verschlüsselte Daten und Komponenten-Registrierung unbrauchbar. Produktiv mit mehreren Admins und vielen Assets ist der jmsctl-Installer besser, weil Wartung, Updates und Backups klarer strukturiert sind.

Verifizieren:

docker logs jms_all --tail 50

Im Test am 04.10.2026 (2 vCPU, 3 GB RAM) lieferte curl -s http://localhost/api/health/ nach rund 80 Sekunden "status":true mit Datenbank und Redis, Loginseite und Oberfläche antworteten mit HTTP 200. Der Container belegte dabei 1,8 bis 2,3 GB RAM bei Volllast beider Kerne, Kael startete einmal neu, weil Core zu langsam antwortete. Für mehr als einen Test planen Sie deshalb die 8 GB aus den Voraussetzungen ein. Browser: http://<SERVER-IP>.

Schritt 4: Erster Login und sofortige Härtung

Standardzugang: admin / ChangeMe. JumpServer ist der Schlüssel zu allen verwalteten Systemen; ein kompromittiertes Admin-Konto bedeutet Zugriff auf sämtliche Assets.

Direkt nach dem ersten Login:

1. Admin-Passwort ändern: Benutzername oben rechts → „Profile“ → „Change Password“
2. MFA aktivieren: im Profil „MFA“ mit TOTP-App (z. B. Aegis, Google Authenticator)
3. System Settings: „System Settings“ → „Security“: Session-Timeout, Passwortrichtlinien, erlaubte Login-IPs
4. HTTPS: vor Produktivbetrieb Reverse Proxy (nginx, Caddy) mit TLS vorschalten

# Wichtige Konfigurationsvariablen in config.txt (bei jmsctl-Installation)
# Datei liegt unter /opt/jumpserver/config/config.txt

SECRET_KEY=<zufällig, min. 50 Zeichen, NIEMALS teilen>
BOOTSTRAP_TOKEN=<zufällig, 16 Zeichen>
HTTP_PORT=80
VOLUME_DIR=/data/jumpserver
LOG_LEVEL=ERROR

Verifizieren: Die Anmeldung mit admin / ChangeMe schlägt fehl, die Anmeldung mit dem neuen Passwort fragt zusätzlich den TOTP-Code ab, und im Profil steht MFA als aktiviert.

Schritt 5: Firewall konfigurieren

Die Ports nie direkt aus dem Internet erreichbar machen; Zugang nur über VPN oder internes Netz.

# UFW-Beispiel: nur nötige Ports öffnen
ufw allow 80/tcp    # Web-UI HTTP (später durch HTTPS ersetzen)
ufw allow 443/tcp   # Web-UI HTTPS
ufw allow 2222/tcp  # SSH-Client-Zugriff via JumpServer
# Interne Ports NICHT nach außen öffnen:
# 6379 (Redis), 3306/5432 (Datenbank), 5001 (KoKo-Web-Proxy)

Relevante Ports:

Verifizieren: sudo ufw status listet nur 80, 443 und 2222 als erlaubt (dazu Ihren SSH-Port), und von einem Rechner außerhalb des erlaubten Netzes liefert nc -zv SERVER-IP 6379 keine Verbindung.

Schritt 6: Assets, Benutzer und Berechtigungen einrichten

Grundkonzept: Ein Benutzer erhält Zugriff auf ein Asset (Server, Windows-Maschine, Datenbank) über ein Systemkonto (gespeicherte Zugangsdaten), dessen Passwort er nie kennt.

Assets anlegen

Unter „Assets“ → „Assets“ Host anlegen (Hostname, IP, Plattform Linux/Windows), dann unter „Accounts“ ein Systemkonto mit Passwort oder SSH-Key hinterlegen. JumpServer testet die Verbindung.

Benutzer und Rollen

Unter „Users“ → „Users“ Konten anlegen und Rollen zuweisen. Die Community Edition bietet volles RBAC mit eigenen Rollen, z. B. „Entwickler“ nur für Staging-Server oder „DBA“ nur für Datenbankverbindungen.

Berechtigungen (Permissions)

Unter „Perms“ → „Asset Permissions“ festlegen, welche Benutzer oder Gruppen mit welchen Systemkonten in welchem Zeitfenster auf welche Assets zugreifen. Just-in-Time-Zugriff: Berechtigungen gelten nur für eine definierte Zeitspanne und verfallen dann automatisch.

Verifizieren: Als normaler Benutzer (nicht admin) einloggen und die Liste der verfügbaren Assets prüfen: Es sollten nur die explizit berechtigten Assets erscheinen.

Schritt 7: Session-Recording und ACL-Granularität

Session-Recording ist in der Community Edition enthalten: SSH als Zeichenprotokoll (Text + Timestamps), RDP als Video. Unter „Audits“ → „Sessions“ lassen sich laufende Sessions live beobachten und beenden, abgeschlossene bis auf den einzelnen Tastendruck zurückspulen.

Kommando-Filter unter „ACL“ → „Command ACL“: Gefährliche Befehle (z. B. rm -rf /, shutdown) werden blockiert oder erfordern eine Admin-Genehmigung.

Ein Hinweis zur Kapazitätsplanung: Video-Aufzeichnungen von RDP-Sessions können pro Stunde mehrere Gigabyte belegen. Das VOLUME_DIR auf ein dediziertes Volume mit ausreichend Platz legen und Monitoring für den Füllstand einrichten, etwa mit Beszel Server Monitoring.

Verifizieren: Nach einer kurzen Test-Session auf ein Linux-Asset erscheint sie unter „Audits“ → „Sessions“ mit Wiedergabe-Knopf, und ein Befehl aus der Command ACL (z. B. shutdown) wird in der Session blockiert.

Schritt 8: Credential-Vault und automatische Passwortrotation

Gespeicherte Passwörter und SSH-Keys liegen verschlüsselt. Der SECRET_KEY ist der Hauptschlüssel: geheim halten und nie verlieren, sonst sind alle gespeicherten Credentials unbrauchbar.

Unter „Accounts“ → „Account Change Secret“ rotiert JumpServer Passwörter auf Zielsystemen in Intervallen und aktualisiert den Vault. Vorher unbedingt Verbindung und automatischen Test prüfen, sonst verliert JumpServer selbst den Zugang zum Asset.

Verifizieren: Der SECRET_KEY liegt als Kopie außerhalb des Servers (z. B. im Passwortmanager), und nach einem manuellen Rotationslauf für ein Testkonto meldet „Test Connectivity“ für das betroffene Asset weiterhin Erfolg.

Update bestehender Installationen von v4 auf v5

v5.0.0 ist ein Major-Release mit geändertem Komponentenschnitt. Planen Sie ein Wartungsfenster ein, ein Rückweg ist nur über die Datensicherung möglich.

1. Ausgangsversion prüfen: Der Installer verlangt (in v5.0.0 und v5.1.0) mindestens v3.10.11. Installationen auf v3 heben Sie laut Herstellerdoku zuerst auf die letzte v3.10.x-Version.
2. Sichern: ./jmsctl.sh backup_db im alten Installer-Verzeichnis, dazu /opt/jumpserver/config/config.txt (enthält SECRET_KEY und BOOTSTRAP_TOKEN) und das VOLUME_DIR mit den Aufzeichnungen.
3. Architektur: Die CE-Images von v5 gibt es nur für amd64. ARM-Installationen bleiben bei v4.10.
4. Lion entfällt: Das Upgrade entfernt den Container jms_lion (in der Community Edition auch jms_xrdp), RDP und VNC laufen danach über KoKo. Testen Sie nach dem Update eine RDP-Verbindung.
5. Neu: Kael (KI-Dienst) mit eigenem Schlüssel CHAT_AI_DELEGATION_SECRET, den das Upgrade einmalig erzeugt.

cd /opt
wget https://github.com/jumpserver/installer/releases/download/v5.1.0/jumpserver-installer-v5.1.0.tar.gz
tar -xf jumpserver-installer-v5.1.0.tar.gz
cd jumpserver-installer-v5.1.0
# Optional: CE-Images aus der GitHub Container Registry statt Docker Hub
grep -q '^IMAGE_PULL_PREFIX=' /opt/jumpserver/config/config.txt || echo 'IMAGE_PULL_PREFIX=ghcr.io/jumpserver' >> /opt/jumpserver/config/config.txt
./jmsctl.sh upgrade
./jmsctl.sh start

Das Upgrade sichert Konfiguration und Datenbank, lädt die Images, migriert das Datenbankschema und räumt alte Images auf. Beim All-in-One-Container tauschen Sie nur den Tag gegen v5.1.0 und starten mit denselben Volumes sowie unverändertem SECRET_KEY und BOOTSTRAP_TOKEN. Noch nicht hochgeladene RDP-Aufzeichnungen unter /opt/data/lion übernimmt v5 laut Projekt nicht automatisch; sichern Sie sie vorher.

Getestet am 04.10.2026 haben wir den All-in-One-Weg: jms_all:v4.10.19 starten, Container ersetzen durch jms_all:v5.0.0 mit denselben Volumes. Die Migration lief ohne Eingriff, der Health-Endpunkt meldete Datenbank und Redis als erreichbar, Loginseite und Oberfläche lieferten HTTP 200.

Das Update von v5.0.0 auf v5.1.0 haben wir am 17.10.2026 ebenfalls mit dem All-in-One-Image getestet: Unter v5.0.0 ein zusätzliches Benutzerkonto angelegt, dann den Container mit denselben Volumes, SECRET_KEY und BOOTSTRAP_TOKEN durch jms_all:v5.1.0 ersetzt. Beim Start liefen die Migrationen automatisch durch (in django_migrations von 190 auf 205 Einträge), das Konto war danach vorhanden, sein Passwort wurde weiter akzeptiert, ein falsches abgewiesen, const.py meldete VERSION = 'v5.1.0', und der Health-Endpunkt zeigte Datenbank und Redis als erreichbar. Version 5.1.0 überarbeitet unter anderem die Terminal-Oberfläche von KoKo für SSH-Clients, ergänzt PowerShell über WinRM, ersetzt DBeaver durch DBX als Standard-Datenbankanwendung und aktiviert HTTPS für OpenBao standardmäßig.

Verifizieren: ./jmsctl.sh status zeigt alle Dienste als running, docker ps -a | grep jms_lion liefert nichts, und unter „Audits“ → „Sessions“ stehen die alten Aufzeichnungen weiter zur Wiedergabe bereit.

Community vs. Enterprise Edition

Für die meisten KMU reicht die Community Edition. Die Grenze:

Die Enterprise Edition hat einen 14-Tage-Trial, sinnvoll bei Bedarf an Multi-Tenancy oder automatisiertem Cloud-Asset-Import.

Troubleshooting / Typische Fehler

Container starten nicht: „Port already in use“

Port 80 oder 2222 belegt; prüfen mit ss -tlnp | grep ':80\|:2222'. Dienst stoppen oder in config.txt andere Ports über HTTP_PORT und SSH_PORT setzen.

SSH-Verbindung zu einem Asset schlägt fehl

„Assets“ → Asset → „Test Connectivity“ zeigt den genauen Fehler (Timeout, Auth, Port). Häufig fehlt die Netzwerkverbindung vom JumpServer-Host zum Asset (Firewall); JumpServer muss das Asset direkt erreichen, Endnutzer nur JumpServer.

RDP im Browser bleibt schwarz oder lädt ewig

KoKo (in v4 Lion) braucht Zugriff auf Port 3389 des Windows-Assets (Firewall auf dem Host prüfen); NLA muss aktiviert sein und JumpServer gültige Credentials haben.

SECRET_KEY nach Installation verloren

Er steht in /opt/jumpserver/config/config.txt (jmsctl) oder in der Docker-Umgebungsvariable; sofort sichern. Ohne ihn sind alle Credentials nicht entschlüsselbar, ein Verlust erfordert Neuinstallation und manuelles Neueintragen.

Performance-Engpässe bei vielen gleichzeitigen Sessions

Vor allem RDP-Video-Recording kostet CPU und RAM. Mit 4 CPU / 8 GB RAM verzögert es ab zehn gleichzeitigen RDP-Sessions spürbar; ab 50 parallelen Sessions mindestens 8 Kerne und 16 GB RAM.

LDAP-Integration: Notfallzugang verloren

Bei SSO über LDAP/AD müssen lokale Admin-Konten als Notfall-Fallback aktiv bleiben: unter „System Settings“ → „Auth“ lokale Authentifizierung nicht deaktivieren.

Häufige Fragen

Ersetzt JumpServer einen klassischen SSH-Bastion-Host vollständig?

JumpServer kann einen klassischen SSH-Jump-Host vollständig ersetzen und erweitert ihn erheblich: Web-UI, RDP, Session-Recording, RBAC und Credential-Vault sind im klassischen Bastion-Host nicht vorhanden. SSH-Hardening auf den Ziel-Servern bleibt aber trotzdem sinnvoll, als Defence-in-Depth-Maßnahme. Die Anleitung SSH-Hardening Deep-Dive: sshd_config und ssh-audit im Bestand passt dazu gut.

Kann ich bestehende SSH-Keys und Passwörter importieren?

Ja. Per „Account Push“ entdeckt und sammelt JumpServer Konten auf Assets; SSH-Keys und Passwörter landen direkt im Vault, unsichtbar für Endnutzer.

Wie funktioniert RDP über den Web-Browser genau?

KoKo baut mit dem integrierten Guacamole-Dienst eine echte RDP-Verbindung auf und streamt den Desktop als HTML5; der Nutzer braucht keinen RDP-Client und erhält keine Zugangsdaten.

Ist die Community Edition wirklich kostenlos ohne versteckte Grenzen?

Ja, GPLv3 ohne künstliche Grenzen bei Assets, Benutzern oder Sessions. Enterprise ergänzt vor allem Cloud-Sync, Ticket-Workflows und Multi-Tenancy.

Wie sichere ich JumpServer selbst ab?

Hinter VPN oder Firewall betreiben, HTTPS per Reverse Proxy, MFA für alle Admins, regelmäßige Backups von VOLUME_DIR und PostgreSQL, Logs ans SIEM. Vor Updates immer vollständiges Backup: Schema-Migrationen sind nicht immer rückwärtskompatibel.

Funktioniert JumpServer auf ARM-Servern?

Für v5 nein: Installer, CE-Images und jumpserver/jms_all:v5.1.0 gibt es nur für amd64 (Stand 17.10.2026). Auf ARM läuft weiterhin jumpserver/jms_all:v4.10.19, das Docker Hub auch für arm64 anbietet.

Fazit

JumpServer wird seit 2014 aktiv entwickelt und ist ein produktionsreifer Bastion-Host. Die Community Edition deckt mit Session-Recording, RBAC, Credential-Vault und JIT-Berechtigungen die wesentlichen PAM-Anforderungen ohne Lizenzkosten ab.

Der einzige echte Nachteil: JumpServer ist selbst ein hochprivilegiertes System. Ein unsicher konfigurierter JumpServer (Standard-Passwort, offene Ports, kein HTTPS) ist schlimmer als gar keiner. Wer die Härtungsschritte aus dieser Anleitung konsequent umsetzt (MFA, HTTPS über Reverse Proxy, Server hinter VPN, regelmäßige Backups), bekommt dafür eine Zugriffskontrolle, die in vielen Punkten mit kommerziellen PAM-Lösungen mithalten kann. Als Ergänzung zu einem gehärteten SSH-Setup rundet JumpServer einen Defence-in-Depth-Ansatz im KMU sauber ab. Die passende Grundlage dafür liefert die Anleitung VPS absichern und härten: UFW, SSH-Keys und Fail2Ban.

Weiterführende Anleitungen und Quellen

1. SSH-Hardening Deep-Dive: sshd_config, Match-Blöcke und ssh-audit für KMU-Server
2. Docker und Docker Compose auf Linux installieren (Ubuntu/Debian): die Self-Hosting-Grundlage
3. VPS absichern und härten: Anleitung mit UFW, SSH-Keys und Fail2Ban
4. Single Sign-On für den Self-Hosted-Stack: Authentik vs. Authelia mit Traefik Forward-Auth
5. JumpServer-Dokumentation: Systemvoraussetzungen (docs.fit2cloud.com)
6. JumpServer-Dokumentation: Netzwerkports
7. Release-Notes JumpServer v5.0.0 auf GitHub
8. Release-Notes JumpServer v5.1.0 auf GitHub
9. JumpServer Installer (jmsctl) auf GitHub
10. All-in-One-Image: Hinweise zu KoKo, Kael und Upgrade