做运维这些年我最大的一个感受是故障不可怕查不到原因才可怕。第一次被“无审计”逼到抓狂是一次数据库误操作之后日志里只有一堆难以分辨的连接来源根本说不清是谁、从哪台机器、执行了什么命令。后来我把 JumpServer 堡垒机部署进了测试和生产环境才把“谁能连、连什么、干了什么、能不能回放”这条链路彻底拉通。这篇文章专门聊 JumpServer 的部署与应用重点不是背文档而是把实际操作里踩过的坑和验证过的做法写出来给准备上堡垒机的团队一个可以直接参考的版本。1. 部署前先想清楚JumpServer 到底解决什么问题1.1 运维审计为什么不能靠自觉堡垒机的本质是把所有运维访问收拢到一个统一入口。人在接触服务器之前必须先经过堡垒机的身份认证、权限校验和行为审计。没有堡垒机的时候运维直接 SSH 到服务器账号密码分散在个人手里离职不改密、误操作无记录、多人共用 root 账号都是常态。上了堡垒机以后服务器上的真实口令可以集中到一个受管账号对使用者隐藏每次连接都从统一入口走入口把连接时间、来源 IP、目标资产、执行命令、会话录像全部记录下来。JumpServer 是我用得最多的一套开源堡垒机方案。相比商业产品它没有按资产数量计的授权成本部署上又是 Docker Compose 组合社区文档也够全。当然它不是唯一选择但胜在足够透明出了问题我能自己翻日志排查这是最让我放心的一点。1.2 部署形态与组件选型如果能理解 JumpServer 大概由哪几部分组成后面排障会轻松很多。简单说用户看到的 Web 界面是前端core 负责用户、资产、授权、审计这些核心数据koko 负责 SSH、SFTP 这类文本协议接入和转发guacamole 负责 RDP、VNC 这类图形协议数据库连接场景还会有对应的数据库代理组件。安装脚本会把它们编排成一个 Compose 项目统一用jmsctl脚本管理。所以它在部署上并不复杂但对服务器性能和网络规划有要求。组件之间用容器内部网络通信对外主要暴露 Web 端口和 SSH 接入端口。如果团队资产规模不大一台 4 核 8G 的机器就能跑起来资产多了再按 CPU、磁盘逐步加规模。2. 环境准备与安装实操2.1 服务器配置建议不要拿最低配置硬扛生产环境。JumpServer 的多个组件同时跑内存吃紧时 core 或 koko 会反复重启表面症状是网页打不开或连不上资产。我给不同规模做个参考使用场景推荐配置说明20 台以内测试2 核 4G勉强能跑建议只做功能验证100 台左右生产4 核 8G大多数中小团队够用200 台以上生产8 核 16G并发会话多时更稳妥大量 RDP 图形会话8 核 16G 起步图形协议比文本协议更吃 CPU操作系统建议选 Debian 11/12 或 Ubuntu 22.04 LTSx86_64 架构。CentOS 7 还能跑但基础组件太老新项目没必要再往旧坑里跳。磁盘方面会话录像是主要消耗点按并发规模算建议给录像数据单独预留足够空间最好挂独立数据盘。2.2 一键安装脚本和目录规划官方提供一键安装脚本会自动装 Docker、Docker Compose 插件并拉取相关镜像。我的习惯是先把脚本下载到本地看完内容再执行毕竟用管道直接跑外部脚本属于高风险操作团队有安全要求的话更应该先审阅。cd /root curl -O https://github.com/jumpserver/installer/releases/download/v3.10.7/quick_start.sh chmod x quick_start.sh bash quick_start.sh网络不太好的环境也可以在官方安装包页面下载离线版本原理一样。默认部署目录是/opt/jumpserver数据存放在/opt/jumpserver/data。这里要特别注意尽量在部署前规划好数据盘挂载不要在初始化完成之后再挪目录。容器编排里的路径是按绝对路径生成的乱动目录会导致组件找不到数据。安装过程中需要开放的端口主要有三个Web 访问端口默认 80/443SSH 接入默认映射到 2222 左右。如果服务器开了防火墙提前把这些端口放通不然安装完才发现网页访问不了还得回头查防火墙规则。2.3 初始化配置文件里的关键参数脚本执行完成后会生成一个配置文件/opt/jumpserver/config.txt。别急着启动先把必填项改好。这个文件里最重要的几类参数是加密密钥、数据库连接、Redis 连接、对外访问地址。cd /opt/jumpserver vi config.txt值得反复强调的是SECRET_KEY和BOOTSTRAP_TOKEN一定不要用默认值。默认值等于是把钥匙放在门口谁都能捡起来。可以用下面的命令生成随机字符串openssl rand -base64 32 head /dev/urandom | tr -dc A-Za-z0-9 | head -c 50配置片段大致长这样SECRET_KEY随机生成的一长串字符 BOOTSTRAP_TOKEN随机生成的一长串字符 DB_HOSTmysql DB_PORT3306 DB_USERjumpserver DB_PASSWORD你自己定义的密码 DB_NAMEjumpserver REDIS_HOSTredis REDIS_PORT6379 REDIS_PASSWORD PUBLIC_URLhttp://你的服务器IP或域名如果使用脚本自带的内置 MySQL 和 Redishost 就填mysql、redis这是容器内部的网络名称。如果公司要求数据库独立部署就把 host 改成实际数据库地址同时确认堡垒机网络能通到对应端口。生产环境我建议数据库和 Redis 都不要跟业务库混用堡垒机的审计数据很关键值得单独给资源。2.4 启动、检查和首次登录配置改完后启动并看状态cd /opt/jumpserver ./jmsctl.sh start ./jmsctl.sh status第一次启动会初始化数据库和基础数据耗时可能比想象中长属正常现象。状态检查时看到core、koko、guacamole这些组件都处于运行状态再访问 Web 页面。如果core一直重启用docker ps找到对应的容器名再用docker logs看日志大部分问题会直接写在报错里。浏览器打开http://你的IP按界面提示完成管理员初始化。这里要注意PUBLIC_URL的值会直接影响后续生成的连接地址。如果以后要在前面加 HTTPS 反向代理需要把PUBLIC_URL改成https://开头的地址再重启jmsctl服务不要只改代理不调整 JumpServer 侧配置。3. 资产纳管与授权让堡垒机真正跑起来3.1 先分清“堡垒机用户”和“资产账号”这是新手最容易绕晕的地方。JumpServer 里有两层账号第一层是堡垒机用户也就是登录 JumpServer 网页或命令行入口的账号比如ops_zhang第二层是资产账号也就是服务器上真实存在的系统账号比如root、ops、ubuntu。授权时要把这两层账号绑定起来。我的建议是不要直接让堡垒机用户对应 root。以前为了方便我把 root 直接授权给运维人员后来排查问题才发现所有操作都拿 root 执行根本分不清命令是谁敲的。更好的做法是给每类服务器建一个最小权限运维账号比如ops再按实际需要通过 sudo 提权。这样既能审计又不会把过高权限平铺给所有人。用户规模少的时候手动创建就行用户多了可以接 LDAP 或 OIDC 做统一身份源避免“OA 离职了堡垒机还活着”这种尴尬。3.2 纳管 Linux、Windows 和数据库资产资产录入在控制台的资产列表里做支持手动添加和批量导入 CSV。Linux 资产要填 IP、SSH 端口、协议再绑定资产账号Windows 资产走 RDP 协议一般填 3389 端口和 Administrator 或专用账号数据库资产选 MySQL、Oracle 等类型填地址、端口和登录账号。添加完资产后记得用“检测连接”或“测试”功能验证一遍。这里有个关键点JumpServer 的连接测试是从堡垒机服务器发起的不是从你本地电脑发起的。很多人添加资产后连不上原因是公司防火墙只放通了办公网到服务器的端口没放通堡垒机到服务器的端口。所以端口放行视角要从“堡垒机 → 资产”这个方向去检查。资产多了以后一定要用节点和标签管理。我习惯按“环境/系统/用途”建目录比如/生产/Web/Nginx授权时直接选择节点后续新资产加进对应节点就能自动被规则覆盖不用每次都改授权。没有节点管理的资产列表五十台以后基本就没法看了。3.3 授权规则的配置思路授权规则是 JumpServer 的核心一句话总结就是让哪些用户通过哪些资产账号能访问哪些资产能做什么操作。我常用的一条规则结构是这样的规则名称prod-web-ops用户运维组资产生产 Web 节点资产账号ops账号权限范围连接、文件管理、命令过滤配授权规则时最忌讳的就是“图省事”。有人把所有服务器放进一个节点所有运维人员放进一个组一条规则全开这跟没上堡垒机没什么区别。权限维护确实麻烦但至少按“环境 系统”两个维度切分比如测试环境一组、生产环境一组开发库一组、生产库一组。前期麻烦一点后面排障和合规审计的时候会轻松非常多。另外授权要尽量用组而不是单用户。用单用户授权很容易造成规则越堆越多最后没人说得清谁有什么权限。这里多花十分钟后面能省十个小时。4. 日常应用的几个高价值功能4.1 命令过滤与危险命令拦截资产接入后日常运维可以通过 Web 终端直接打开 SSH 会话。这个终端最大的价值不是好看而是支持命令过滤。JumpServer 支持配置危险命令正则一旦用户执行匹配到的命令可以拦截或触发告警。我自己的危险命令库至少包含这几类删除类rm -rf /、rm -rf /*格式化类mkfs、dd if... of/dev/...系统级操作shutdown、reboot、init 0权限变更类chmod -R 777 /注意命令过滤对 SSH、SFTP 这类文本协议有效RDP 图形会话里是没法逐条拦截命令的。Windows 服务器的命令审计更多还是依赖会话录像和登录日志。所以我建议 Linux 管理员尽量走 SSH 终端把高危命令“挡在门外”Windows 管理员则要养成“所有操作都在录”的习惯。4.2 会话录像、上传下载审计会话录像是堡垒机应用中最有说服力的功能。出了故障双方各执一词的时候把录像调出来放一遍谁对谁错一目了然。数据库误删、配置文件被改、服务被莫名拉起来这些问题在录像面前都会变得清楚很多。JumpServer 的会话记录在 Web 端可以直接回放录像文件也会落到数据目录。生产环境我建议把录像数据单独挂盘磁盘监控要盯起来不然录像把磁盘写满整个堡垒机组件都会异常。文件管理权限也要仔细配授权规则里可以分别控制上传、下载。如果某个资产不适合往外传文件就把下载关掉避免通过 SFTP 把敏感数据拖走。4.3 多因子认证和工单审批堡垒机账号一旦泄露影响的是所有纳管资产所以多因子认证不是可选项是必选项。JumpServer 支持 TOTP 验证器用户手机安装一个验证器应用登录时输入动态码。刚开始推广时会有人嫌麻烦但堡垒机这种入口级的系统多一步认证是非常值的。给用户绑定 TOTP 时建议让用户自己保存初始密钥避免换手机后无法登录。工单审批也是我推荐优先开启的功能。当用户没有某个资产的授权时可以通过申请流程临时申请访问权限审批通过后自动开通到期自动收回。比起“找管理员加权限”这种不透明流程工单审批留痕清楚权限也不会长期停留在不该有权限的人手里。5. 常见故障与排错记录5.1 连接类问题排查思路部署和日常使用中我遇到最多的不是安装失败而是资产连接异常。下面这个表是实际排障中比较高频的问题故障现象可能原因排查方法SSH 资产连不上堡垒机到资产 22 端口不通或资产账号密码错误在堡垒机服务器上直接用 ssh/telnet 测试到资产的连通性RDP 资产连不上堡垒机到资产 3389 端口不通或资产开了 NLA 策略检查安全组/防火墙确认堡垒机 IP 在资产允许名单里网页打不开core 组件未启动或后端数据库、Redis 连接失败执行./jmsctl.sh status再查看 core 容器日志Web 终端连上了马上断开资产上的 shell 配置异常或 SSH 端口不是默认值先绕过堡垒机直连资产确认原生连接没问题SSH 命令行入口登录后没有资产列表当前用户没有被授权任何资产检查授权规则确认用户组、资产组、账号都匹配有一类问题特别隐蔽资产 IP 在办公网能 ping 通但堡垒机所在的网段不通。因为很多人测试连通性习惯用本地电脑访问服务器忘了真正发起连接的是堡垒机。所以添加资产之后第一件事就是从堡垒机本机测试到资产的网络通路。5.2 组件状态类问题处理如果./jmsctl.sh status显示某个组件 unhealthy不要急着重启整个服务先看日志。core组件如果连不上数据库或 Redis日志里通常直接有连接失败字样。确认数据库账号、密码、网络没有问题后再重启服务。另一种情况是配置改了但没生效。修改config.txt后需要执行./jmsctl.sh restart容器重新加载环境变量。只改文件不重启等于没改。修改配置前一定要先备份改错了还能回滚不要在线上边改边试。组件反复重启时还要看一下服务器资源内存和磁盘满了会看到各种奇怪现象。我的经验是先查磁盘占用再查内存最后才去看业务配置。很多“莫名其妙”的故障根因就是/opt/jumpserver/data目录被录像胀满了。5.3 升级与备份JumpServer 版本升级前务必先备份。至少备份两样东西数据库和整个/opt/jumpserver数据目录。命令行下通常有对应的备份脚本先执行备份确认备份文件非空再执行升级操作。升级后不要只看网页能不能打开还要做一个“登录用户 → 选择资产 → 建立会话 → 查看录像”的完整回归。之前我遇到过升级后网页正常但录像播放不了的案例就是因为某个组件版本和录像存储格式不匹配。完整回归一遍才能确认这次升级真正成功。6. 上线后容易被忽略的几件事堡垒机部署完只是开始真正值钱的是后续的使用纪律。我个人感觉最重要的一件事是把旁路断掉服务器安全组和防火墙上的 22 端口、3389 端口只允许堡垒机访问不允许办公网直连服务器。如果大家还是能直接从本地 SSH 到服务器堡垒机录到的就只是一部分操作审计价值直接打折扣。用户权限要定期梳理至少每个季度过一遍。看看哪些人不该有生产权限了哪些授权规则已经没人使用。有人离职时第一时间禁用堡垒机账号同时把相关的资产账号密码改掉。录像和日志保留时间也要有明确策略。合规审计要求各异但至少保留 180 天比较稳妥。磁盘空间、备份有效性、录像完整性这些都可以加一个定时检查任务或者接进现有的监控系统。堡垒机本身也是系统它也需要被监控。最后再分享一点实际体会堡垒机不是给运维“添麻烦”的工具它更像是给整个团队装了一个可以回放的黑匣子。刚开始接入时大家会觉得多一步登录很烦坚持用一段时间之后再遇到故障或争议能拿出录像和日志说话那种感觉远比互相扯皮舒服。工具提供能力纪律决定价值这两者都到位了JumpServer 这套堡垒机才能真正变成运维体系里最稳的一环。