用海外云服务器自建 JumpServer 开源堡垒机完整教程：SSH/RDP/数据库统一纳管、会话录像与命令审计实战（2026最新版）

Meta Description: 2026 最新 JumpServer 自建教程：在海外云服务器一键部署开源堡垒机（PAM 特权访问管理），统一纳管 SSH、RDP、数据库、Kubernetes、Web 资产，配置会话录像、命令审计、MFA 与工单审批，附社区版与企业版功能边界、jmsctl 运维命令、数据备份升级、故障速查、配置价格对比表与 10 条常见问答。

关键词：JumpServer 搭建、自建堡垒机、开源堡垒机、运维审计、PAM 特权账号管理、4A 规范、JumpServer 一键部署、会话录像、命令审计、SSH 跳板机、等保合规、海外云服务器

前言

当你手上从一台服务器变成五台、十台，问题就不再是「哪台机器还能连上」，而是「谁、在什么时候、用什么账号、连了哪台机器、敲了什么命令」。多人共用 root、把私钥随手发给同事、生产库的密码写在群公告里——这些才是最容易被忽略、也最难在出事后复盘的地方。JumpServer 就是来解决这件事的：它是一个开源堡垒机（官方定位是开源特权访问管理平台，PAM），把「连服务器」这件事从「人手一把钥匙」改造成「统一入口 + 全程录像 + 命令审计」，符合 4A 规范（认证 Authentication、授权 Authorization、账号 Accounting、审计 Auditing），实现事前授权、事中监察、事后审计。

JumpServer 由飞致云（FIT2CLOUD）维护，以 GPLv3 许可证开源（Copyright 2014-2026 FIT2CLOUD），GitHub 仓库为 jumpserver/jumpserver——注意它的默认分支是 dev 而不是 main。它支持纳管的资产类型非常广：SSH、Windows（RDP）、数据库、云服务（Kubernetes / VMware）、Web 站点以及 RemoteApp 远程应用。官方推荐的一键部署脚本会把整套系统（Web 管理端、终端连接器、数据库与缓存）以 Docker 容器的方式装好，因此才有一条重要的结论：宿主机只需要一个 64 位 Linux 与 Docker，宿主的 glibc 版本完全不参与——和本站写过的 Immich / RustDesk / AdGuard / Umami / Loki / authentik 一样，CentOS 7 的 glibc 2.17 不会是障碍。

当前最新稳定版为 v5.1.0（2026-10-15 发布），安装脚本中的 VERSION 就固定在这个版本号上。官方给出的最低要求很简单：一台干净的 64 位 Linux 服务器，至少 4 核 CPU、8 GB 内存。

动手之前，请记住官方与社区反复强调的三条最容易踩的坑：① 绝不要把 SSH 端口（默认 2222）和 Web 端口（默认 80）直接全量暴露公网——堡垒机是所有服务器的「总门」,门锁丢了等于全家都丢了，务必套 Nginx HTTPS + IP 白名单 + MFA；② 默认管理员账号是 admin / 密码 ChangeMe，装完第一件事就是改掉它并开两步验证；③ 数据目录与 SECRET_KEY、BOOTSTRAP_TOKEN 必须纳入备份——换了密钥等于所有已登录会话失效，迁移时这两个值要和旧环境保持一致。 另外，也不要把它和「密码管理器」或「统一身份认证」混为一谈——它们回答的是完全不同的问题（下文会专门切开）。

🚀 需要一台海外云服务器来跑 JumpServer？通过 5.chengzicloud.cloud 购买阿里云国际版 / 腾讯云国际版 / AWS，享专属折扣。

一、先搞清楚：JumpServer 解决什么问题（与站内方案的分工）

JumpServer 的定位是「谁连了哪台机器、干了什么」——它不替代你的服务器，也不改变你的网络结构，而是在你和所有被管理资产之间插入一个统一的入口：运维人员不再持有资产的真实密码/密钥，而是登录堡垒机，由堡垒机代为连接、代填凭据、并录下全过程。这就是「运维审计」（也叫跳板机、堡垒机）的核心逻辑。

