Jumpserver

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

JumpServer runs a multi-container stack, so Standard_B4ms (4 vCPU / 16 GiB RAM) is the recommended starting size. The upstream minimum is 4 cores and 8 GiB.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network for host administration, 80/tcp for the web console and 2222/tcp for the SSH bastion gateway. The console binds to the address the VM resolves on first boot. For production, put it behind your own domain and a real certificate (see Step 11).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for JumpServer by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size (Standard_B4ms or larger). Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80).

Select Review + create, then Create. When the VM exists, add an inbound rule for 2222/tcp so operators can reach the SSH gateway.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:jumpserver-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name jumpserver \
  --image sac1647283583153:jumpserver-ubuntu-24-04:default:latest \
  --size Standard_B4ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name jumpserver --port 80 --priority 1010
az vm open-port --resource-group <your-rg> --name jumpserver --port 2222 --priority 1020

Step 3 - Connect to your VM

Connect to the VM over SSH as azureuser:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

First boot generates every secret and brings the stack up. jumpserver-firstboot.service runs once, then jumpserver.service keeps the Compose project running. Check both services and the containers:

sudo systemctl is-active jumpserver.service docker.service
sudo docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

Expected output:

active active NAMES IMAGE STATUS jms_web jumpserver/web:v4.10.17-ce Up 2 minutes (healthy) jms_lion jumpserver/lion:v4.10.17-ce Up 2 minutes (healthy) jms_celery jumpserver/core:v4.10.17-ce Up 2 minutes jms_koko jumpserver/koko:v4.10.17-ce Up 2 minutes (healthy) jms_chen jumpserver/chen:v4.10.17-ce Up 2 minutes (healthy) jms_core jumpserver/core:v4.10.17-ce Up 2 minutes (healthy) jms_postgresql postgres:16.10-bookworm Up 3 minutes (healthy) jms_redis valkey/valkey:8.1-bookworm Up 3 minutes (healthy)

The core API and the SSH gateway each expose a health endpoint. Query both:

curl -s -o /dev/null -w 'core: HTTP %{http_code}\n' http://127.0.0.1/api/health/
curl -s -o /dev/null -w 'koko: HTTP %{http_code}\n' http://127.0.0.1/koko/health/

Expected output:

core: HTTP 200 koko: HTTP 200

Watch koko in particular. It is the component that brokers SSH sessions, so a 200 from koko means the bastion can do its job.

Step 5 - Secure by default: no login ships with the image

The API refuses unauthenticated calls. The datastores are not reachable from the host at all: PostgreSQL and Valkey publish no host port and live only on the private container network. Verify both:

curl -s -o /dev/null -w 'no token: HTTP %{http_code}\n' http://127.0.0.1/api/v1/users/users/
sudo ss -ltn | awk 'NR==1 || /:80 |:2222 |:5432 |:6379 /'
sudo docker ps --format '{{.Names}} {{.Ports}}' | grep -E 'postgresql|redis'

Expected output: only 80 (console) and 2222 (SSH gateway) are bound on a host interface, and neither datastore maps a port.

no token: HTTP 401 State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 4096 0.0.0.0:2222 0.0.0.0:* LISTEN 0 4096 0.0.0.0:80 0.0.0.0:* jms_postgresql 5432/tcp jms_redis 6379/tcp

The upstream default administrator password does not work either, because first boot replaces it before the console is reachable:

curl -s -o /dev/null -w "default password: HTTP %{http_code}\n" \
  -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"ChangeMe"}' \
  http://127.0.0.1/api/v1/authentication/auth/

Expected output is 400: the credential is rejected and no token is issued.

default password: HTTP 400

Step 6 - Your per-VM credentials

First boot writes the generated credentials to a root-only file. List the file and view it with the secrets masked:

sudo ls -l /root/jumpserver-credentials.txt
sudo sed -E 's/(pass|PASSWORD|TOKEN)=.*/\1=********/' /root/jumpserver-credentials.txt | head -14

