JumpServer

JumpServer is a bastion host that gives operators a single entry point to your servers and databases. Every connection passes through JumpServer, so you can later check who did what on which server.

This review is for people who run more than a few servers with a team and want to rethink how access is managed. After reading it, you can do the following:

• Install JumpServer on a test virtual machine and sign in to the console
• Register one server and connect to it from the browser
• Know where connection records are stored

##What JumpServer does

The official README describes JumpServer as an open-source privileged access management (PAM) platform. It lets you reach SSH, RDP, Kubernetes, databases, websites, and more from one interface. The main features in the official docs are:

• Centralized access: You register servers (assets) and their login accounts in JumpServer. Users connect through the browser.
• Access assignment: In Authorization, you decide which users can use which accounts on which assets.
• Activity records: JumpServer records sessions and the commands typed during them. Recordings can go to local storage or to object storage such as Amazon S3. Command logs can go to local storage or Elasticsearch.
• Multi-factor authentication (MFA): You can require MFA for all users or for administrators only.

A bastion host makes defense easier because there is only one place to protect. If servers accept logins only from the bastion, you no longer hand out passwords or keys to each operator. Removing a departing employee’s access becomes one change on the bastion. Because sessions are recorded, you can trace who did what and when after an outage or a suspected incident. The trade-off is that a compromised bastion affects every server behind it, so keeping it updated and its authentication strong matters most.

The official comparison table lists the differences between the open-source Community Edition (CE) and the commercial Enterprise Edition (EE). For example, session monitoring and command auditing are in both. OIDC and SAML2 integration, Oracle and SQL Server access, and the ticketing system are EE only.

##Try it safely: one test virtual machine

The official guide asks for a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM. Try everything on a test VM before you connect production servers. We could not find a list of supported Linux distributions in the official docs (unverified).

1. Create a Linux VM with at least 4 cores and 8 GB of RAM. See How to build a safe test lab for options.

2. Log in as root or as a user with superuser privileges, and change to /opt.

3. Download the official install script and read it before running it (see “Cautions”).

4. When you are satisfied, run it as the official guide shows:

   curl -sSL https://github.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash

5. When installation finishes, open https://<JumpServer IP address>/ in your browser.

6. Sign in with the default account (username admin, password ChangeMe). You are asked to change the password at first sign-in. Choose a strong one.

7. Turn on MFA even for a test instance. Use Global MFA under Security>Auth security in the console.

##Basic use: connect one server

The official quickstart walks you to a first connection in this order. Connect only to a server you set up for testing.

You can change where recordings and command logs are stored under Storage>Object storage and Command storage.

##Cautions

##Read next

• cd ../keycloakKeycloakan identity server for single sign-on and multi-factor authentication
• cd ../wazuhWazuha security platform that collects and monitors server logs
• cat ~/guides/lab-setup.mdHow to build a safe test lab