企业运维普遍会引入 Jumpserver 堡垒机因为服务器分散、账号多、权限边界不清晰只要有人登录过生产机器后期几乎无法确认“这台服务器当时是谁操作的、执行了什么命令、看到了什么文件”。Jumpserver 解决的就是这类问题把登录入口、用户身份、资产账号、授权规则和操作录像统一收口形成一套可追溯的运维审计链路。对刚入行运维的同学来说先学会部署一套最小可用的 Jumpserver 环境再接入一台 Linux 资产并验证录像回放是理解企业级安全审计比较直接的一条路径。下面从概念开始先讲清楚堡垒机为什么存在再带你把 Jumpserver 用 docker-compose 方式部署到 Linux 上接入第一台 Linux 资产然后验证 SSH 登录、会话录像和命令审计最后给出生产环境落地和常见问题排查建议。1. 先理解 Jumpserver 在企业运维里到底解决什么问题很多同学第一次接触堡垒机时会觉得它只是“多了一层登录入口”但真实场景里它解决的问题要细很多。1.1 堡垒机不是“多一层登录”这么简单在没有堡垒机时团队里的 Linux 服务器通常是这样管理的root 或其他管理员账号直接分给多个同事密码长时间不换。某台服务器被误操作后不知道是谁执行的命令。现场排障时为了图方便直接关闭审计连日志都没有。离职员工的账号没有及时清理生产权限始终存在。堡垒机改变的是这个流程所有运维人员先登录堡垒机再由堡垒机与目标资产建立会话。用户不会直接接触资产的真实密码操作记录会自动落到审计模块里。Jumpserver 是其中应用比较广泛的开源实现支持 SSH、RDP、数据库、Kubernetes 等多种资产接入社区活跃度也高。对企业来说堡垒机的价值不只是“管住入口”而是让每一次登录都有身份、有时间、有命令记录、有视频回放最终能形成一条完整的审计证据链。1.2 Jumpserver 的核心组件与一条登录链路Jumpserver 采用前后端分离和组件化设计。使用 docker-compose 部署时并不是只有一个容器而是一组容器协作。常见组件如下组件作用常见容器名Web前端页面和 API 入口jms_webCore核心逻辑负责认证、授权、审计数据写入jms_coreCelery异步任务处理录像、通知、资产同步等jms_celeryGuacamole负责图形协议和字符协议接入jms_guacamoleNginx前端入口和静态资源分发jms_nginxMySQL存储用户、资产、授权、审计元数据jms_mysqlRedis缓存和任务队列jms_redis一条典型的登录链路是这样的用户浏览器先访问 Web 页面Nginx 把请求交给 WebWeb 调用 Core 完成身份认证用户发起连接资产后Web 向 Core 申请会话Core 校验授权规则再通过 Guacamole 与目标资产建立连接整个会话过程中的命令和录像会异步写入数据库和文件存储。理解了这条链路后面排错时就会很清楚页面打不开先查 Nginx登录失败看 Core录像迟迟不生成则要查 Celery 和 Redis。1.3 典型使用场景Jumpserver 并不只有大厂才需要。常见的落地场景包括多台 Linux 服务器需要统一管理运维同学不再共享同一个 root 密码。有第三方人员需要临时登录生产环境但不想把系统账号直接交给对方。为了通过等保或其他安全审计要求需要保留登录记录和操作录像。同时管理云服务器、自建机房服务器和混合云环境希望有一个统一的资产入口。需要审计的不只是 SSH还包括 RDP 远程桌面和部分数据库连接。需要注意一个常见误区堡垒机用户不是目标 Linux 系统上的用户。堡垒机里的“普通用户”是平台登录身份真正登录资产时使用的是“资产账号”。这个概念后面配置授权时会直接影响功能是否生效。2. 部署前先确定版本、硬件、端口和网络边界部署 Jumpserver 前先不要急着敲安装命令。版本、硬件、端口和网络规划如果不对后面很容易出现“容器起来了但访问不了”“资产连不上”“录像丢失”这类问题。2.1 版本和安装包怎么选Jumpserver 更新速度比较快。生产环境不建议使用 GitHub 上的 master 分支而应该选择官方 Releases 页面中的一个稳定版本。常见安装方式有两种在线安装服务器能够访问外网执行官方脚本或命令时自动下载镜像。离线安装把官方发布包下载后拷贝到内网服务器适合网络隔离环境。离线安装包的名字通常类似jumpserver-offline-installer-vX.Y.Z-amd64.tar.gz jumpserver-offline-installer-vX.Y.Z-arm64.tar.gz如果服务器是 x86 架构就选 amd64如果服务器是 ARM 架构就选 arm64。查看 CPU 架构可以用uname -m输出x86_64时选 amd64 包输出aarch64时选 arm64 包。2.2 硬件和操作系统要求Jumpserver 单机部署对硬件要求并不算高但具体内存占用会随在线会话数、录像时长和并发量增长。以下是适合学习和小规模团队的参考配置项目学习环境最低小规模生产推荐CPU2 核4 核及以上内存4 GB8 GB 及以上系统盘50 GB100 GB 及以上数据盘无需单独规划建议单独挂载用于存储数据库和录像操作系统Ubuntu 20.04 / CentOS 7 或同类Ubuntu 22.04 / Rocky Linux 9 或同类如果资产数量多、录像保留时间长数据盘要预留更大空间。录像文件默认会落在本机存储目录中生产环境还要考虑定期清理或转存到独立存储。2.3 端口规划Jumpserver 安装后默认需要保留两个对外端口常用的映射方式是端口用途建议8080Web 访问 https 页面和 API对办公网开放2222SSH 命令行登录堡垒机对运维网段开放内部还会用到 MySQL 3306、Redis 6379 等端口但这些是容器之间通信使用的不要直接映射到公网。云服务器安全组和本机防火墙都应当只放行必要端口。防火墙配置示例以 firewalld 为例firewall-cmd --permanent --add-port8080/tcp firewall-cmd --permanent --add-port2222/tcp firewall-cmd --reload如果使用云平台还要在控制台的安全组中同步放行。2.4 网络边界和基线检查部署前还要做两件事确认服务器时间同步正常。审计日志一旦时间错乱录像和命令记录会失去可信度。建议执行timedatectl set-ntp true开启时间同步。确认堡垒机与待纳管资产网络互通。如果堡垒机无法访问资产 IP后面配置再正确也连不上。生产环境建议把堡垒机放在独立的管理网段只允许运维网段访问 8080 和 2222不能把 MySQL、Redis 等内部服务暴露在公网。3. 用 docker-compose 完成最小化部署部署步骤的核心是使用官方安装包生成的 docker-compose 编排文件。手动逐个启动容器也可以但官方安装脚本会统一处理目录、密钥、数据库初始化和服务依赖更适合第一次安装。3.1 安装 Docker 和 Compose 插件先安装 Docker。常见做法是使用 Docker 官方安装脚本下载后先检查内容再执行curl -fsSL https://get.docker.com -o get-docker.sh sh get-docker.sh systemctl enable --now docker安装完成后确认版本docker --version docker compose version如果环境里只有旧版docker-compose命令也可以使用docker-compose --version确认。新版 Jumpserver 安装脚本通常要求docker compose插件。3.2 下载发布包并进入安装目录下载发布包前先到 Jumpserver 官方 Releases 页面确认需要安装的版本号。下面的命令使用占位符vX.Y.Z实际执行时替换成你在 Releases 页面看到的版本号cd /opt JUMP_VERSIONvX.Y.Z wget https://github.com/jumpserver/jumpserver/releases/download/${JUMP_VERSION}/jumpserver-offline-installer-${JUMP_VERSION}-amd64.tar.gz tar xf jumpserver-offline-installer-${JUMP_VERSION}-amd64.tar.gz cd jumpserver-offline-installer-${JUMP_VERSION}-amd64如果你使用的是 ARM 服务器把文件名中的amd64改成arm64。3.3 检查环境并执行安装进入安装目录后先执行环境检查确认 Docker、端口、磁盘等条件满足要求./jmsctl.sh check检查通过后执行安装./jmsctl.sh install安装过程中脚本会生成 docker-compose 文件并启动服务。安装完成后使用下面的命令启动并查看状态./jmsctl.sh start ./jmsctl.sh status如果status输出显示各个服务为 running 状态说明进程层面已经起来了。此时可以先不着急访问页面先确认关键容器是否正常。3.4 理解 config.env 关键配置安装包会在环境中生成一个config.env文件里面保存了基础配置。常见字段如下字段含义说明DOCKER_DIR数据目录默认存放数据库数据、录像、日志生产环境建议放到独立数据盘HTTP_PORTWeb 访问端口默认 8080SSH_PORTSSH 登录端口默认 2222MYSQL_DATABASE数据库名安装脚本自动生成MYSQL_USER数据库用户安装脚本自动生成MYSQL_PASSWORD数据库密码生产环境必须修改为强密码SECRET_KEY核心签名密钥用于敏感信息加密安装后不要随意修改BOOTSTRAP_TOKEN组件间通信令牌用于核心组件鉴权如果需要重新生成随机密钥可以这样操作openssl rand -base64 50把输出的字符串填到config.env的SECRET_KEY字段中。BOOTSTRAP_TOKEN同理openssl rand -base64 24重要提示安装完成并已经写入数据后不要随意修改SECRET_KEY和数据库密码。这两个配置一旦变化已有用户密码和会话数据可能无法解密导致服务虽然启动但登录失败。如果是在内网离线环境安装镜像需要提前准备好。离线安装包通常自带镜像导入脚本具体以官方安装文档为准。3.5 查看容器状态和日志安装完成后用docker ps可以直观看到容器列表docker ps正常情况下会看到 jms_nginx、jms_web、jms_core、jms_celery、jms_guacamole、jms_mysql、jms_redis 等容器。看到jms_core反复重启时不要急着重新安装先看日志docker logs --tail 200 jms_core日志是定位安装问题的第一入口。后续不管遇到登录失败、录像不生成还是资产连不上都应该先看对应容器的日志。4. 初始化管理员并接入第一台 Linux 资产服务安装完成只是第一步接下来要在 Web 页面里把用户、资产、授权这组关系配好。4.1 首次 Web 初始化在浏览器中访问http://服务器IP:8080不同版本的 Jumpserver 首次访问流程略有差异。有的版本会直接进入初始化页面要求创建管理员有的版本默认管理员账号是admin初始密码通常会在安装界面中提示常见的是ChangeMe登录后系统会要求修改。以实际安装版本页面的提示为准。首次登录后建议马上完成以下几件事修改管理员密码。确认系统时间显示正确。如果系统支持 MFA先为管理员开启动态口令认证。进入“用户管理”确认默认组织存在。4.2 创建普通用户、资产和资产账号要让一个真实运维人员通过堡垒机登录服务器需要依次创建四个核心对象普通用户这是登录堡垒机的平台账号不是服务器上的 Linux 账号。资产需要被纳管的服务器比如一台 IP 为192.168.1.10的 Linux 机器。资产账号服务器上真实存在的 SSH 登录账号比如ubuntu、deploy或root。授权规则把用户、资产、资产账号绑定在一起。在 Web 页面中的大致路径如下用户管理 - 用户列表 - 创建用户填写用户名、姓名、邮箱、密码角色选择“普通用户”。资产管理 - 资产列表 - 创建资产类型选择 Linux填写 IP192.168.1.10协议选择 SSH端口填写22系统平台选择 Linux。进入资产详情页在“账号”标签页添加真实登录账号认证方式可以选择密码或 SSH 私钥。访问权限 - 资产授权 - 创建授权规则选择刚才创建的用户、资产和资产账号。这样一来用户登录堡垒机后才能看到并访问这台 Linux 资产。4.3 授权关系必须完整缺一个都看不到资产如果普通用户登录堡垒机后看不到任何资产大概率是授权关系不完整。最容易出错的点是只创建了用户和资产但没有在资产详情里添加“资产账号”或者授权规则里没有勾选资产账号。用表格表示这层关系对象作用缺失后果普通用户登录堡垒机平台用户无法登录平台资产被纳管服务器用户看不到资产入口资产账号真实 Linux 登录凭据即使看到资产也无法建立会话授权规则把前三者绑定普通用户登录后资产列表为空很多教程只写“创建用户”和“添加资产”容易忽略“资产账号”和“授权规则”。实际上后者才是决定普通用户能不能真正使用堡垒机的关键。4.4 用 Web 终端验证登录配置完成后可以先用 Web 终端做一次最小验证用普通用户在浏览器登录 Jumpserver。进入工作台打开 Web 终端。选择授权给你的 Linux 资产。如果资产账号已经配置好堡垒机会自动使用该账号与目标服务器建立会话。如果能看到服务器命令行提示符并且输入hostname、ip addr等命令有正常返回说明资产接入链路已经打通。4.5 用 SSH 命令行验证登录Web 终端能登录后再验证命令行方式。普通用户可以从自己电脑上执行ssh -p 2222 zhangsan堡垒机IP这里的zhangsan是堡垒机里的普通用户不是 Linux 系统用户。登录后会看到可访问资产列表输入对应序号即可进入目标服务器。需要注意此时虽然连接命令写的是堡垒机地址但会话建立后你在终端里操作的已经是目标 Linux 资产。这个过程由堡垒机统一接管用户不会直接接触资产明文密码。注意如果登录堡垒机后一直提示“没有可访问的资产”不要反复删除重建资产先检查授权规则是否把用户、资产、资产账号三者都包含进去。5. 验证审计链路录像、命令和会话记录部署堡垒机的最终目的是审计。只做到能登录还不够必须验证登录后产生的录像、命令记录和会话日志确实被保存下来。5.1 会话录像怎么回放登录操作完成后进入 Web 页面找到“审计”或“会话审计”入口在会话列表里可以看到刚才那条 SSH 连接记录。点击详情或回放按钮可以查看操作过程的录像。验证录像时建议做三个动作在目标服务器执行whoami。执行cat /etc/os-release。执行history查看对话内容。然后回到 Jumpserver 会话审计页面确认会话记录里能显示操作时间、操作用户、目标资产并且录像可以正常播放。如果录像无法播放常见原因是浏览器兼容性推荐使用 Chrome 或 Edge。如果录像文件根本没有生成则要查jms_celery容器日志和存储目录的磁盘空间。5.2 命令审计与高危命令过滤Jumpserver 除了提供录像回放还会记录会话中执行过的命令。可以在“命令审计”里按用户、资产、时间段过滤。如果想把高危命令直接拦截可以在访问权限中配置“命令过滤器”。例如可以在命令过滤器里添加规则规则名称: 禁止删除根目录 匹配命令: rm -rf / /var 动作: 拒绝当普通用户执行这条命令时堡垒机会直接阻止并在审计日志中留下记录。命令过滤是生产环境最常用的安全策略之一建议不要把拦截规则设计得过于宽松否则误伤正常运维操作。5.3 文件传输和登录日志堡垒机接入 SSH 资产后通常会记录文件传输行为。如果运维人员通过 SFTP 上传或下载文件审计模块会保留传输记录。登录日志则记录了每次登录成功或失败的时间、来源 IP、用户账号、目标资产。这些日志在排查“谁在生产环境留下了后门”“哪个账号异常登录”时非常有用。建议在部署完成后专门用错误密码登录几次确认登录失败也会有记录。5.4 审计证据如何保存单机环境的录像默认存放在堡垒机数据盘中。如果服务器磁盘损坏录像和数据库会一起丢失。生产环境至少要做到定期备份数据库保证用户、资产、授权元数据可恢复。定期导出会话录像和命令日志到独立存储。根据企业安全合规要求设定保留周期避免无限占用磁盘。验证备份是否可用比执行一次备份更重要。备份做完后要至少验证一次恢复流程不能等出故障后再发现备份文件不可用。6. 部署后最常遇到的问题与排查链路Jumpserver 部署过程中很多问题不是配置复杂造成的而是容器状态、端口、网络和授权关系没有对齐。下面按现象列出排查链路。6.1 先按这条链路检查遇到问题优先按以下顺序排查容器是否都在运行docker ps。访问端口是否放行ss -lntp | grep 8080。浏览器访问的协议和端口是否正确。相关容器日志是否出现异常关键字。资产网络是否可达在堡垒机本机执行ping或nc -vz 资产IP 22。授权规则是否包含用户和资产账号。不要一上来就重装系统或删除容器。大多数故障都可以通过“看日志、查端口、验授权”定位。6.2 问题现象、原因和处理问题现象常见原因检查方式处理建议页面打不开Nginx 容器未启动、端口被占用、防火墙未放行检查docker ps和ss -lntp放行 8080 端口查看 jms_nginx 日志jms_core 容器反复重启SECRET_KEY、数据库密码不匹配或镜像与版本不一致查看 jms_core 容器日志确认 config.env 配置必要时恢复备份后重启普通用户登录后没有资产用户、资产、资产账号未授权组织不一致检查授权规则和用户所在组织重新创建授权规则确认三要素都被选中资产连接超时或连接被拒绝目标资产关机、SSH 端口不通、网络隔离在堡垒机执行nc -vz 资产IP 22修复网络或修改资产端口没有会话录像会话不是通过堡垒机建立Celery 未处理存储路径不可写查 jms_celery 日志和磁盘空间确认所有登录入口都走堡垒机修复存储命令审计为空用户没有操作或授权规则未关联审计策略确认普通用户执行过命令重新建立会话并执行简单命令验证6.3 关键时刻看日志日志关键字是定位问题的核心线索。常用命令docker logs --tail 200 jms_web docker logs --tail 200 jms_core docker logs --tail 200 jms_celery docker logs --tail 200 jms_guacamole例如当出现资产连接失败时jms_core日志里通常会记录目标地址、端口和错误原因。当录像不生成时jms_celery日志里可能会出现任务处理失败的堆栈。6.4 升级与回滚升级前必须做两个准备对服务器磁盘创建快照。执行一次堡垒机自身的备份命令常见是./jmsctl.sh backup升级后不要只登录页面看版本号还要完整验证一遍普通用户登录、SSH 登录、会话录像和命令审计。如果发现升级后的自定义配置丢失或功能异常可以通过./jmsctl.sh help查看恢复命令并使用升级前备份恢复。7. 生产环境落地建议与扩展方向单机部署跑通只是起点。真正交付给企业使用还需要围绕安全、备份、高可用和账号生命周期做更细致的设计。7.1 从单机演示到生产要补齐的能力能力项说明建议HTTPSWeb 页面走明文风险高通过域名和证书把 8080 封装成 HTTPS 入口MFA普通账号泄露后仍可登录开启 OTP 动态口令密码策略弱密码是审计风险强制密码长度、复杂度、定期改密备份恢复数据库和录像都重要备份文件要异地保存并定期演练恢复监控告警堡垒机本身故障没人知道监控容器、端口、磁盘和核心服务心跳网络隔离堡垒机权限过高时风险更大只允许必要网段访问避免公网直接暴露录像保留策略录像占用磁盘且不可无限增长按合规要求设置保留周期和自动归档7.2 权限模型规范化生产环境使用堡垒机的核心原则是最小权限。不要给所有普通用户分配 root 资产账号。常见做法是资产账号使用低权限用户比如deploy、app。需要临时提权时在目标系统上配置 sudo 规则并让堡垒机记录对应命令。授权规则按项目、环境、时间段拆分避免“一个授权规则包含所有资产”。人员离职时先撤销堡垒机账号再检查他名下的授权规则和资产账号是否清理干净。这些规则没有配置进去时堡垒机只能提供“能登录”的能力无法真正收敛风险。7.3 对接外部系统Jumpserver 的生产使用往往不是孤岛。常见的扩展方向包括对接 LDAP、AD 或 OAuth2让用户使用企业统一身份认证登录堡垒机。对接 CMDB自动同步服务器资产清单避免手工维护漏配。对接云平台 API实现云服务器资产的自动纳管和标签同步。对接工单或审批系统把高危资产申请流程和授权规则联动。对接集中日志平台把堡垒机审计日志同步到 SIEM 或日志系统中。这些扩展依赖具体版本和部署方式落地前需要先确认目标版本是否支持相应协议或插件。7.4 上线前检查清单把本次部署作为一次交付时可以拿着下面这份清单逐项确认[ ] 服务器时间已同步审计时间可信。[ ] 防火墙只放行 8080 和 2222内部数据库端口不对外。[ ] 管理员密码已修改MFA 已开启。[ ] 至少创建了一个普通用户。[ ] 至少添加了一台 Linux 资产并在资产详情中配置了资产账号。[ ] 创建了授权规则普通用户登录后能看到该资产。[ ] 使用普通用户通过 Web 终端成功登录。[ ] 使用ssh -p 2222方式成功登录。[ ] 会话审计中有录像命令审计中有命令记录。[ ] 高危命令过滤器已配置或至少已确认默认策略。[ ] 执行过备份并把备份文件拷离当前服务器。[ ] 升级和回滚方案已记录关键时刻不会手忙脚乱。对新手来说建议不要一开始就追求高可用和复杂网络架构。先在虚拟机上完成单机部署把用户、资产、授权和审计这条链路跑通再逐步加入 LDAP、CMDB、HTTPS、外部存储和备份恢复。堡垒机这类工具只有在真实操作和故障复盘中被反复使用才能发挥出审计价值。