Expected output, with the secrets masked. The real file holds the values:

-rw------- 1 root root 1587 Jul 19 06:11 /root/jumpserver-credentials.txt
# JumpServer — generated on first boot by jumpserver-firstboot.service
# These credentials are unique to this VM. Store them somewhere safe. jumpserver.url=http://10.0.0.22/ jumpserver.admin.user=admin jumpserver.admin.pass=********
# Canonical keys consumed by the Marketplace smoke verifier + guide substitution: JUMPSERVER_ADMIN_PASSWORD=<set-at-first-boot> JUMPSERVER_API_TOKEN=<set-at-first-boot>

The API token is a JumpServer private token for the admin user. It keeps working after you change the console password, so your automation is not interrupted. Test it:

TOKEN=$(sudo grep '^JUMPSERVER_API_TOKEN=' /root/jumpserver-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w 'with token: HTTP %{http_code}\n' \
  -H "Authorization: Token ${TOKEN}" http://127.0.0.1/api/v1/users/users/

Expected output:

with token: HTTP 200

Step 7 - Sign in to the console

Browse to http://<vm-public-ip>/ and sign in as admin with the password from the credentials file.

JumpServer requires you to choose a new password at your first interactive sign-in. Set the new password and store it safely, because the credentials file is not updated when you change it.

After you sign in, the Console dashboard shows live session counts, user and asset totals, and recent activity.

Step 8 - Add an asset and vault its credential

An asset is a machine you want to reach. An account is the credential on that machine. JumpServer stores it encrypted under the SECRET_KEY of this VM, so your operators never need to hold it.

In the Console, go to Assets, choose Create and add a host. Give it a name, its address and the Linux platform. Then add an account to it, which is a username plus either a password or an SSH private key. JumpServer vaults the secret. Finally, under Authorizations, grant a user or group permission to that asset with that account.

You can do the same over the API, using the token from Step 6:

TOKEN=$(sudo grep '^JUMPSERVER_API_TOKEN=' /root/jumpserver-credentials.txt | cut -d= -f2-)
curl -s -H "Authorization: Token ${TOKEN}" \
  'http://127.0.0.1/api/v1/assets/hosts/?limit=5' \
  | head -c 400; echo

This returns the JSON list of hosts JumpServer currently manages.

Step 9 - Connect through the bastion

Operators do not SSH to the target. They SSH to JumpServer on port 2222, and JumpServer opens the session for them using the vaulted credential. Running ssh -p 2222 <jumpserver-user>@<vm-ip> opens an interactive menu of everything that user is permitted to reach.

To go straight to one target, use the direct connect form of koko. It takes the JumpServer user, the account, the asset address and then the JumpServer host:

ssh -p 2222 '<jumpserver-user>@<account>@<asset-address>@<vm-ip>'

The gateway brokers the session. The shell that answers is the target's, reached with a credential the operator never saw.

Step 10 - Every session is recorded

The audit trail is the point of a bastion. Go to the Audits workspace, then Asset sessions, and open Historical sessions. Each brokered session is listed with the JumpServer user, the target, the account used, the protocol and the start time. Select Playback to replay exactly what happened.

Recordings, the vault and the database all live on the dedicated data disk. Confirm the mount:

mountpoint -q /var/lib/jumpserver && echo "/var/lib/jumpserver is a dedicated volume" df -h /var/lib/jumpserver | tail -1

Expected output:

/var/lib/jumpserver is a dedicated volume /dev/sda 98G 8.5G 85G 10% /var/lib/jumpserver

Because this data sits on its own disk, you can grow or snapshot your audit history independently of the OS disk.

Step 11 - Production: your own domain with TLS

The image serves the console over HTTP on port 80, so it works as soon as the VM boots. For production, terminate TLS in front of it. Point a DNS name at the VM, put a reverse proxy or an Azure Application Gateway with a certificate for that name in front, and restrict 80/tcp to that proxy.

Keep 2222/tcp reachable for the SSH gateway, and restrict 22/tcp to your management network. Operators should use the bastion, not the host.

Back up /var/lib/jumpserver (database, vault and recordings), and keep /root/jumpserver-credentials.txt somewhere safe. The SECRET_KEY in /opt/jumpserver/config.txt decrypts every vaulted credential. Without it, a restored database is unreadable.

Support

SecureAnyCloud provides 24/7 support for this image. Contact us at sales@secureanycloud.com or visit secureanycloud.com.

Deploy on Azure

Launch JumpServer on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Launching the instance

Launch the AMI from the AWS Marketplace listing. Use these recommended settings:

• Instance type: m5.large runs the full stack. The upstream documented minimum for a standalone deployment is 4 vCPU and 8 GB of memory, so choose m5.xlarge or larger for production concurrency.
• Root volume: 40 GiB gp3 (the default in the listing).
• Data volume: 100 GiB gp3, attached automatically and mounted at /var/lib/jumpserver.
• Security group: inbound TCP 22 (SSH), 80 (web console and REST API) and 2222 (SSH and SFTP gateway).
• Key pair: your own EC2 key pair, which you use for the operating system login.

Restrict the security group to your own address ranges wherever you can. Port 80 serves the console, and port 2222 is the bastion gateway that your engineers connect through.

First boot takes a few minutes. A one-shot service generates every secret, initializes an empty database, brings the eight containers up and waits for the gateway to report healthy before it finishes.

Connecting to your instance

Connect to the operating system over SSH with your own EC2 key pair, using the login user for your AMI variant:

• Ubuntu 24.04: login user ubuntu, command ssh -i your-key.pem ubuntu@<public-ip>

Both ports 22 and 2222 speak SSH, but they lead to different places:

• Port 22 is the operating system of the appliance itself. You log in with your EC2 key pair as ubuntu.
• Port 2222 is the JumpServer bastion gateway. Your engineers log in with their JumpServer accounts to reach your assets.

Retrieving your credentials

Every secret in this appliance is generated on your instance at first boot and exists nowhere else. Read the credentials file over SSH with sudo cat /root/jumpserver-credentials.txt.

The file is mode 0600, owned by root, and contains the console URL, the admin username, the per-instance administrator password and a per-instance REST API token.

To confirm which keys are present without printing any value, run:

sudo grep -oE '^[A-Za-z_.]+=' /root/jumpserver-credentials.txt | sort -u

The administrator password is deliberately single use. JumpServer requires you to choose a new password the first time you sign in interactively. The credentials file is not updated when you change the password, so store the new one somewhere safe. The API token is a JumpServer private token and is not affected by the interactive password change, so your automation keeps working.

Verifying the appliance from the command line

Every command in this section is safe to run on a live instance, and none of them prints a secret.

Services

systemctl is-active docker.service jumpserver-firstboot.service jumpserver.service

The eight containers

sudo docker ps --format '{{.Names}}\t{{.Image}}\t{{.Status}}' | sort

Note that jms_redis runs the valkey/valkey image. The container name and hostname are kept for wiring compatibility, but the software is Valkey, not Redis.

Component health through the front door

Each registered component reports its own health endpoint through the nginx front door. All four must answer 200:

for path in /api/health/ /koko/health/ /lion/health/ /chen/healthy; do printf '%s -> %s\n' "$path" "$(curl -sS -o /dev/null -w '%{http_code}' --max-time 20 "http://127.0.0.1$path")" done

What actually listens on the host

ss -ltnH | awk '{print $4}' | sort -u

The output shows 22, 80 and 2222, plus the local systemd-resolved stub on 127.0.0.53. It does not show 5432 or 6379 in any address family. The check enumerates every listener instead of matching one spelling of an address, because a dual-stack service can bind [::ffff:127.0.0.1] and slip past a naive 0.0.0.0 match.

The datastore and cache publish no host port

for c in jms_postgresql jms_redis; do printf '%s ports: %s\n' "$c" "$(sudo docker inspect -f '{{json .NetworkSettings.Ports}}' "$c")" done

A null value against each port means the container port is not published to the host at all. This is stronger than binding to loopback, because there is no host socket to reach.

The dedicated data volume

The whole stateful tier lives on its own EBS volume mounted at /var/lib/jumpserver. The volume is referenced in /etc/fstab by filesystem UUID, so the mount is reproduced on every instance launched from this AMI:

findmnt -no SOURCE,TARGET,FSTYPE /var/lib/jumpserver df -h /var/lib/jumpserver /var/lib/containerd /

Both Docker stores are on that volume. This matters because Docker 29 keeps image layers in the containerd content store, so relocating only the Docker data-root would leave several gigabytes of image layers on the OS root disk. /var/lib/containerd is bind-mounted onto the data volume with its own /etc/fstab entry:

grep -E 'jumpserver|containerd' /etc/fstab

Every secret is per-instance

The image records a one-way SHA-256 digest of the secrets that were baked into it at build time. First boot replaces those secrets, so the digest of the live configuration must differ from the recorded image digest. Neither command prints a secret. Both print a digest:

echo "image digest : $(sudo cat /var/lib/sac/data/jumpserver-image-secrets.sha256)"
echo "live digest : $(sudo grep -E '^(SECRET_KEY|BOOTSTRAP_TOKEN)=' /opt/jumpserver/config.txt | sha256sum | awk '{print $1}')"

If the two strings match, the appliance is still running the temporary build-time secrets and first boot has not completed. The strings must be different.

The vendor default credentials are rejected

The JumpServer database migration seeds the admin account with the published default password ChangeMe. First boot replaces it before the appliance is reachable. Verify this against the live login endpoint:

for pw in ChangeMe admin; do code=$(curl -sS -o /tmp/jms-default-check.json -w '%{http_code}' --max-time 20 \
  -X POST http://127.0.0.1/api/v1/authentication/auth/ \
  -H 'Content-Type: application/json' \
  -d "{\"username\":\"admin\",\"password\":\"$pw\"}") printf 'admin/%s -> HTTP %s token_issued=%s\n' "$pw" "$code" "$(grep -c '"token"' /tmp/jms-default-check.json)" done rm -f /tmp/jms-default-check.json

Both attempts must return HTTP 400 with token_issued=0. JumpServer temporarily locks an account after five failed sign-ins, so do not run this check in a loop.

Unauthenticated API access is refused

curl -sS -o /dev/null -w 'unauthenticated /api/v1/users/users/ -> HTTP %{http_code}\n' \
  --max-time 20 'http://127.0.0.1/api/v1/users/users/?limit=1'

The expected response is 401.

Signing in to the web console

Open http://<public-ip>/ in a browser and sign in as admin with the password from your credentials file.

JumpServer immediately requires you to choose your own password. This is the single-use password behavior described above, which is enabled deliberately at first boot.

After you set your password, JumpServer asks you to acknowledge the account security notice once. Select the agreement checkbox and submit. The console then opens on the dashboard, which shows live session and user counts, failed sessions today, and the user and asset activity trend.

Adding your first asset

An asset is something you want people to reach: a Linux host, a Windows host, a network device, a database, a cloud account or a web application. An account is a credential on that asset. JumpServer holds it in its vault, encrypted with the master key generated on your instance.

• Go to Console > Assets and click Create.
• Choose the asset type (Host for a Linux or Windows server), give it a name and its address, and pick the matching platform.
• Under Accounts, add the login that JumpServer should use on that asset: a username with either a password or an SSH private key. That secret is encrypted into the vault, and nobody who is granted access to the asset ever sees it.
• Save. JumpServer can test the account and report connectivity against the real host.

Granting access

You grant access through an authorization, not by handing out the credential.

• Go to Console > Authorizations and click Create.
• Select the users or user groups, the assets or nodes, and the accounts they may use.
• Choose the protocols and the actions they are allowed: connect, upload and download.
• Save. The authorization takes effect within a few seconds. The gateway briefly caches the permitted asset list of each user.

Opening a recorded session

Your engineers can reach their assets in two ways, and both are recorded.

From a browser. Engineers sign in to the console, open Workbench and click the asset. SSH and SFTP sessions open in the browser terminal, RDP and VNC sessions open through the lion gateway, and database sessions open through the chen client. Nothing needs to be installed on their machines.

From a standard SSH client, through the gateway on port 2222. The login string names the JumpServer user, the account on the asset, the address of the asset and the JumpServer host:

• Login string: <jumpserver-user>@<account>@<asset-address>@<public-ip>
• Command: ssh -p 2222 '<jumpserver-user>@<account>@<asset-address>@<public-ip>'
• Interactive menu: ssh -p 2222 '<jumpserver-user>@<public-ip>', then choose from the asset list

JumpServer matches the asset by its address, not by its display name. The display-name form returns match asset failed: No found asset.

Every completed session appears under Console > Audit > Sessions with its user, asset, account, protocol and duration, and you can retrieve the terminal replay from there. Session recordings are stored on the dedicated data volume, so they grow independently of the OS disk.

Operating the appliance

Common operating tasks and their commands:

• Restart the whole stack: sudo systemctl restart jumpserver.service
• Stop the stack: sudo systemctl stop jumpserver.service
• Follow the core application log: sudo docker logs -f jms_core
• Follow the gateway log: sudo docker logs -f jms_koko
• Inspect the Compose configuration: sudo docker compose -f /opt/jumpserver/docker-compose.yml --env-file /opt/jumpserver/config.txt ps

The appliance configuration lives in /opt/jumpserver/config.txt (mode 0600, root only). It holds the master key, the component bootstrap token and the datastore passwords for your instance. Do not copy it off the instance, and do not share it.

The registered components (the SSH gateway, the RDP and VNC gateway and the database client) receive a reduced copy of that configuration at /opt/jumpserver/config_safe.txt. The copy deliberately excludes the datastore host, port and passwords. These components authenticate to core with the bootstrap token and do not need database credentials. Confirm that the exclusion holds without printing anything sensitive:

for k in DB_HOST DB_PORT DB_PASSWORD REDIS_PASSWORD; do printf '%s present in config_safe.txt: %s\n' "$k" \
  "$(sudo grep -c "^${k}=" /opt/jumpserver/config_safe.txt)" done

Every count must be 0.

Backup

Everything worth backing up lives under /var/lib/jumpserver on the dedicated EBS volume. This includes the vault, the asset and account inventory, the users and authorizations, the audit trail and the session recordings. Snapshot that volume with EBS snapshots or AWS Backup on whatever schedule your retention policy requires.

Also back up /opt/jumpserver/config.txt, separately and securely. It holds the master key that decrypts the vault, so a database snapshot without it cannot be restored.

Adding TLS and your own domain

The image serves plain HTTP on port 80, so it works as soon as it launches. For anything beyond an initial trial, terminate TLS in front of it using one of these options:

• Put an Application Load Balancer with an AWS Certificate Manager certificate in front of the instance, forward to port 80, and restrict the instance security group to the load balancer.
• Terminate TLS on the instance with your own certificate and a reverse proxy.

Point your own DNS name at whichever option you choose. Contact SecureAnyCloud support if you would like us to walk through either option with you.

Support

SecureAnyCloud provides 24/7 technical support for this image by email and live chat.

• Email: sales@secureanycloud.com
• We help with deployment, connecting your first assets and accounts, access control design, TLS termination with your own certificate and domain, session recording retention, datastore backup, instance sizing and upgrade guidance.

JumpServer Community Edition is licensed under GPLv3. The corresponding source for JumpServer and each of its bundled components is available from the upstream project at the pinned v4.10.17 release tag.

Deploy on AWS

Launch JumpServer with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com