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

Wer in einem KMU oder Homelab mehrere Linux-Server, Windows-Maschinen und Datenbankinstanzen verwaltet, kennt das Problem: SSH-Keys sind verstreut, RDP-Passwörter liegen in Textdateien, niemand weiß genau, wer wann welchen Server betreten hat. JumpServer löst dieses Problem, indem es als zentraler Bastion-Host alle Verbindungen – SSH, RDP, VNC, Telnet, Kubernetes und Datenbankprotokolle – über einen einzigen Web-Proxy führt. Administratoren arbeiten im Browser, sehen nie ein Klartext-Passwort, und jede Session wird vollständig aufgezeichnet. Die Community Edition ist kostenlos unter GPLv3 lizenziert und lässt sich per Docker-All-in-One-Image in wenigen Minuten starten. Diese Anleitung zeigt den Weg vom leeren Linux-Server bis zur ersten gesicherten RDP-Verbindung – inklusive der Fallstricke, über die man bei einem zentralen Zugangstor unbedingt Bescheid wissen sollte.

Voraussetzungen

1. Linux-Server (Ubuntu 20.04/22.04 LTS oder RHEL/CentOS 8+, 64-bit, Kernel >= 4.0) – dedizierte VM oder VPS empfohlen
2. Mindestressourcen: 4 CPU-Kerne, 8 GB RAM, 20 GB Systemspeicher; für Produktivbetrieb besser 8 Kerne / 16 GB RAM
3. Dediziertes Volume für Session-Recordings – Aufzeichnungen können schnell viel Platz belegen
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 für den One-Liner-Installer (alternativ: Offline-Tar-Paket von GitHub Releases)
7. Firewall-Regeln vorbereiten: Ports 80/443 (Web-UI) und 2222 (SSH-Proxy) – idealerweise nur aus einem VPN oder internen Netz erreichbar
8. Optional: DNS-Eintrag oder statische IP, Reverse Proxy (nginx, Caddy) für HTTPS

Schritt 1: JumpServer-Architektur verstehen

Bevor der erste Befehl ausgeführt wird, lohnt ein kurzer Blick auf die interne Struktur. JumpServer ist kein monolithisches Binary, sondern besteht aus mehreren spezialisierten Komponenten, die der Installer gemeinsam als Container betreibt:

1. Lina – das Vue.js-Web-Frontend, über das Administratoren Assets, Benutzer und Berechtigungen verwalten
2. Luna – das Web-Terminal-Frontend für SSH/Telnet-Sessions direkt im Browser
3. KoKo – der Zeichenprotokoll-Connector für SSH, Telnet und Kubernetes; schreibt das Kommandoprotokoll
4. Lion – der grafische Connector für RDP und VNC, basierend auf Apache Guacamole und FreeRDP; streamt den Desktop als HTML5 in den Browser
5. Magnus – der Datenbank-Proxy für MySQL, MariaDB, PostgreSQL, Oracle und Redis; leitet Verbindungen von lokalen Datenbankclients durch JumpServer
6. Core – das Django-Backend mit API, RBAC-Engine, Credential-Vault und Audit-Log

Endnutzer melden sich ausschließlich am Web-UI an. Sie sehen die Assets, für die sie berechtigt sind, klicken auf „Verbinden" und erhalten einen Terminal oder einen RDP-Desktop im Browser – ohne je ein Passwort zu Gesicht zu bekommen. JumpServer authentifiziert sich intern mit den im Credential-Vault gespeicherten Zugangsdaten.

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

Der offizielle Installer lädt alle benötigten Container-Images und legt eine saubere, wartbare Verzeichnisstruktur unter /opt/jumpserver an. Er fragt interaktiv nach dem Installations-Pfad und generiert automatisch zufällige Schlüssel. Das ist der empfohlene Weg für alle produktiven Deployments.

# Als root auf einem frischen Linux-Server ausführen
cd /opt
curl -sSL https://github.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash

