From 1.0 to 3.0: The Evolution and Architecture of Jumpserver Bastion Host

Preface

If you haven’t explored Jumpserver before, you can visit the following links:

Open‑source Bastion Host Jumpserver Official Release V3.0

Official website:

<code>http://jumpserver.org</code>

GitHub repository:

<code>https://github.com/ibuler/jumpserver</code>

The main topics covered in this article are:

From the beginning to the present Design ideas and structure Development experience sharing Future plans

1. Development History of Jumpserver

The core of a bastion host is the three A’s: Authentication, Authorization, and Audit. Implementing these requires a transparent gateway that forwards SSH connections, authenticates users, maps users to hosts via a database, and records input/output for audit.

Jumpserver 1.0

Released in August 2014, version 1.0 was built with Python’s

pexpect

module to create the gateway. Authentication and authorization queried a database, while

pexpect

handled the SSH connection and log recording. A simple log‑view page provided basic audit capability. Later, the unstable custom

pexpect

wrapper was replaced by

pxssh

, leading to version 1.1.

Version 1.x used LDAP for authentication because it was easy to implement with Python’s

ldap

library. The web UI was a basic Bootstrap layout.

When colleague Wang Yong (halcyon) joined, the team bought a commercial Bootstrap template to improve the UI. They also switched from

pexpect

to

paramiko

for a more stable SSH implementation, learning to use

paramiko.channel

for interactive sessions and log collection.

Jumpserver 2.0

Collaboration was done via GitCafe branches, merging on weekends. After four months of work, version 2.0 was released in April 2015. It introduced batch commands, batch authorization, real‑time log viewing, and command statistics. The UI became much more polished.

Real‑time monitoring was implemented with WebSocket. Since Django’s WebSocket support was limited, a teammate helped implement the server side with Node.js. The monitoring logic watched log files (similar to

tail -f

) and pushed updates to the browser.

Authorization still relied on LDAP groups, but the team later decided to drop LDAP in favor of a simpler installation process.

Jumpserver 3.0 – Team Growth

Version 2.0 attracted new contributors: Chen Shangwei, Yu Maojun, Liu Zheng, and Ke Lianchun. The team adopted a task‑tracking system (Tower) and weekly voice meetings in a QQ group. Modules were split, each owner responsible for a specific API, with mock data used during integration.

Despite the enthusiasm, the project faced typical open‑source challenges: uneven contributor availability, inter‑module dependencies, and occasional merge conflicts.

2. Architecture Analysis of Jumpserver 3.0

1. User Management

Beyond web‑based user CRUD, the system creates corresponding Linux users on the bastion host so that they can log in via SSH. Django’s built‑in auth is extended slightly for this purpose.

2. Asset Management (CMDB)

The goal is a lightweight CMDB: bulk add/modify assets, Excel import/export, and automatic hardware information collection via Ansible.

3. Authorization Management

Authorization maps users to hosts through groups. To avoid LDAP complexities, the team introduced “system users” (e.g., dev, op, dba) that represent common role collections. These system users are pushed to target machines (using Ansible or similar tools) with appropriate sudo privileges.

4. Log Auditing

Auditing aggregates real‑time monitoring, command statistics, file upload/download records, and batch command logs. Real‑time monitoring uses WebSocket to push log changes to the UI, while command statistics are now derived directly from database records for higher accuracy.

5. Web Terminal

The Web Terminal is built with Tornado for WebSocket support and

term.js

on the front end. User input is forwarded to a Paramiko channel; the channel’s output is pushed back to the browser, providing an interactive SSH experience.

6. Session Recording

Recording leverages the

script

mechanism, generating log and timing files that are later rendered as animations in the browser.

7. connect.py

When a user logs into the bastion host (non‑web),

connect.py

runs (triggered by a script in

/etc/profile.d/

). It queries the Jumpserver API for authorized hosts, selects a system user, establishes the SSH session, and records all input/output to the database.

3. Development Reflections

Team Dynamics

A motivated team brings diversity and shared purpose, making the project more sustainable than solo effort.

Learning by Building

Working on a real project forces you to learn version control, documentation, testing, and time management.

Persistence

Early versions were rough and faced criticism; continuous perseverance turned the “caterpillar” into a “butterfly.”

Time Management

Project success requires disciplined time allocation among all contributors.

Balancing Features

Open‑source projects must often trade off niche features for broader usability, e.g., using Ansible or SaltStack for provisioning.

Language as a Tool

The programming language is merely a means to implement the product’s design.

4. Future Plans

1. Deepen CMDB Integration

Expand asset management into a full‑featured CMDB.

2. Improve Stability and Usability

Address design flaws and enhance user experience.

3. Support Windows and Network Devices

Develop RDP integration and broader hardware compatibility.

4. Command Whitelisting/Blacklisting

Implement advanced command filtering for security.

5. Refactor with Django Class‑Based Views and RESTful API

Provide a cleaner, extensible API for third‑party integration.

6. Comprehensive Documentation, Comments, and Test Cases

Invest in high‑quality docs and automated tests to aid contributors.

Q&A

Q1: How to build and maintain an open‑source team?

Motivation comes from learning and passion; contributors volunteer their time.

Q2: How do you decide on technology trade‑offs?

Decisions balance technical merits with user familiarity and operational simplicity.

Q3: How to handle inconsistent code styles?

Future plans include establishing a coding style guide and adding linting tools.

Q4: Will the CMDB be open‑sourced?

It is currently embedded in Jumpserver; a standalone open‑source version may be released later.

Q5: Is the CMDB built from scratch?

It extends the existing asset module within Jumpserver.

Q6: Any commercial plans?

Currently no; the project relies on community donations.

Q7: Why Python over Java?

Python is simpler and easier for ops engineers, whereas Java has a steeper learning curve.

Q8: Will Windows support be added?

Yes, the team is researching Python RDP solutions to integrate with Jumpserver’s authentication and recording features.