很多人在自建时会把几个「安全 / 连接 / 接入类」服务混在一起选，其实它们回答的是完全不同的问题。下表把站内已经写过的相邻方案和 JumpServer 逐一切开：

一句话总结边界：JumpServer 不是密码管理器（它不保管你的个人密码，那是 Vaultwarden 的事）；不是 VPN 或内网穿透（它不改变网络可达性，那是 WireGuard / frp 的事）；不是业务应用的 SSO（那是 authentik 的事）。它是横跨在「网络打通」与「业务登录」之间、专门回答「运维行为是否被授权、是否被记录」的那一层。

二、部署前的三条前置条件（先确认，再动手）

第 1 步：选系统——优先 Ubuntu 22.04 / 24.04 或 Debian 12/13

官方一键脚本基于 Docker 分发，脚本本身会按发行版自动选用 dnf / yum / apt / zypper / apk 来补齐 curl wget tar gettext coreutils 等依赖，因此主流 x86_64 Linux 都能跑（官方 installer 要求内核大于 4.0）。CentOS 7 已于 2024 年 6 月 EOL，不建议用于新部署，建议直接用 Ubuntu 22.04 / 24.04 或 Debian 12/13。容器方案的好处是应用依赖的系统库都打包在镜像里，宿主 glibc 不参与——就是开头说的那条结论。

第 2 步：确认资源下限——4 核 8G 起步，数据库与缓存内置

官方 README 的 Quickstart 原文只有一句：「Prepare a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM.」 也就是说，最低 4 核 CPU / 8 GB 内存。这套系统一台机器上同时跑：Web 管理端（Lina）、Web 终端与连接器（KoKo / Luna / Chen）、后端任务、以及内置的数据库（PostgreSQL 5432 或 MariaDB 3306）与缓存（Redis 6379）。请不要用 1 核 1G / 2 核 2G 去试——一键脚本拉镜像 + 数据库初始化 + 首启动非常吃内存，小内存机很容易在启动阶段被 OOM 杀掉，装到一半失败是最常见的「新手劝退」场景。

第 3 步：先锁定一个「专属域名」和一组端口

堡垒机的登录入口最好绑定独立子域名（例如 jumpserver.example.com）并准备好 DNS，方便签 HTTPS 证书。同时要提前规划端口：Web 用 80/443，SSH 终端连接器用 2222，其余组件端口（如 5001、3389、5525）按需放通。最稳妥的做法是：80/443 交给 Nginx 走 HTTPS，2222 等运维端口只对可信来源 IP 开放，而不是全量丢在公网上。

三、第一步：一键部署 JumpServer（默认 v5.1.0）

官方推荐的安装方式是「一键脚本」，它会自动完成三件事：补齐依赖 → 把安装器下载解压到 /opt/jumpserver-installer-v5.1.0 → 依次执行 ./jmsctl.sh install 和 ./jmsctl.sh start。

第 1 步：用 root 执行官方一键脚本

# 官方源（GitHub），脚本内固定 VERSION=v5.1.0
curl -sSL https://github.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash

如果你在海外云主机上遇到从 GitHub 拉取镜像慢的问题，可以用飞致云的国内镜像脚本——它会额外把安装器的 DOCKER_IMAGE_MIRROR=1 打开，走国内镜像加速：

# 国内加速源（自动开启 Docker 镜像加速）
curl -sSL https://resource.fit2cloud.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash

需要固定某个具体版本时，用环境变量覆盖 VERSION 即可，例如：

VERSION=v5.1.0 curl -sSL https://resource.fit2cloud.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash

脚本下载安装器时会做 sha256 校验（jumpserver-installer-v5.1.0.tar.gz.sha256），校验不通过会直接中止并在控制台报错，这一点可以放心。

第 2 步：安装器的关键路径与配置