Der Installer stellt einige Fragen (Verzeichnis, Datenbanktyp) und startet dann alle Container. Der Vorgang dauert je nach Verbindungsgeschwindigkeit fünf bis fünfzehn Minuten.

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

cd /opt/jumpserver
./jmsctl.sh status

Alle Dienste sollten als running erscheinen. Anschließend im Browser http://<SERVER-IP> aufrufen – die JumpServer-Loginseite erscheint.

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

Wer JumpServer zunächst ausprobieren möchte oder eine sehr kleine Umgebung betreibt, kann das All-in-One-Image direkt mit docker run starten. Wichtig: SECRET_KEY und BOOTSTRAP_TOKEN immer durch echte Zufallswerte ersetzen – niemals die Standardwerte verwenden.

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 16) \
  -v jsdata:/opt/data \
  -v pgdata:/var/lib/postgresql \
  -p 2222:2222 \
  -p 80:80 \
  --restart=unless-stopped \
  jumpserver/jms_all:v4.10.16

Das Image enthält alle Komponenten inklusive PostgreSQL und Redis in einem einzigen Container. Für den produktiven Einsatz mit mehreren Administratoren und vielen Assets ist der jmsctl-Installer mit separaten Containern die bessere Wahl, weil Wartung, Updates und Backups dort klarer strukturiert sind.

Verifizieren:

docker logs jms_all --tail 50

Nach etwa einer bis zwei Minuten erscheint im Log die Meldung, dass alle Dienste gestartet sind. Browser: http://<SERVER-IP>.

Schritt 4: Erster Login und sofortige Härtung

Die Standardzugangsdaten lauten admin / ChangeMe. Das ist wörtlich zu nehmen: JumpServer ist der Schlüssel zu allen verwalteten Systemen – ein kompromittiertes Admin-Konto bedeutet vollständigen Zugriff auf sämtliche Assets.

Direkt nach dem ersten Login folgende Schritte ausführen:

1. Admin-Passwort ändern: Oben rechts auf den Benutzernamen klicken → „Profile" → „Change Password"
2. MFA aktivieren: Im selben Profil-Dialog „MFA" aktivieren und mit einer TOTP-App (z. B. Aegis, Google Authenticator) einrichten
3. System Settings überprüfen: „System Settings" → „Security" – Session-Timeout, Passwortrichtlinien und erlaubte Login-IPs konfigurieren
4. HTTPS einrichten: Vor dem produktiven Betrieb einen Reverse Proxy (nginx, Caddy) vorschalten und TLS terminieren

# 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

Schritt 5: Firewall konfigurieren

JumpServer ist ein internes Werkzeug. Die Ports sollten nie direkt aus dem öffentlichen Internet erreichbar sein. Zugang idealerweise nur über VPN oder aus dem internen Netz erlauben.

# 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:
# 3389 (RDP), 6379 (Redis), 3306/5432 (Datenbank), Magnus-Ports

Die folgende Tabelle zeigt alle relevanten Ports im Überblick:

Schritt 6: Assets, Benutzer und Berechtigungen einrichten

Die eigentliche Arbeit beginnt nach dem Login. Das grundlegende Konzept in JumpServer lautet: Ein Benutzer erhält Zugriff auf ein Asset (Server, Windows-Maschine, Datenbank) über ein Systemkonto (die gespeicherten Zugangsdaten). Kein Benutzer kennt das Passwort des Systemkontos – JumpServer authentifiziert sich automatisch.

Assets anlegen

Unter „Assets" → „Assets" einen neuen Host anlegen: Hostname, IP-Adresse und Plattform (Linux/Windows) eingeben. Anschließend unter „Accounts" ein Systemkonto mit Benutzername und Passwort oder SSH-Key hinterlegen. JumpServer testet die Verbindung und meldet, ob sie erfolgreich war.

Benutzer und Rollen

