1. 先搞清楚堡垒机和跳板机到底在解决什么问题做运维久了你会发现一个特别尴尬的阶段服务器从三五台涨到几十台团队从两三个人涨到五六个人每个人手里都攒着一堆密码和私钥。今天张三改个端口明天李四重启个服务后天有人不小心在生产环境敲了rm -rf。等出了事想查是谁干的翻半天操作日志发现要么没记录要么记录被改了要么根本不知道哪台机器被人动过。堡垒机或者说跳板机就是用来治这个乱局的。简单理解跳板机是“绕路”的入口外部网络不直接打通到内网服务器而是先登录一台经过加固的机器再从这台机器跳到目标服务器上。它解决的是网络隔离的问题。堡垒机的概念更大一些它更像一道门禁加录像机所有运维操作必须经过这道门门上有身份校验、权限控制屋子里还装了摄像头和录音笔把你在每台机器上敲过的命令、传过的文件、看过的内容全部录下来事后可以回放审计。所以现在大家说“堡垒机”的时候通常已经默认包含了“跳板”这个功能。JumpServer就是目前国内用得非常广的开源堡垒机方案核心功能就三个身份认证、权限控制、操作审计。换句话说它管住“谁能进”、“能进哪”、“进去干了什么”。这篇文章把我自己从零搭建JumpServer到日常运维使用的完整过程整理出来包括踩过的坑、版本选型、组件逻辑、配置细节适合刚开始接触堡垒机的运维新人也适合准备在公司内部落地一套审计方案的团队参考。注意这里说的JumpServer部署和使用纯指内网运维审计系统的搭建。不涉及任何外网访问链路、代理协议之类的配置只聊在私有化环境里怎么把它跑起来、用起来。2. 设计与选型为什么是JumpServer而不是自己攒脚本理论上你可以用一台普通的Linux服务器当跳板机配好SSH转发、装个Python脚本做命令记录再搞个集中账号管理。但真正落地之后你会发现自己攒的方案在运维规模小的时候勉强能用一旦账号多、机器多、人员频繁变动维护成本会迅速超过收益。2.1 自建跳板方案的痛点先说我自己经历过的最头疼的几件事。第一账号管理全靠人肉。新员工入职要在几百台服务器上添加账号要么改/etc/passwd要么用Ansible批量推动作慢还容易漏。员工离职时最怕的就是漏删某个机器上的账号留下一个长期不用的僵尸入口。第二审计根本不完整。脚本记录命令日志用户一句sudo su -切到root之后后面干了什么就全丢了。想在Web端看回放做不到想检索某条命令在哪台机器上执行过做不到想控制某些高危命令不让执行更做不到。第三权限控制太粗糙。运维权限通常按人分但服务器上只有root、普通用户两级。你很难做到“给张三开这三台机器的root权限但不允许执行reboot”也很难做到“李四只能看日志不能改配置”。2.2 JumpServer的核心组件与逻辑JumpServer能在众多堡垒机方案里被选出来主要因为三个特点开源免费、组件清晰、部署不复杂。它的核心逻辑围绕着四个组件转CorePython编写的核心服务负责用户管理、资产管理、权限规则、审计日志存储相当于堡垒机的大脑。KoKo负责SSH协议的连接代理。用户访问Linux资产时实际是先连到KoKo再由KoKo转发到目标机器。所有命令流都会经过这一层所以能完整记录字符型会话。Lion负责Web端远程连接。严格来说Lion提供了浏览器里打开SSH终端、RDP桌面客户端的能力适应“不想装本地客户端打开网页就能连”的场景。Web前端控制台日常的资产录入、授权、日志查看都在这里完成同时承担了一部分Web Terminal的界面展示。这几者的关系用一句话概括你先登录Web控制台Web控制台找Core确认你的身份和权限然后你通过KoKo或Lion发起到目标资产的连接整个过程的会话流被录下来审计数据回到Core存储。2.3 JumpServer v3.x 和 v4.x 该怎么选部署之前版本选择要认真考虑。目前社区和商业版主要围绕v3.x和v4.x两条线。v3.x是长稳版本适合生产环境资料多网上踩坑案例也多v4.x对UI和底层做了一些重构界面更现代但升级带来的兼容性变化需要注意部分旧插件、自定义脚本需要适配。我自己的建议是如果是新搭建直接选v4.x的最新LTS版本功能边界更清晰官方更新周期也更可控。如果团队里已有v2.x或v3.x在跑不要轻易原地升级先拿测试环境完整走一遍升级流程确认资产和授权规则都没有异常再动生产。另外要注意JumpServer支持从源码部署、传统包部署、Docker部署、Kubernetes部署。对于大多数中小团队Docker Compose是性价比最高的方式。源码部署适合深度定制传统包部署适合没有Docker环境的老系统而Compose方式部署快、回滚容易、依赖打包完整下文就以Docker Compose为主线展开。3. 部署前准备硬件规划、系统要求、端口和目录约定很多人在搭建堡垒机时翻车不是JumpServer本身的问题而是准备工作没做好。这里把我在正式部署前会花时间确认的点一一列出来。3.1 硬件与系统最低要求JumpServer由多个组件组成虽然可以全部塞在一台服务器上但资源规划还是要认真对待。官方给的最低配置是2核4G但这个配置只适合实验环境。我实测下来4核8G是小型团队50台资产以内、并发连接不超过20个的稳妥起步配置。磁盘要特别关注。审计会话都是文本日志和录像文件单个会话不大但日积月累很占空间。建议独立挂载一块数据盘至少100G起步并把/opt/jumpserver的数据目录放在数据盘上。系统盘和数据盘分开避免日志把系统分区写满。操作系统方面CentOS 7.9、CentOS Stream、Ubuntu 22.04/24.04都可以。这里有一个很关键的建议部署机不要和JumpServer所在机器重合。也就是说不要在部署机上同时存放Compose编排文件和数据库数据编排文件可以放在/opt/jumpserver下的单独目录数据库和日志数据默认就放在编排目录附近但一定要确认磁盘空间。3.2 端口规划JumpServer默认需要用到以下端口安装前先在防火墙和安全组里放通端口用途80Web控制台HTTP访问通常配合Nginx做443443Web控制台HTTPS访问配置证书后使用2222KoKo组件的SSH接入端口用户用原生SSH客户端连接堡垒机时用这个端口3306若内置MySQL供容器间访问若使用外部MySQL需单独放通6379Redis端口供容器间访问如果你公司的网络策略比较严格需要把Web控制台端口和SSH接入端口都登记到资产台账里。我习惯把80端口映射为8443对外只暴露443和2222管理网段才能访问其他端口。3.3 Docker与Compose环境准备JumpServer的Docker镜像在Docker Hub和阿里云镜像仓库都有同步。服务器能连外网的话直接拉取最新镜像即可。如果处于纯内网环境需要在有外网的机器上下载镜像包再docker save成tar包导入内网。安装Docker的步骤比较基础但版本有讲究。不要装太老的Docker版本建议20.10以上Compose插件用v2版本。命令如下# 安装Docker以Ubuntu 22.04为例 sudo apt update sudo apt install -y docker.io docker-compose-v2 # 启动并设置开机自启 sudo systemctl enable --now docker # 确认版本 docker --version docker compose version注意如果系统自带旧版docker-compose命令建议直接用docker compose带空格的v2语法编排文件兼容性更好。3.4 目录约定我在部署时习惯把JumpServer统一放在一个固定目录下方便后续备份和升级sudo mkdir -p /opt/jumpserver sudo chown -R $(whoami):$(whoami) /opt/jumpserver cd /opt/jumpserver之后下载编排文件、配置.env环境变量、查看日志、备份数据都以这个目录为基准。4. 实操部署从下载编排文件到第一次进入控制台这一节是全文核心我会把每一步的操作意图都说明白而不是只给你一串命令。4.1 下载编排文件与配置环境变量JumpServer官方维护了一套docker-compose编排文件放在GitHub上。内网环境可以从网上下载后传给服务器外网环境直接拉取。以当前v4.x版本为例cd /opt/jumpserver # 下载编排文件 curl -sSL https://github.com/jumpserver/Dockerfile/raw/master/4.0/docker-compose.yml -o docker-compose.yml # 下载环境变量模板 curl -sSL https://github.com/jumpserver/Dockerfile/raw/master/4.0/config_example.txt -o .env拿到.env文件后不要急着启动先检查几个关键项。DOMAIN字段决定Web控制台的访问域名或IP。如果你是IP访问直接写DOMAIN192.168.1.100这种形式如果有域名并配置了HTTPS证书就写域名。HTTP_PORT改成实际要暴露的端口。SSH_PORT是KoKo的接入端口默认2222。SECRET_KEY和BOOTSTRAP_TOKEN默认是示例值生产环境一定要改成随机串可以用以下命令生成# 生成随机密钥 echo $RANDOM | md5sum head -c 50 /dev/urandom | base64数据库和Redis默认是容器内置的系统会自动完成初始化。如果你有外部MySQL和Redis需要在.env里把DB_HOST、DB_PORT、DB_USER、DB_PASSWORD、REDIS_HOST、REDIS_PORT这些变量改成外部服务地址。4.2 启动与初始化配置完.env执行以下命令cd /opt/jumpserver docker compose up -d第一次启动会拉取镜像并创建容器时间取决于网络。启动完成后确认所有容器状态正常docker compose ps正常情况下你会看到core、koko、lion、web、mysql、redis等容器全部处于Up状态。如果你用的是新版镜像可能还会有xpack等扩展组件容器。此时打开浏览器访问http://你的服务器IP:80。不出意外会看到JumpServer的初始化页面第一步是创建管理员账号。这里我踩过一个坑管理员密码要足够复杂至少包含大小写字母和数字否则会提示弱密码无法通过。初始化完成后系统会引导你修改默认的安全设置比如密码策略、MFA配置。建议初始化阶段就把MFA打开管理员账号自己先绑好OTP应用后面所有用户登录都要求二次验证。第一次进入控制台后第一件事不是急着添加资产而是先把系统设置里的“默认用户”和“命令过滤”规则过一遍。4.3 容器组件之间的网络逻辑补充一点理解性的内容。启动后你会发现各个容器之间是通过Docker内网通信的。Core通过内网IP连接MySQL和RedisKoKo通过内部地址连接CoreWeb通过反向代理的方式把请求转发给Core和KoKo。这些容器之间的连接不需要你操心Compose文件已经全部定义好了。你要关心的只是对外暴露的端口Web控制台的80/443SSH接入的2222。理解这个逻辑之后排错就清晰了用户连接不了资产问题可能出在KoKo到目标机器的网络而不是Web控制台本身审计日志查不到大概率是Core到MySQL的写入有问题。5. 使用配置用户、资产、授权规则三步走JumpServer的使用逻辑非常标准核心就三步先把人和机器纳管进来再把权限规则配置好最后让用户通过堡垒机去连接。5.1 用户管理本地用户与MFA强制用户管理在“控制台-用户-用户列表”里操作。创建用户时要填写用户名、姓名、邮箱、手机号这些字段会在后续审计和告警中用到尽量填全。JumpServer支持多种认证方式本地密码、LDAP、OAuth2、CAS等。小团队直接本地用户即可企业级建议对接LDAP或OAuth2这样可以跟随公司账号体系自动同步员工离职时统一停用。这里要强调一个设计细节JumpServer里的用户和资产上的系统账号不是一回事。堡垒机的用户是“谁登录了JumpServer”资产上的账号是“JumpServer以什么身份去登录目标机器”。两者的映射关系在授权规则中定义逻辑上要分清楚。我在第一次使用时犯过一个错误以为添加了JumpServer用户就等于能在服务器上登录了。实际上你还得在资产上准备好一个系统账号然后把“资产-系统用户”与“JumpServer用户”做授权关联用户才能真正连上。MFA建议设为强制。登录JumpServer时输入密码后再输入一次性验证码能有效避免密码泄露后直接被登录的风险。OTP应用用Google Authenticator或Microsoft Authenticator都可以。5.2 资产纳管主机、Windows、数据库在“控制台-资产-资产列表”里新增资产。以最常用的Linux主机为例填写的核心字段有主机名建议用规范的命名方式比如prod-web-01避免出现测试机1这种名字。IP地址目标服务器的管理IP。协议SSH。端口目标服务器的SSH端口默认22。系统用户这里填的是你要在目标服务器上使用的账号名比如root或者一个普通运维账号。JumpServer会自动用这个账号连接目标服务器连接时可以选择“密码”、“密钥”、“自动提权”等方式。Windows资产的协议是RDP端口3389。数据库资产的协议需要选择对应的类型比如MySQL、PostgreSQL、SQL Server等。对于数据库资产JumpServer会通过代理方式捕获SQL语句形成独立的数据库审计日志。资产数量少的时候逐个添加没毛病。资产上百台以后建议使用批量导入功能按CSV模板整理资产信息后一键导入。模板字段比较多但只要把IP、主机名、协议、端口填好系统用户可以先不填后续在授权规则里统一关联。5.3 授权规则最小权限是怎么落地的授权规则在“控制台-权限-授权规则”里配置。规则的三要素是“用户”、“资产”、“系统用户”含义是“这个用户能用哪个系统账号连接哪些资产”。实操中有一个常用的设计套路先建一个“运维组”把所有需要登录生产环境的同事拉进来。再建一个“生产资产组”把生产环境的机器都归进去。最后建一条授权规则运维组 - 生产资产组系统用户用root但“命令过滤”里禁止高危命令。再建一个“开发组”只授权测试环境的资产系统用户用普通账号命令权限放宽到禁止rm -rf /即可。这样权限规则数量少维护起来也直观。如果有临时需求比如某个人需要暂时访问某台机器可以建一条临时授权规则设置有效期。到期自动失效不需要担心忘记收回权限。命令过滤是JumpServer比较实用的功能。在“控制台-权限-命令过滤”里创建过滤规则可以按命令正则匹配比如^rm -rf .*、^mkfs.*等动作可以是“禁止执行”或“允许执行并审批”。我建议先做“禁止执行”的最小集把删库跑路类命令全部禁掉然后再考虑审批流。6. 实际连接场景Web终端、SSH客户端、数据库客户端配置完授权规则后用户就可以开始连接资产了。这一节我分别介绍三种最常见的连接方式以及各自适合的场景。6.1 Web终端屛蔽安装客户端的最好选择用户登录JumpServer控制台后在“工作台-我的资产”里能看到自己被授权的资产列表。点击“连接”按钮选择SSH终端就会在浏览器里打开一个基于Web的终端窗口。Web终端其实走的是Lion组件部分版本是KoKo内置了Web终端能力用户不需要在本地安装任何SSH工具只要能打开浏览器就能操作。这个方式最适合偶尔需要登录服务器处理问题的场景比如测试同事临时看个日志产品经理需要查某个配置。Web终端的优点是多了一个“协作分享”的能力你可以把当前会话分享给其他人对方通过链接即可看到实时操作画面。这个功能在远程协助排障时特别实用比自己报命令、别人截图来回折腾效率高得多。6.2 原生SSH客户端高频运维人员的日常姿势对于每天要登录几十台服务器的运维来说浏览器里点来点去还是不够快。JumpServer支持原生SSH客户端直接连接你只需要知道一个入口地址ssh -p 2222 用户名堡垒机IP。输入密码和MFA验证码之后你会进入一个交互式菜单里面列出你有权限访问的资产列表输入编号即可进入对应资产的终端。这个方式的体验和直接SSH到目标机器几乎没有区别而且所有操作依然会被记录下来。我日常的使用习惯是在本地Shell里配置一个SSH别名比如alias jumpssh -p 2222 myname192.168.1.100然后每天工作时先jump进入菜单再选择需要的机器。这个流程熟练之后效率很高。如果你用Xshell之类的图形化SSH工具同样可以新建会话连接到堡垒机IP的2222端口输入账号密码后进入菜单然后在Xshell里就能操作目标机器。6.3 数据库客户端连接数据库连接有一个常见需求用Navicat或DBVisualizer这类客户端直连内网数据库。借助JumpServer可以做到不让数据库端口直接暴露给客户端网络而是让客户端先连到堡垒机再通过堡垒机转发到数据库端口。JumpServer在授权规则里配置好数据库资产后会在“工作台-我的资产”里看到数据库资产。点击“数据库”图标系统会弹出一个连接助手的说明上面明确告诉你本地连接时需要填写的地址、端口、用户名和密码。比如在Navicat里新建连接时主机填堡垒机IP端口填JumpServer提供的映射端口每次连接时会动态生成用户名填JumpServer的用户名密码填JumpServer的密码。连接后实际访问的是目标数据库。需要注意的是数据库客户端连接依赖Lion组件提供的Web-based DBeaver能力。如果你的环境里Lion有问题会直接影响数据库连接。排查的时候优先看Lion容器状态。7. 常见问题与排查技巧实录实际使用JumpServer半年多我积累了不少排错经验。这里整理几个高频问题按“问题现象-原因分析-解决办法”的方式列出。7.1 Web控制台登录后白屏或502错误这个问题的常见原因有两个。一是SECRET_KEY或BOOTSTRAP_TOKEN在启动后又被手动修改过导致Core生成的加密数据无法解密。解决办法是恢复原来的密钥或清空数据库重新初始化如果数据不重要。二是Web容器和Core容器之间的网络异常重启Web容器或执行docker compose restart web一般能恢复。7.2 SSH客户端连接堡垒机一直提示超时先从网络链路排查先确认堡垒机IP和2222端口是否可达用telnet 堡垒机IP 2222测试。如果端口通再看KoKo容器状态如果KoKo正常检查.env里SSH_PORT是否在防火墙中放通。还有一个比较容易忽略的问题如果堡垒机上有多个网卡确保用户访问的IP是KoKo绑定监听的IP。7.3 能连上资产但命令记录查不到命令记录查不到先确认是不是用了RDP协议连接Windows资产。Windows的RDP会话记录的是屏幕录像不是字符命令字符型命令过滤规则对它无效。这种场景下需要查看录像回放位置在“审计台-会话记录-录像回放”里。如果是SSH连接但查不到命令大概率是授权规则里关联的“系统用户”没有启用命令记录功能检查系统用户的“自动推送”和“记录命令”选项。7.4 资产连接时报“认证失败”登录JumpServer成功后连接资产时提示认证失败问题出在JumpServer服务器和目标机器之间的认证上。你需要检查系统用户配置里的认证方式如果选的是密码确认目标机器上这个账号的密码正确如果选的是密钥确认公钥已经推送到目标机器的~/.ssh/authorized_keys里如果选择了“自动推送”那么JumpServer会尝试通过SSH方式把密钥推过去前提是目标机器的SSH首次连接时允许认证。7.5 命令过滤规则没有生效排查时要注意命令过滤规则的优先级高于授权规则。规则创建后需要对“用户-资产-系统用户”的授权关系重新做一次更新或者等待规则缓存刷新。如果规则配置正确但不生效重启KoKo容器是一个快速解决办法。7.6 常见问题速查表问题现象排查思路解决办法控制台白屏Core密钥是否变动、Web容器状态恢复初始密钥重启web容器SSH连接超时防火墙、端口、KoKo容器放通2222端口重启koko容器资产认证失败系统用户密码/密钥是否正确核对目标机器认证信息命令查不到协议类型、命令记录开关RDP走录像回放SSH开记录过滤规则不生效规则优先级、缓存刷新更新授权重启koko容器数据库连接失败Lion组件状态、本地网络查看lion日志检查组件状态8. 备份、升级与日常运维部署完成只是开始真正的长期挑战在运维侧。这部分说说我自己的习惯做法。8.1 数据库与配置文件备份JumpServer的资产、用户、授权规则都存在MySQL里这些数据是堡垒机的核心资产。备份策略很简单每天凌晨对MySQL容器做一次mysqldump保存到独立数据盘保留30天。同时把/opt/jumpserver下的.env文件单独备份这个文件里保存了所有随机密钥没有它即使有数据库备份也无法恢复。# 进入JumpServer目录 cd /opt/jumpserver # 用Docker执行数据库备份 docker compose exec mysql mysqldump -uroot -p$DB_PASSWORD jumpserver backup_jumpserver_$(date %F).sql注意替换$DB_PASSWORD为.env里实际配置的数据库密码。备份完成后把SQL文件同步到异地备份或对象存储防止本地磁盘故障导致备份一起丢失。8.2 升级流程JumpServer的升级不要跳版本。先查看当前版本再在官方Release页面找到对应的升级包或者重新拉取镜像。Docker Compose方式升级相对简单关闭服务、备份数据库、拉取最新镜像、启动服务。但升级前一定要在测试环境完整验证重点检查授权规则、用户导入导出、数据库连接三块功能是否正常。8.3 日常巡检建议每天看一次磁盘使用率审计录像目录增长很快。每周检查一次KoKo和Lion容器的日志确认没有异常报错。每月抽查几条审计录像确认录像能正常回放。每季度回顾一次授权规则清理长期不用的资产和用户。我自己在巡检时发现过一个问题某台测试服务器的磁盘满了导致KoKo写入审计日志失败用户连接会话直接卡住。从那之后我会用df -h和docker compose logs --tail50 koko作为巡检的第一条命令。9. 聊聊我踩过的坑和最后的一点建议堡垒机本质上是一个“管控入口”它不是装完就一劳永逸的工具而是需要持续运营的流程体系。部署阶段多花一点时间把规则设计好日常使用才会省心。有几个具体建议按优先级排序第一MFA一定要强制开启。堡垒机集中了公司所有服务器的入口一旦堡垒机的管理员账号被攻破所有资产都等于裸奔。MFA是目前成本最低、效果最明显的防护措施。第二系统用户不要一股脑全用root。你可以用root做初始连接但尽量在目标机器上创建一个专用账号加入sudo权限组通过命令过滤控制提权行为。这样即使JumpServer被入侵对方拿到的也不是直接root权限。第三定期做一次权限审计。把授权规则列表导出来逐个核对哪些用户还在活跃、哪些资产已经下线、哪些授权关系是三个月前临时加的但已经没人记得了。这种“权限清理”比装任何安全工具都有效。第四日志备份不要只放本机。堡垒机的审计日志是安全追责的重要依据如果被攻击者连同服务器一起删掉审计能力就失效了。日志定期同步到独立的日志平台或存储桶是最好的保险。我在实际使用中体会最深的一件事是堡垒机不是为了限制运维人员的自由度而是为了让所有人在出问题时能快速定位责任、恢复现场。有了这套体系之后团队在操作生产环境时反而更自信了因为每个操作都有迹可循每次变更都能复盘。JumpServer的开源属性让它成为一个非常灵活的底座你可以按团队的实际情况定制授权模型和审计策略而不是被商业产品的固定流程绑住手脚。最后再分享一个小技巧如果你们团队使用JumpServer比较频繁可以把“资产命名规范”和“用户命名规范”单独写一份简单的内部文档和JumpServer配合使用。命名不乱权限规则就不会乱审计的时候才能快速定位到具体的人和机器。这个细节很多人一开始不在意等资产上了几百台之后就知道有多重要了。