安装器落地后，你会用到下面几个固定路径（后文的运维命令都基于它们）：

首次 ./jmsctl.sh install 时脚本会引导你确认配置。配置模板里最需要留意的几项：

• VOLUME_DIR=/data/jumpserver——所有持久化数据的落盘位置，建议放到独立数据盘；
• HTTP_PORT=80 / HTTPS_PORT=443——Web 端口；
• KOKO_SSH_PORT=2222——SSH 终端连接端口（客户端 ssh -p 2222 就连它）；
• SECRET_KEY / BOOTSTRAP_TOKEN——加密密钥与组件注册令牌，迁移时必须与旧环境一致，且绝不能外泄；
• DOMAINS / SERVER_NAME——受信域名，反代场景建议显式填写。

第 3 步：启动并确认服务起来

脚本末尾会自动 ./jmsctl.sh start。稍等片刻后确认状态：

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

看到各个容器（core / web / koko / redis / 数据库等）为 running 即可。

四、第二步：Nginx 反向代理 + HTTPS（必做）

一键脚本默认会在宿主机直接监听 80 端口。生产环境应当改成「容器只绑本机，由宿主机 Nginx 对外提供 HTTPS」。

第 1 步：让 Web 只监听本机

在 /opt/jumpserver/config/config.txt 里把 HTTP 端口改到本机高位端口（避免和 Nginx 抢 80），例如把 HTTP_PORT=80 改为 HTTP_PORT=8080，然后重启：

./jmsctl.sh restart

第 2 步：配置 Nginx 反向代理与 WebSocket

JumpServer 的 Web 终端依赖 WebSocket，所以反代必须正确转发升级头。参考配置：

server {
    listen 443 ssl http2;
    server_name jumpserver.example.com;

    ssl_certificate     /etc/letsencrypt/live/jumpserver.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/jumpserver.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Web 终端所需
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 3600s;
    }
}

第 3 步：别忘了 SSH 连接器的端口

Web 端（80/443）走 Nginx 没问题，但SSH 终端连接器（默认 2222）是独立的 TCP 服务，不走 Nginx。如果你希望运维人员用命令行 ssh -p 2222 [email protected] 登录，就必须在安全组里放通 2222；如果只用网页终端，则可以只对可信 IP 开放 2222，缩小暴露面。

五、第三步：初始化管理员与「上线必改」清单

第 1 步：用默认账号登录并立刻改密

安装完成后浏览器访问 https://jumpserver.example.com/，默认账号是 admin / 密码 ChangeMe。第一件事就是修改这个密码——它是全网最容易被人扫描试探的默认口令。

第 2 步：开启两步验证（MFA）

JumpServer 社区版免费支持 OTP 两步验证（如 TOTP 认证器 App）以及 RADIUS 二次认证；登录来源还支持 LDAP / AD、CAS、Passkey、OpenID、OAuth、SAML2 等 SSO 对接。给管理员账号开启 OTP 是成本最低、收益最高的一步。

第 3 步：限制登录来源 IP 与时间段

社区版自带「登录限制」能力：可按黑 / 白名单控制用户登录来源 IP，也可自定义控制登录的时间段。上和跳板机这类「总入口」服务，强烈建议把登录来源收敛到办公网或固定 IP。

六、第四步：纳管第一台资产（以 Linux SSH 为例）

JumpServer 的资产模型分三层，理解了它就理解了整套系统：资产（被管的机器）→ 账号（机器上的登录身份）→ 授权（谁能在什么条件下用哪个账号连哪台资产）。

第 1 步：创建资产

在「资产管理」里新增一台主机，填入名称、IP、平台（Linux）等信息。资产支持树状节点结构，节点内资产可自动继承授权、子节点自动继承父节点授权——机器一多，靠节点分组来批量授权比逐台勾选省事得多。

第 2 步：创建账号

