在企业里，服务器账号密码像传家宝一样在几个人手里传来传去，工作记录靠聊天记录，谁改过配置只能靠猜，这场景是不是很眼熟？更危险的是，员工离职后账号回收不及时，或者一台数据库服务器被开发、测试、运维轮流 root 直连，出了问题根本没法追溯。这已经不是管理混乱的问题，而是实实在在的安全漏洞。
Jumpserver 就是为解决这类问题而生的开源堡垒机。它的核心价值不是“多一个登录跳板”，而是把“谁能登、登到哪、做了什么、命令能否审批、录像能否回放”全部收口到一条可控的链路上。对于刚入行运维、或者正在搭建公司运维规范的工程师来说，Jumpserver 是绕不开的基础设施。本文从零开始，走一遍 Jumpserver 的完整部署、配置、纳管资产和审计验证流程，并给出常见的坑和排查思路。
1. 为什么要部署 Jumpserver：不只是“跳板机”
早期很多公司做运维权限管理，用的是一台普通跳板机，所有人先 SSH 到跳板机，再手动跳到目标服务器。这种做法听起来简单，但问题很明确：跳板机本身成为内网入口，一旦被攻击，所有后续主机都暴露；其次，用户登录目标机器的过程没有统一审计，命令历史可以被人为清除；第三，权限管理靠人工分发公钥，账号数量一多必然失控。
Jumpserver 解决的正是这些问题。它通过统一的 Web 界面接入资产，用户不需要拿到目标服务器的真实密码或私钥，所有连接由 Jumpserver 作为代理建立。运维人员看到的是 Web 终端、SSH 客户端或者运维工具，背后则由 Jumpserver 完成认证、授权、命令过滤、操作录像和会话审计。换句话说，目标机器上的账号密码被收进保险箱，用户只用自己的账号登录 Jumpserver，再由平台按授权策略决定你能不能连某台机器、能执行哪些命令。
从架构上理解，Jumpserver 由多个组件组成，包括核心服务（Core）、Web 前端、Luna（Web 终端组件）、Lion（Web 桌面组件，用于 RDP/VNC 协议）、Coco/Koko（SSH 协议连接组件），以及 Guacamole（负责 RDP/VNC 协议代理）。整套系统可以部署在 Linux 服务器上，日常维护并不复杂，但部署方式和组件协同却有讲究。
本文选择的安装方式是 Docker Compose，这是目前社区最常见、也最容易上手的部署方式，适合单机环境、中小规模资产管理和学习测试。生产环境如果资产量很大、需要高可用，再考虑集群化部署，但核心流程中的概念依然相通。
2. Jumpserver 核心概念与适用场景
2.1 资产、账号、用户、权限的关系
在 Jumpserver 中，有几个核心术语必须先理清楚：
- 用户：登录 Jumpserver 的人员账号，可以是普通用户，也可以是管理员。
- 资产：被纳管的服务器、网络设备、数据库等资源。
- 账号：资产上的登录账号，比如 Linux 服务器的 root 或普通用户，数据库账号等。这些账号被 Jumpserver 托管，用户不直接接触真实密码。
- 系统用户：Jumpserver 连接资产时使用的账号，分为“特权用户”和“普通用户”，用于执行自动化任务或作为登录代理。
- 授权规则：把“用户、资产、账号”三者绑定，并指定登录方式、命令过滤和会话控制。
支持的关系并不复杂：先创建用户，再录入资产，再把资产关联到系统用户，最后创建授权规则让某类用户可以访问某些资产。这一套关系捋顺了，后续所有功能都比较容易理解。
2.2 适用场景
Jumpserver 并不是只有大厂才需要。只要存在以下情况，就值得引入：
- 多个运维、开发人员共用服务器账号，无法区分个人操作；
- 需要满足信息安全合规要求，比如等保、ISO 27001，要求对运维操作有审计记录；
- 对外包人员、实习生的权限需要临时授权、到期自动回收；
- 数据库、生产服务器有敏感数据，需要禁用危险命令，比如删除文件、清空表、重启服务。
从搜索热词中也能看到，Jumpserver 经常与“堡垒机”“Linux 运维”一起被搜索，说明这已经是普通运维必备技能，而不只是安全工程师的专属工具。
2.3 新手最容易误解的地方
第一个误解是“堡垒机会拖慢速度”。实际上，Jumpserver 是代理转发模式，链路增加了一层，但只要服务器性能和网络带宽足够，体感延迟很小。相比没有审计带来的安全风险，这点开销值得。
第二个误解是“部署堡垒机之后，用户无法再用 Xshell、SecureCRT 等工具连接”。其实 Jumpserver 还支持通过 SSH 客户端直连，连接地址是堡垒机 IP，端口为 SSH 转发端口，用户仍然可以保留原有客户端习惯，只是账号密码要换成 Jumpserver 的用户名密码，或者通过密钥认证。
第三个误解是“装完堡垒机，运维工作变复杂”。实际用起来后，用户不需要记住资产 IP、账号密码，登录 Jumpserver 后看到的就是自己有权限访问的资产列表，点一下就能连接，反而比原来翻 Excel 记密码方便得多。
3. 环境准备与前置条件
本文以 Linux 系统（这里以 CentOS 7/Ubuntu 20.04 系列为例）演示 Docker Compose 部署方式。实际生产环境请根据发行版调整命令，但整体思路一致。
3.1 服务器要求
- 操作系统：Linux，建议 4 核 CPU、8GB 内存以上，磁盘根据录像留存策略配置，建议至少 100GB。
- 网络：必须能访问外网以下载 Docker 镜像，同时能访问被纳管的资产网络。
- 防火墙：需要开放 80（Web）、2222（SSH 转发）等端口，具体端口可根据情况修改。
- 注意：Jumpserver 服务器本身要加固，因为它会成为内网运维入口，禁止随意放开高危端口。
3.2 安装 Docker 和 Docker Compose
如果服务器还没有 Docker，先安装基础环境。以 CentOS 7 为例：
# 卸载旧版本 yum remove docker docker-common docker-selinux docker-engine -y # 安装依赖 yum install -y yum-utils device-mapper-persistent-data lvm2 # 配置 Docker 仓库 yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo # 安装 Docker yum install docker-ce -y # 启动并设置开机自启 systemctl start docker systemctl enable dockerUbuntu/Debian 系统则用 apt 安装：
apt update apt install -y apt-transport-https ca-certificates curl software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" apt update apt install -y docker-ce systemctl start docker systemctl enable dockerDocker Compose 插件如果使用新版 Docker，可以直接使用docker compose子命令。如果还是旧版，需要单独安装。
# 如果是 Docker Compose V2 docker compose version # 如果命令行提示没有该命令，可以安装 docker-compose curl -L "https://github.com/docker/compose/releases/download/v2.20.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose chmod +x /usr/local/bin/docker-compose ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose docker-compose --version注意，具体版本号请以官方 GitHub Release 页面为准，本文重点演示流程。
3.3 获取 Jumpserver 并准备配置文件
推荐使用官方提供的 Docker Compose 方式。官方仓库会提供一份.env示例文件，里面包含数据库密码、Redis 密码、SECRET_KEY、BOOTSTRAP_TOKEN 等关键配置。
mkdir -p /opt/jumpserver/docker cd /opt/jumpserver/docker # 下载官方 compose 文件（请以当前版本实际文件名为准） # 可以从 GitHub 仓库 jumpserver/Dockerfile 或官方文档获取需要注意，不同版本的 Jumpserver 依赖的组件镜像版本不同，直接去官网下载当前 release 对应的docker-compose.yml和.env最稳妥。
.env文件里面最关键的是生成随机密钥：
# 生成 SECRET_KEY，只用于本机随机生成 echo "SECRET_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | head -c 50)" >> .env echo "BOOTSTRAP_TOKEN=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | head -c 24)" >> .env同时要设置数据库和 Redis 的密码，避免默认密码。
3.4 修改关键端口
默认情况下，Jumpserver Web 端口是 80，SSH 端口是 2222。如果服务器上已经有其他服务占用 80，可以在.env中修改：
HTTP_PORT=8080 SSH_PORT=2222修改后，用户访问 Web 时就用http://IP:8080，SSH 客户端连接时使用端口 2222。
4. 使用 Docker Compose 完成 Jumpserver 部署
4.1 启动服务
在 docker-compose.yml 所在目录执行：
docker-compose up -d如果是新版 Docker Compose，也可以使用：
docker compose up -d首次启动会拉取多个镜像，包括 mysql、redis、core、koko、lion、web 等，耗时取决于网络速度。可以通过docker-compose logs -f查看日志，看到Channels server started或类似关键字说明启动成功。
4.2 初始化管理员账号
部署完成后，浏览器访问http://<服务器IP>:<端口>。首次访问会进入初始化页面，需要设置管理员邮箱和密码。设置完成后，使用该账号登录管理员后台。
需要注意，如果初始化页面没有出现，通常是因为 Core 服务还没有完全启动，或者数据库没有初始化完成。可以稍等 1-2 分钟再刷新。
4.3 验证容器状态
部署完成后，检查容器运行状态：
docker ps | grep jumpserver预期会看到类似下面的容器：
jms-core jms-mysql jms-redis jms-web jms-luna jms-lion jms-koko jms-guacamole每个容器状态为 Up，且没有循环重启，说明基本部署成功。
4.4 升级与版本管理建议
Jumpserver 迭代速度较快，生产环境升级前先备份数据库和配置文件。可以通过docker compose pull拉取新镜像，然后docker compose up -d完成升级。升级后注意查看官方 Upgrade 文档，因为数据库结构可能变化。
5. 纳管 Linux 资产：从创建用户到授权连接
5.1 创建 Jumpserver 普通用户
进入控制台后，在“用户管理 - 用户列表”中创建普通用户。填写用户名、姓名、邮箱、手机等信息，设置初始密码。普通用户后续用这个账号登录 Jumpserver 访问授权资产。
5.2 创建系统用户
系统用户是 Jumpserver 连接资产时使用的账号。通常有两种方式：
- 手动录入账号：如果目标资产上已经存在一个账号，可以把账号密码录入到 Jumpserver 中。
- 自动推送账号：Jumpserver 通过特权用户登录资产后，自动创建系统用户，并推送 SSH 公钥。
实际项目中更推荐自动推送方式，这样目标机器上不需要手动维护密码，而且可以统一配置 sudo 权限。先在“资产管理 - 系统用户”中创建一个“特权用户”，例如名为deploy的账号，具有 SSH 登录和提权能力。然后为不同类型的资产创建对应的普通系统用户，比如nginx、mysql、app等。
创建系统用户时，有几个配置项比较关键：
- 用户名：目标机器上实际使用的登录名。
- 协议：SSH / RDP / VNC 等。
- 自动推送：勾选后 Jumpserver 会在资产上自动生成该用户的 SSH 公钥。
- sudo：配置
/usr/bin/passwd, /usr/bin/chsh等允许执行的命令，或者留空表示不授权 sudo。 - 命令过滤：配置该用户可执行的命令白名单或黑名单。
5.3 添加资产
进入“资产管理 - 资产列表”，点击“创建”按钮添加 Linux 资产。
需要填写的信息包括：
- 主机名：给资产起的名称。
- IP：资产的实际 IP。
- 协议：SSH。
- 端口：默认 22，如果自定义过则填写实际端口。
- 系统用户：选择刚才创建的系统用户。
保存后，Jumpserver 会测试连接。如果资产上还没安装并启动 SSH，或者防火墙限制了 Jumpserver 服务器的 IP，连接测试会失败。
5.4 创建授权规则
在“权限管理 - 资产授权”中，新建授权规则。
规则中需要选择：
- 用户：可以是单个用户，也可以是用户组。
- 资产：可以是单个资产，也可以是资产树节点。
- 系统用户：选择可用于连接这些资产的系统用户。
- 账号：可选，指定资产上的目标账号。
- 命令过滤：可以绑定命令过滤规则，限制危险命令。
授权规则创建完成后，用户刷新 Web 页面，就能在资产列表中看到自己有权访问的资产。
5.5 用户连接资产
用户登录 Jumpserver Web 后，进入“我的资产”或“工作台”，点击资产对应的“连接”按钮，即可打开 Web 终端。也可以使用 Xshell、SecureCRT 等 SSH 客户端连接 Jumpserver：
ssh -p 2222 <用户名>@<Jumpserver-IP>输入 Jumpserver 的用户名密码后，进入交互式菜单，选择要访问的资产序号，即可进入目标资产 Shell。
6. 命令过滤与操作录像审计
部署 Jumpserver 的真实价值，是让运维操作变得可管可控。
6.1 命令过滤规则
在“权限管理 - 命令过滤”中，可以创建命令组，比如“危险命令组”，包含rm -rf、mkfs、dd、shutdown、reboot、kill -9等命令。然后在授权规则中关联该命令过滤规则，动作选择“拒绝”或“允许”。
例如，创建一条规则：当用户登录生产数据库服务器时，禁止执行DROP TABLE，防止误操作。
Jumpserver 的命令过滤支持正则表达式和常见命令匹配，能覆盖大部分场景。需要注意的是，命令过滤只对 Web 终端和 SSH 客户端生效，如果目标资产上有人绕过 Jumpserver 直接登录，那属于网络管控层面的问题，要配合防火墙或安全组限制目标资产的 SSH 来源 IP。
6.2 会话录像
Jumpserver 默认会对 Web 终端连接录制会话录像。管理员可以在“审计台 - 会话记录”中查看已结束的会话，并回放终端操作。这个功能对故障追溯、恶意操作取证非常有用。
在“会话记录”中可以看到会话开始时间、结束时间、用户、资产、协议等信息。点击回放，能看到操作过程中输入过的每一条命令和输出结果。
需要注意，录像文件会占用磁盘空间。生产环境要配置录像清理策略，例如保留 180 天，避免磁盘写满。
6.3 审计报表
Jumpserver 的“审计台”中还提供登录日志、操作日志、命令记录等。管理员可以通过报表了解谁在什么时间访问了哪台服务器。在等保测评或内部安全审计时，这些记录是重要证据。
7. 常见问题与排查思路
部署和日常使用中，以下几类问题出现频率最高。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| Web 页面无法访问 | HTTP 端口未开放，或防火墙拦截 | 检查服务器防火墙、云安全组端口 | 放行 80/8080 端口 |
| 容器反复重启 | 数据库密码或 SECRET_KEY 配置错误 | 查看docker logs jms-core日志 | 修正 .env 后重新docker-compose up -d |
| 连接资产失败 | 目标资产 SSH 端口未开放、IP 填写错误、防火墙限制 | 在 Jumpserver 服务器telnet 资产IP 22测试 | 修改系统用户密码，或放通网络 |
| 无法自动推送系统用户 | 特权用户权限不足，或 SSH 配置禁止 root 登录 | 检查特权用户是否能手动 SSH 到目标机 | 使用有 sudo 权限的账号作为特权用户 |
| 用户看不到资产 | 授权规则未绑定用户、资产或系统用户 | 检查授权规则内容和优先级 | 重新创建完整授权规则 |
| 录像播放失败 | 浏览器兼容或视频格式问题 | 使用 Chrome 浏览器，检查录像文件是否完整 | 更新 Jumpserver 版本，或清理损坏录像 |
新手最容易卡住的点，是“能登录 Jumpserver，但连不上资产”。这里要记住：堡垒机和资产之间必须网络可达，堡垒机连接资产使用的是系统用户，而不是 Jumpserver 普通用户。普通用户只是“你能登录这个平台”，系统用户才是“平台用哪个身份去帮你连目标机”。
如果连接测试报错，优先在 Jumpserver 服务器上手动验证：
ssh -i /opt/jumpserver/data/keys/user.key 系统用户名@目标IP或者用 SSH 命令指定私钥测试，确认是否能免密登录。
8. 最佳实践与生产环境建议
8.1 安全加固
- Jumpserver 服务器只保留必要端口，Web 建议通过 HTTPS 访问，使用 Nginx 反向代理并配置证书。
- 关闭不需要的协议，只用 SSH 端口，避免暴露过多服务。
- 登录 Jumpserver 启用心跳超时，用户长时间不操作自动断开。
- 高危操作尽量走“应用发布”或“工单审批”流程，结合企业 OA 或企微机器人做审批通知。
8.2 账号与资产管理
- 系统用户按业务模块划分，不要所有资产共用一个 root 账号。
- 对 Linux 服务器启用密钥自动推送，减少密码口令存储。
- 数据库资产建议使用独立数据库账号，并配置可执行命令白名单。
- 定期梳理授权关系，清理长期未登录用户和未使用资产。
8.3 存储与备份
- 数据库必须定期备份，建议每天备份，保留多天。
- 录像文件单独挂载到大容量磁盘，并配置定期归档清理。
- 配置文件
.env要注意权限，不要提交到代码仓库中。
8.4 团队协作
- 管理员账号不要多人共用，建议把管理员能力授权给安全专员和运维负责人。
- 日常操作使用普通用户登录，只有需要修改堡垒机配置时才切换到管理员账号，降低误操作风险。
9. 总结与后续学习方向
Jumpserver 部署本身并不难，难的是把“用户、资产、系统用户、授权、命令过滤、审计”这六件事串起来，形成一套可持续运维的访问控制体系。本文通过 Docker Compose 完成了全套部署，也演示了从创建用户到纳管 Linux 资产的操作路径。但部署完只是第一步，生产环境还要结合故障巡检、容量规划、权限定期审计来不断优化。
如果你所在的公司还没有堡垒机，完全可以用 Jumpserver 先在测试环境跑通流程，再逐步接入生产服务器。如果你正准备运维面试，建议把“堡垒机解决了什么问题、Jumpserver 的核心组件、授权流程、命令过滤和录像审计”这几个点整理清楚，这比单纯背命令更能体现运维思维。
后续可以继续深入研究 Jumpserver 的数据库运维功能，比如通过 Web 页面直连 MySQL、Redis 等资源；也可以了解它的应用发布功能，把应用部署和权限审批结合；或者尝试基于 LDAP/AD 统一认证，让员工直接使用企业账号登录堡垒机。无论往哪个方向深入，Jumpserver 都是企业运维安全建设中值得投入时间学习的核心工具。