Unter „Users" → „Users" Benutzerkonten anlegen und Rollen zuweisen. Die Community Edition bietet volles RBAC mit benutzerdefinierten Rollen: Man kann z. B. eine Rolle „Entwickler" erstellen, die nur auf Staging-Server zugreifen darf, und eine Rolle „DBA", die nur Datenbankverbindungen bekommt.

Berechtigungen (Permissions)

Unter „Perms" → „Asset Permissions" Regeln erstellen: Welche Benutzer oder Benutzergruppen dürfen auf welche Assets mit welchen Systemkonten zugreifen – und in welchem Zeitfenster. Hier lässt sich auch Just-in-Time-Zugriff konfigurieren: Eine Berechtigung gilt nur für eine definierte Zeitspanne und wird danach automatisch entzogen.

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 vollständig enthalten. Jede SSH-Session wird als Zeichenprotokoll aufgezeichnet (Text + Timestamps), RDP-Sessions als Video-Stream. Unter „Audits" → „Sessions" können Administratoren laufende Sessions in Echtzeit beobachten und bei Bedarf beenden. Abgeschlossene Sessions lassen sich bis auf den einzelnen Tastendruck zurückspulen.

Zusätzlich lassen sich Kommando-Filter einrichten: Unter „ACL" → „Command ACL" können gefährliche Befehle (z. B. rm -rf /, shutdown) auf einer Blacklist stehen und werden beim Ausführen blockiert oder müssen erst durch einen Administrator genehmigt werden.

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.

Schritt 8: Credential-Vault und automatische Passwortrotation

Alle in JumpServer gespeicherten Passwörter und SSH-Keys werden verschlüsselt abgelegt. Der SECRET_KEY in der Konfiguration ist der Hauptschlüssel dieser Verschlüsselung – er darf niemals verloren gehen und muss geheim bleiben. Bei einem Verlust sind alle gespeicherten Credentials unbrauchbar.

Unter „Accounts" → „Account Change Secret" lässt sich automatische Passwortrotation einrichten: JumpServer ändert das Passwort auf dem Zielsystem in konfigurierbaren Intervallen und aktualisiert den Vault automatisch. Vor der Aktivierung unbedingt testen, ob die Verbindung und der automatische Test erfolgreich sind – sonst verliert JumpServer selbst den Zugang zum Asset.

Community vs. Enterprise Edition

Für die meisten KMU-Szenarien reicht die Community Edition vollständig aus. Die folgende Tabelle zeigt, wo die Grenze liegt:

Die Enterprise Edition bietet einen 14-Tage-Trial. Wer Multi-Tenancy für mehrere Mandanten oder automatisierten Cloud-Asset-Import braucht, sollte ihn nutzen. Für ein KMU mit einer einzigen Organisation und definierten Teams deckt die Community Edition alle wesentlichen PAM-Anforderungen ab.

Troubleshooting / Typische Fehler

Container starten nicht – „Port already in use"

Port 80 oder 2222 ist bereits belegt. Prüfen mit ss -tlnp | grep ':80\|:2222'. Entweder den kollidierenden Dienst stoppen oder in der config.txt andere Ports über HTTP_PORT und SSH_PORT konfigurieren.

SSH-Verbindung zu einem Asset schlägt fehl

Unter „Assets" → Asset auswählen → „Test Connectivity" ausführen. JumpServer zeigt den genauen Fehler (Timeout, Auth-Fehler, falscher Port). Häufige Ursache: Der JumpServer-Host hat keine Netzwerkverbindung zum Asset (Firewall zwischen den Hosts). JumpServer muss das Asset direkt erreichen können – Endnutzer hingegen brauchen nur Zugang zu JumpServer.

RDP im Browser bleibt schwarz oder lädt ewig

Der Lion-Container benötigt Zugriff auf Port 3389 des Windows-Assets. Firewall-Regeln auf dem Windows-Host prüfen. Außerdem: NLA (Network Level Authentication) muss auf dem Windows-Host aktiviert sein und JumpServer muss gültige Credentials haben.