账号分两种：特权账号（机器上真实的 root/运维账号，用于「代填凭据」自动登录）与普通账号（被授权用户自己在该资产上的登录身份）。社区版支持为用户名与认证信息相同的账号抽象出账号模板，快速与资产关联并批量生成账号。

第 3 步：创建授权规则

新建授权，把「用户/用户组」与「资产/节点」以及账号关联起来。JumpServer 的授权是多维度的，社区版即可免费使用：

• 资产授权：把资产和节点灵活授权给用户；
• 动作授权：控制文件上传 / 下载以及「连接」动作，支持 RDP 剪贴板复制粘贴控制；
• 时间授权：限制授权资产的可使用时间段；
• 命令过滤：对授权账号执行的命令进行控制（例如拦下 rm -rf）；
• 协议授权：控制允许连接的协议。

第 4 步：连接并验证

用被授权的普通用户在「Web 终端」里点开该资产，或者用命令行连接 SSH 连接器，即可免密（由堡垒机代填）登录被管机器。从这里开始，你的所有操作都会进入审计。

七、第五步：会话录像、命令审计与实时监控

这是堡垒机存在的真正理由。JumpServer 社区版免费提供以下审计能力：

• 会话审计：在线会话内容审计 + 历史会话内容审计，支持在会话画面上叠加水印（泄露溯源）；
• 录像审计：对资产操作的录像进行回放审计，录像还支持上传到云端对象存储（Amazon S3、腾讯云 COS、阿里云 OSS、华为云 OBS、Ceph、Swift、Azure）；
• 命令审计：记录资产上执行的命令，并支持高危命令告警；
• 文件传输审计：记录文件上传 / 下载行为；
• 实时监控：管理员 / 审计员可实时旁观用户操作，必要时实时中断会话；
• 登录 / 操作 / 改密 / 作业 / 活动日志：覆盖用户登录、后台操作、密码修改、自动化任务执行等；登录日志还支持同步至 Syslog。

一个实用的落地建议：把「命令审计」的告警接到你已有的告警通道上（例如站内的 ntfy 自建推送服务 或 Uptime Kuma 状态页 的告警体系），高危命令一出现就实时收到推送，比事后翻录像有用得多。

八、第六步：纳管数据库、Windows 与 Kubernetes

JumpServer 的价值随着「被纳管资产类型」的增加而放大，下面这几类资产都值得尽快接入：

• 数据库：社区版免费支持 MariaDB、MySQL、Redis、MongoDB 的数据库连接与审计；企业版（X-Pack）在此基础上扩展到 Oracle、SQL Server、PostgreSQL、ClickHouse、DB2、达梦数据库。数据库运维最怕「直连生产库改数据」，走 JumpServer 后每一次 SQL 都会被记录。
• Windows 资产（RDP）：社区版支持 RDP 协议代理连接与剪贴板控制；企业版额外支持「高清晰度 RDP 客户端连接」。想把 Windows 服务器也纳入统一审计，这条是刚需。
• Kubernetes：支持对 Kubernetes 进行运维审计，把 kubectl exec 之类的集群操作也收进录像。
• Web 站点与远程应用：支持纳管 Web 站点资产，以及 RemoteApp 远程应用（自动管理远程应用发布机，一键部署发布机）。

九、第七步：账号管理（PAM）——改密、备份与风险检测

从 v4.10 LTS 起，JumpServer 把「堡垒机」与「PAM 特权账号管理」整合进同一套系统：既能发现并管理特权账号，又能对运维操作进行审计管控。社区版可用的账号管理能力包括：

• 账号列表 / 账号模板：集中查看与抽象复用账号；
• 账号推送：把自定义账号与密码一键下发到目标资产，无需手动登录创建；
• 数据库账号连接：统一管理数据库账号；
• 改密 / 备份（企业版 X-Pack）：批量改密、定期备份账号密码（支持双人密钥解密）、按密码策略生成复杂口令；
• 风险检测（企业版 X-Pack）：自动扫描僵死账号、异常账号、弱密码账号并实时告警；
• 账号存储（企业版 X-Pack）：可对接外部密文存储系统（HashiCorp Vault / OpenBao）统一托管凭据。

