如果你手头管着一批 Linux 服务器每天靠 SSH 密码登录、靠一个公共账号在不同人之间传着用那我强烈建议你花一个下午把 JumpServer 部署起来。这东西是飞致云开源的那款堡垒机我前后在测试环境和生产环境各部署过几轮从单机 docker compose 到稍微大点的集群都摸过一遍今天这篇文章就把整个部署过程、踩坑点和原理一次讲清楚。JumpServer 的本质是“运维安全审计系统”通俗说就是给 SSH、RDP、VNC 这些远程运维通道加一道闸门。以前你要登录生产服务器直接从自己电脑 ssh rootip 就进去了中间没有任何管控。有了堡垒机之后你不能再直连服务器只能先连到堡垒机由堡垒机替你转发到目标服务器。这样一来谁、什么时候、用了哪个账号、执行了什么命令、屏幕上发生了什么全部有记录关键操作还能阻断。这个价值在过等保、应付安全审计、多人共管服务器的时候尤其明显。这套系统适合谁如果你是一个几十台服务器的运维、或者创业公司里既写代码又管服务器的全栈工程师再或者学校里做实验环境的老师都很合适。新手也不用怕JumpServer 的部署路径已经做得很成熟了尤其 docker compose 方式基本上复制几段命令就能跑起来。下面我从选型思路开始讲不光是给步骤还会说清楚每一步背后的逻辑这样你以后自己排查问题时心里有底。1. 方案选型为什么我推荐 Docker Compose 而不是源码部署先说结论我个人强烈建议生产环境用 Docker Compose 方式部署 JumpServer除非你被要求必须用 RPM 包装在物理机上。JumpServer 的架构比普通单机 Web 应用要复杂一点。它不是一个单体而是由一个 Web 前端、一个 API 核心服务、负责 SSH 协议转发的 koko 组件、负责 RDP/VNC 转发的 Lion 组件、任务调度 Celery、关系数据库和缓存数据库组成的分布式系统。如果你选择源码部署意味着这些组件都要自己安装、自己配置进程管理、自己处理环境冲突工作量是成倍增加的。而 docker compose 把 nginx、core、koko、lion、mysql、redis 全编排在一个项目里一条 docker compose up -d 就能全部拉起来组件的网络互联、依赖启动顺序都由编排文件处理好了。源码部署的优势是更贴近系统底层出了问题可以直接看进程日志、改 Python 代码调试但这需要你对 Django、Celery、Redis 都有一定掌握而且升级时要手动处理迁移脚本和依赖变更。对于绝大部分团队来说维护一个 docker compose 部署的 JumpServer 已经足够了升级就是拉新镜像、执行迁移脚本回滚也简单改动 image 版本就好。我在生产环境用 docker compose 跑了一年多稳定性很好性能瓶颈主要出现在 MySQL 慢查询和高并发会话数上这跟部署方式无关。另外要提一下的是数据库选型。JumpServer 官方支持 MySQL 和 PostgreSQL默认 compose 文件里用的是 MySQL。测试环境下有人图省事改成了 SQLite我劝你千万别这么做。SQLite 在并发写操作多的时候会频繁锁库操作审计记录、会话日志这种高频率写入分分钟把数据库拖垮。既然 compose 里已经把 MySQL 容器编排好了就没必要自己额外折腾。2. 部署前的准备工作和核心概念2.1 硬件与网络规划JumpServer 本身占用的资源不算多一般建议是 4 核 8G 内存起步磁盘 100G 左右。这个配置不是给 JumpServer 自己用的主要是缓存并发会话录像和日志用的。如果你的团队人很多、一天几百个登录取证那磁盘容量按半年存储量来规划比如 4TB 也不嫌多。网络方面需要注意三点。第一防火墙要放行 80/443 端口因为用户界面的 web 访问走的是 HTTP/HTTPS。第二SSH 连接端口默认是 2222也就是用户用 ssh 连接堡垒机时用的端口不是目标服务器自身的 22 端口。了解这一点很重要很多人配置防火墙时只放行了 80 和 443结果 ssh -p 2222 连不上去然后开始怀疑 koko 组件出了问题。第三JumpServer 所在服务器必须能访问到你管理的那些目标服务器的 22/3389 端口因为它本质上是一个代理所有数据都要经过它转发。如果目标服务器在另一个内网网段那你需要做好路由打通否则会出现能登录堡垒机、但是连不上资产的情况。2.2 理解 JumpServer 几个核心角色在部署之前理解这几个概念会让你后续使用顺畅得多。用户User是指登录堡垒机的人。一个用户可以绑定微信、邮箱、MFA 令牌登录时可以做多因子认证。资产Asset是你管理的目标服务器可以是 Linux 主机、Windows 主机、网络设备、数据库等。资产之上可以分组比如“生产环境 Web 集群”“测试数据库”。资产关联着账号信息这个账号就是真正的系统账号比如 root、oracle、admin。系统用户System User是堡垒机用来登录目标服务器时使用的账号同时又定义了登录方式手动输入密码、托管密码、SSH Key。系统用户和资产绑定在一起就形成了“该资产上具体用什么账号登录”的规则。可以这么理解资产是“我要去哪”系统用户是“我到那了用谁的身份”。授权规则Authorization把用户、资产、系统用户三者绑定同时可以指定访问时间窗口和命令过滤规则。用户访问任意资产必须要有对应的授权规则否则即使账号密码都对也会被堡垒机拒绝。这四个概念你一定要记住后面所有操作都围绕它们展开。我见过不少人在部署完成后卡在“能登录堡垒机但是点资产没反应”其实就是没弄清楚系统用户和授权规则之间的关系。3. 使用 Docker Compose 完成 JumpServer 部署3.1 准备环境与下载编排文件我这里假设你已经装好了 Docker 和 docker compose 插件。环境我用的是 Ubuntu 22.04但步骤在 CentOS 上基本也一样只是包管理命令不同。没有 Docker 的话先执行以下命令安装# Ubuntu / Debian curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo systemctl enable --now docker # 安装 compose 插件 sudo apt-get install -y docker-compose-plugin接下来克隆 JumpServer 的部署项目。官方把 docker compose 的编排文件和初始化配置都放在 GitHub 的 jumpserver/installer 仓库里cd /opt git clone https://github.com/jumpserver/installer.git cd installer如果你所在的网络访问 GitHub 很慢也可以从国内 Gitee 的镜像仓库拉取。拉下来之后你会看到目录里有一堆以 current 命名的文件比如 .env 的示例文件 config_example、nginx 配置文件等。重点说一下 .env 这个文件它是整个部署的风向标所有关键参数都在这里配置。3.2 配置 .env 文件的几个关键选项以下是我认为必须认真设置的几个配置项我会把每个参数背后的含义说清楚。SECRET_KEY 是 Django 加密签名用的密钥必须修改不能使用默认值否则一旦默认值泄露别人可以伪造会话和加密数据。我们可以用 openssl 随机生成openssl rand -base64 48把生成的一长串字符串填到 SECRET_KEY 这一行。这个 key 要保存好如果丢了或者改动后之前加密的数据比如部分密码、会话信息将无法解密用户只能重置密码。我在升级版本时踩过这个坑备份 .env 文件是必须养成的习惯。BOOTSTRAP_TOKEN 是各组件向 core 服务注册时用的 token同样需要自己生成。它跟 SECRET_KEY 一样改动后组件重启可能会互相认证失败所以备份和环境一致性要格外注意。DOCKER_IMAGE_PREFIX 一般保持默认即可国内访问 Docker Hub 无法拉取镜像的时候可以改成阿里云上同步的镜像仓库地址。如果你用 docker compose 启动时发现镜像一直拉不下来优先检查网络然后考虑切换这个前缀。3.3 启动服务与初始化编辑完 .env 之后执行启动命令# 初始化配置生成 docker-compose.yml bash jmsctl.sh init # 启动整个服务 bash jmsctl.sh start # 查看服务状态 bash jmsctl.sh status第一次启动会拉取 nginx、core、koko、lion、mysql、redis 这些镜像耗时取决于网络。启动完成后通过 docker ps 查看所有容器的状态应该看到各个容器都是 up 状态。这里有一个要求core 和 koko 这两个容器必须保持 running如果某个容器不断重启多半是 .env 文件里的 BOOTSTRAP_TOKEN 或 SECRET_KEY 有问题导致组件之间无法建立信任关系。初始化完成后打开浏览器访问 http://你的服务器IP第一件事是注册管理员账号创建完管理员后默认自动登录。用管理员账号登录以后你需要立刻进入“系统设置”修改管理员密码并开启 MFA这里不要偷懒默认密码直接上生产环境等出了安全问题再后悔就晚了。4. 首次配置把管理员体验走通4.1 用户创建和 MFA 配置登录管理员界面后首先到“用户管理”里创建业务用户。可以是一次建一批也可以对接企业 LDAP 实现自动同步。如果你有 AD 域环境强烈建议在“系统设置”里配置 LDAP 对接这样可以做到离职自动禁用账号减少账号残留风险。MFA 是另外一件不能省的事。JumpServer 支持 TOTP 动态口令可以在手机上装一个 Google Authenticator 或者 FreeOTP。在“安全设置”里把登录校验策略调成“开启 MFA”建议把“管理员强制开启 MFA”也打开强制到管理员这一层防钓鱼账号泄露。这个功能实测下来好用在真实环境里就算账号密码不小心被截获攻击者没有手机 Token 也进不来。4.2 添加资产、系统用户和授权规则以添加一台 Linux 服务器为例。进入“资产管理 资产列表”选择创建主机填入主机名、IP、协议 SSH、端口 22。然后是系统用户点击创建系统用户名称随便起比如“prod-root-auto”登录方式选“自动登录”用户名/密钥填 root SSH Key 或者 root 密码。系统用户这个概念第一次接触会有点绕但它的设计意图是很好的可以针对不同资产使用不同的系统账号和认证方式权限控制很细。接下来到“授权管理 授权规则”创建授权。规则的核心是一个三元组哪些用户、哪些资产、哪些系统用户。比如我的规则是用户组“运维组”、资产组“生产集群”、系统用户“prod-root-auto”登录时间窗口设为工作日 9:00-18:00。这样配置好之后运维组的人在工作时间才能通过堡垒机登录到生产集群服务器其余时间一律拒绝。命令过滤也可以在这个规则里配置比如禁止执行 rm -rf /、reboot、shutdown 等危险命令。配置完这条授权规则后从普通用户的角度测试一下。用创建的普通用户账号登录 JumpServer Web 界面进入“我的资产”能看到授权的服务器列表点击右上角“Web 终端”就能打开一个网页版 SSH 终端直接进入目标服务器。整个过程不需要知道目标服务器的 root 密码因为堡垒机帮我们托管了。这就是堡垒机最核心的价值用户完全碰不到服务器真实密码所有操作被记录且受控。5. 常见问题排查与避坑实录5.1 能访问 Web 界面但“Web 终端”一直连不上目标服务器这个现象我遇到最多。操作顺序是先确认平台能正常登录然后在“我的资产”里点击 Web 终端页面卡在连接中或者提示 connect refused。排查路径是第一确认 luna 容器、koko 容器是否正常运行如果 koko 容器挂掉终端连接直接无法建立。第二从堡垒机这台机器上测试能否 ssh 到目标服务器直接在命令行执行 ssh root目标IP如果手动都不通说明是网络或防火墙问题跟 JumpServer 无关。第三检查 koko 日志里的报错docker logs koko 命令一定要熟练里面通常能看到明显的 connection refused 或者 timeout 记录。我遇到过最坑的一个情况是目标服务器安全组限制了来源 IP 白名单只放行了运维办公网的 IP没放堡垒机内网 IP导致堡垒机根本无法访问这台服务器。这种情况在云服务器上尤其常见一个安全组策略就让整体链路走不通排查时一定要先把目标侧的访问控制检查了。5.2 执行操作卡顿、命令响应慢JumpServer 是基于 WebSocket 代理转发的命令在网络传输中有额外的中转节点相比直连 SSH 多了一跳延迟。如果体感明显变慢先看服务器负载是否过高。koko 和 core 容器都吃 CPU如果是交换内存不够了也会拖慢整个平台。还有一种隐藏原因MySQL 慢查询。JumpServer 在每次操作时都会写入审计日志如果数据库盘 I/O 瓶颈或者 MySQL 参数没有优化过越来越多的会话记录会让插入越来越吃力。排查手段是看 mysql 容器里的慢查询日志把 long_query_time 调低一些看看哪些查询拖了后腿。生产环境如果并发大建议把 MySQL 迁移到独立实例或独立物理机而不是跟 JumpServer 挤在同一台机器上。5.3 会话录像缺失或者打不开录像文件默认存放在本地具体路径在 .env 中由 VOLUME 来指定比如 /opt/jumpserver/core/data。录像文件缺失有几个常见原因磁盘满了文件写入失败存储路径被修改导致容器找不到旧文件或者录像文件被手动清理了。实际操作中磁盘满是最容易出现的尤其录像文件都不小一天几十次登录就能吃掉几个 G。另外一个容易忽略的坑容器重启后某些老录像文件在页面上打不开先别急着删数据库记录去服务器上确认文件真实位置再用命令行播放器测试一下。很多时候文件还在只是路径配置漂移了。5.4 升级 JumpServer 版本时的注意事项升级之前必须做两件事备份数据库和备份 .env 文件。JumpServer 官方文档提供了升级脚本但生产环境的数据库备份永远是第一位。我在一次升级中遇到过 Django migration 执行失败导致 core 容器起不来最后是靠 MySQL 备份恢复数据才抢救回来。升级操作建议在低峰期进行执行完 jmsctl.sh upgrade 之后盯着日志看有没有 error再检查所有容器状态。另外升级后一定要快速做一次冒烟测试登录 Web 界面、打开终端连一台测试机、执行几条命令确认操作审计正常。版本大版本升级比如从 v2 升 v3的坑比较多升级前最好先在同版本环境里试一次或者在公司测试环境跑一遍完整流程再上生产。6. 日常运维经验让堡垒机跑得更顺当你把 JumpServer 部署完、配置完授权规则之后它已经可以正常工作了但日常运维才是长期的事。下面分享几个我实际用下来觉得很有价值的经验。第一关于密码托管的安全性。系统用户可以选择“手动输入密码”或“自动登录”自动登录意味着堡垒机存储目标服务器的密码采用的是加密存储但这个密码仍然暴露在配置文件里所以你的 .env 文件权限一定要保护好备份文件也要加密存放。能用 SSH Key 托管的尽量用 Key这样即使堡垒机数据库被拖走至少 Key 私钥还有一层保护。第二MFA 和密码策略不要嫌麻烦。有同事觉得每次登录要输验证码麻烦偷偷把 MFA 关了这其实就是把堡垒机变成了一个普通的跳板机。我长期的做法是提前在岗前培训里强调账号安全的意义同时在安全设置里把 MFA 设为强制让系统层面根本没有关闭的入口。第三审计日志要定期导出归档。JumpServer 的操作审计记录和录像文件会随着时间增长变得非常大需要制定一个定时备份和清理策略例如每个月导出一次三个月自动清理本地录像。如果不做清理最终你会发现存储被撑爆审计功能反而名存实亡。第四高可用问题。单机部署的 JumpServer 最大的风险是机器挂了导致所有人都进不了服务器。如果条件允许可以部署多套 JumpServer 做负载均衡但这会引入数据同步的复杂度。更轻量的方案是给堡垒机纳入公司备份体系定期备份 MySQL 和关键配置文件至少保证数据不丢、能快速恢复。第五留意版本迭代和官方公告。JumpServer 社区更新很活跃安全问题修复也很快建议订阅官方 release 页面不要再评论区问“为什么我的版本用不了这个功能”先检查版本是否过旧。7. 最后的建议我在多个环境里部署 JumpServer 后最深的感受是它的部署难度真的不高真正有门槛的是配置思路。如果你只是把服务器和授权规则搭起来那它只是一个增加了一层的 SSH 入口只有当你把用户权限最小化、危险命令过滤规则配全、强制启用 MFA、定期检审计记录它才真正起到了安全审计的作用。有一个小技巧想分享给前端刚接触堡垒机的朋友别急着在全部资产上启用命令过滤先拿一台测试服务器跑通整个流程。从创建资产、创建系统用户、创建授权规则到用户登录、连资产、看操作审计整个过程完整走一遍之后再逐步推广到生产环境。这样即使误操作影响面也只是在一台测试机上。后续你还可以尝试把 JumpServer 接入已有的工单系统在授权规则上做到“有工单才可访问”审计关联工单号。这个玩法在精细化管理要求比较高的团队里很实用我已经在推进了。希望这篇部署记录能帮你少踩一些坑有部署上的问题也可以多翻翻官方文档回复慢归慢但它确实是目前最完整的参考。