SECRET_KEY nach Installation verloren

Unter /opt/jumpserver/config/config.txt (jmsctl-Installation) oder als Docker-Umgebungsvariable gespeichert. Den Wert sofort sichern – ohne ihn sind alle gespeicherten Credentials nicht mehr entschlüsselbar. Ein Verlust erfordert eine Neuinstallation und das manuelle Neueintragen aller Zugangsdaten.

Performance-Engpässe bei vielen gleichzeitigen Sessions

Vor allem RDP-Video-Recording ist CPU- und RAM-intensiv. Unter 4 CPU / 8 GB RAM treten bei mehr als zehn gleichzeitigen RDP-Sessions spürbare Verzögerungen auf. Für Umgebungen mit > 50 parallelen Sessions mindestens 8 Kerne und 16 GB RAM einplanen.

LDAP-Integration: Notfallzugang verloren

Wenn SSO über LDAP/AD konfiguriert ist und der LDAP-Server ausfällt, müssen lokale Admin-Konten als Notfall-Fallback aktiv bleiben. Unter „System Settings" → „Auth" sicherstellen, dass lokale Authentifizierung nicht deaktiviert ist.

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. JumpServer hat einen „Account Push"-Mechanismus und kann Konten auf Assets automatisch entdecken und einsammeln. SSH-Keys und Passwörter können direkt im Credential-Vault hinterlegt werden, ohne dass Endnutzer sie je zu sehen bekommen.

Wie funktioniert RDP über den Web-Browser genau?

Der Lion-Connector baut intern eine echte RDP-Verbindung zur Windows-Maschine auf und streamt den Desktop als HTML5 in den Browser. Der Endnutzer sieht keinen RDP-Client, erhält keine Zugangsdaten und braucht keine Software zu installieren. JumpServer authentifiziert sich mit dem hinterlegten Konto aus dem Credential-Vault.

Ist die Community Edition wirklich kostenlos ohne versteckte Grenzen?

Ja – die Community Edition ist vollständig kostenlos unter GPLv3. Es gibt keine künstliche Begrenzung bei der Anzahl der Assets, Benutzer oder Sessions. Die Enterprise Edition ergänzt hauptsächlich Cloud-Sync, Ticket-Workflows und Multi-Tenancy – Features, die für ein einzelnes KMU selten zwingend notwendig sind.

Wie sichere ich JumpServer selbst ab?

Mindestempfehlung: Server hinter VPN oder Firewall betreiben, HTTPS mit gültigem Zertifikat über einen Reverse Proxy erzwingen, MFA für alle Admin-Konten aktivieren, regelmäßige Backups der VOLUME_DIR und der PostgreSQL-Datenbank einrichten, und Logs an ein SIEM exportieren. Vor Updates immer ein vollständiges Backup erstellen – Datenbankschema-Migrationen sind nicht immer rückwärtskompatibel.

Funktioniert JumpServer auf ARM-Servern?

Die Community Edition (Offline-Tar-Paket) unterstützt nur linux/amd64. ARM- oder andere Architekturen erfordern die Enterprise Edition oder eigene Container-Builds. Das Docker-All-in-One-Image ist ebenfalls primär für amd64 ausgelegt.

Fazit

JumpServer ist eine der vollständigsten Open-Source-PAM-Lösungen auf dem Markt. Mit über 30.000 GitHub-Sternen, einer aktiven Community und mehr als 500.000 Deployments weltweit ist es keine experimentelle Software mehr, sondern ein produktionsreifer Bastion-Host für ernsthafte Umgebungen. Die Community Edition deckt mit Session-Recording, RBAC, Credential-Vault und JIT-Berechtigungen alle wesentlichen PAM-Anforderungen ab – ohne Lizenzkosten.

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 mit kommerziellen PAM-Lösungen im vier- bis fünfstelligen Bereich 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 Official Documentation – Quick Start (docs.jumpserver.org)
6. JumpServer GitHub Repository (v4.10.16-lts)