即便只用社区版，「账号模板 + 账号推送」也足以把「新服务器开账号」这件重复劳动标准化。

十、安全加固清单

装机只是起点，堡垒机必须比它保护的机器更安全。建议逐项落实：

1. 改默认密码 + 强密码策略：admin / ChangeMe 必须第一个改掉。
2. 强制 MFA：管理员与所有能连生产的账号都开 OTP。
3. 收敛登录来源 IP：用「登录限制」把后台收敛到办公网 / 固定 IP 白名单。
4. HTTPS + 独立子域名：Web 走 Nginx TLS，禁用明文 HTTP。
5. SSH 端口（2222）不要裸奔：只对可信来源开放，或用云安全组做来源限制。
6. 命令过滤：对高危命令（如 rm -rf /、mkfs）配置拦截，配合高危命令告警。
7. 开启会话水印：让别人截屏外泄时也能溯源。
8. 定期备份：见下一节的备份策略，SECRET_KEY 与 BOOTSTRAP_TOKEN 一并纳入。
9. 及时升级：关注官方 Changelog，安全更新优先。

十一、备份、升级与故障排查（jmsctl.sh 全解）

安装器自带的管理脚本 jmsctl.sh 是日常运维的主力工具，常用命令如下：

# 安装 / 升级
./jmsctl.sh install
./jmsctl.sh upgrade

# 启停与状态
./jmsctl.sh start        # 启动
./jmsctl.sh stop         # 关闭（不含数据库）
./jmsctl.sh restart      # 重启
./jmsctl.sh status       # 查看状态
./jmsctl.sh down         # 关闭所有（含数据库）
./jmsctl.sh uninstall    # 卸载

# 备份与恢复
./jmsctl.sh backup_db            # 备份数据库
./jmsctl.sh backup_no_audit      # 备份数据库（不含审计数据，包更小）
./jmsctl.sh backup_audit         # 单独备份审计表
./jmsctl.sh restore_db [file]    # 通过备份文件恢复

# 其它
./jmsctl.sh config               # 配置向导
./jmsctl.sh tail [service]       # 查看日志
./jmsctl.sh raw                  # 执行原始 docker compose 命令

备份策略

一次完整的备份至少要覆盖三样东西：① 数据库（用 backup_db，包含用户、资产、授权、审计元数据）；② 数据目录 VOLUME_DIR（默认 /data/jumpserver，含录像与附件等）；③ 配置文件 /opt/jumpserver/config/config.txt（含 SECRET_KEY、BOOTSTRAP_TOKEN）。任何迁移或重装，只要这三样齐全就能还原——这也是为什么这两个密钥必须和备份一起妥善保管。可参考站内《服务器备份与容灾恢复方案》把备份落地到异地。

升级策略

正确顺序是：先读该版本的发布说明 → 备份 → 执行 ./jmsctl.sh upgrade → 用 status 确认。升级过程中 upgrade 会自动做数据库迁移，迁移不可逆，所以「升级前不备份」是唯一真正危险的操作。

故障排查速查表

十二、社区版够不够用？——社区版 vs 企业版（X-Pack）功能边界

这是自建前最该搞清楚的一件事。JumpServer 社区版资产上限为 5000 台（v4.0 起），日常自建与中小团队基本碰不到这个限制。带 X-Pack 标识的为企业版功能，社区版免费包含 vs 企业版专有的边界大致如下：

结论：只有几台到几十台机器、主要用 SSH + RDP + 常见数据库的团队，社区版完全够用；一旦需要「工单审批 + 组织隔离 + 特权账号自动改密/备份 + 云资产自动同步」，就是企业版场景。

十三、海外云服务器配置推荐与价格对比

JumpServer 的负载特点是「平时很闲，但你连机器时它要同时扛会话录像、命令解析与数据库写入」——真正吃的是 CPU 与内存（多个容器 + 数据库 + 缓存）。官方最低写的是 4 核 8G，因此不要选低于 4 核 8G 的档位。

下表的价格为 2026 年 10 月直读 DigitalOcean 与 AWS Lightsail 官方定价页的档位-规格映射（阿里云国际版 / 腾讯云国际版给区间，因活动浮动较大）：

\* Lightsail 低档位标注的 2 vCPU 为突发型（burstable），持续高负载会受 CPU 积分限制；把堡垒机当作团队基础设施时，建议从 4 核 8G 档起步。

声明：本文价格数据采集于 2026 年 10 月，仅为公开官网参考区间，实际以各家官网实时价格为准，金额单位均为美元（USD）。

选型口径（针对 JumpServer）：

• 个人 / 家庭自建（几台机器）：官方 4 核 8G 是硬底线，DO $48 / Lightsail $44 档即可，数据库与缓存同机。
• 10~50 人小团队：4 核 8G 起步，若资产数多、并发会话多、要长期存录像，建议 8 核 16G（$96 档），并把 VOLUME_DIR 放到独立数据盘。
• 要做高可用（HA）：单机一旦挂了，所有人连不上任何服务器——所以生产环境更该关心备份与恢复速度，而不是一味堆配置。官方也提供集群模式与 Kubernetes Helm 部署，但已超出「单机自建」的范畴。
• 已有独立数据库：如果团队已有独立的 PostgreSQL / MySQL 主机（见站内《MySQL / PostgreSQL 数据库服务器搭建指南》），可以复用它，把主机磁盘 I/O 留给录像存储。

🚀 需要海外云服务器来部署 JumpServer？通过 5.chengzicloud.cloud 购买阿里云国际版 / 腾讯云国际版 / AWS，享专属折扣。

十四、常见误区速查

部署 JumpServer 时，下面这几个「想当然」最容易踩：

1. 「装完就能用了，密码回头再改」——错。默认 admin / ChangeMe 是全网扫描重点，装完立刻改。
2. 「把 2222 端口敞开没关系」——错。堡垒机是所有服务器的总门，SSH 端口必须收敛来源，配合 MFA 与命令过滤。
3. 「2 核 4G 也能跑」——官方最低是 4 核 8G。低于它，一键脚本拉镜像 + 数据库初始化阶段很容易 OOM 失败。
4. 「它就是个 SSH 跳板」——不止。它还能纳管 RDP、数据库、Kubernetes、Web 资产与远程应用，并做会话录像与命令审计。
5. 「它和 Vaultwarden / authentik 是一回事」——不是。它管的是「运维人员的入口与行为审计」，不是个人密码，也不是业务应用 SSO。
6. 「升级直接跑命令就行」——迁移不可逆，升级前必须备份（数据库 + VOLUME_DIR + config.txt）。

推荐方案

• 只要「统一登录 + 录像 + 命令审计」的个人 / 小团队：一台 4 核 8G 海外云服务器（DO $48 / Lightsail $44）+ 官方一键脚本 + Nginx HTTPS，纳管几台 SSH 机器，就足以把「谁动过服务器」这件事看清楚，投资回报极高。
• 10~50 人团队：4 核 8G 起步、录像多的上 8 核 16G + 独立数据盘 + backup_db 每日定时 + 异地备份 + 强制 MFA + 命令过滤 + 登录 IP 白名单。把「改默认密码、收敛 2222、给 admin 开 OTP」这三件事做对，安全性就超过 90% 的自建跳板机。
• 有合规 / 多组织需求的团队：社区版资产上限 5000 台通常够用；一旦需要工单二级审批、组织隔离、特权账号自动改密与备份、云资产自动同步，就是企业版（X-Pack）的场景，按需评估。

如果你还没决定用哪家云，或想直接省掉选型这一步，5.chengzicloud.cloud 提供阿里云国际版 / 腾讯云国际版 / AWS 等海外云服务器的购买与部署支持。