堡垒机与跳板机区别及JumpServer开源堡垒机部署实践

做运维这些年，我见过太多团队在服务器访问管理上栽跟头。先是开发人员为了省事，把服务器密码直接写在聊天记录里；再是某个外包同事离职后，他经手过的机器还留着原来的钥匙；最后安全审计一查，连哪个人哪次执行过什么命令都说不清楚。等到这时才想起来搭一套访问入口，嘴里念叨的又是“堡垒机”又是“跳板机”，完全分不清这两者到底差在哪。

想搞懂服务器安全访问方案，第一步确实得先把概念厘清。堡垒机和跳板机听起来像是同一个东西的两个名字，不少云厂商的文档也会把两者混着写，但实际在生产环境里，它们的定位、能力边界、部署成本完全不是一回事。如果你只想要一条能绕过生产网段、登进去干活的通道，跳板机就够了；如果你要的是能过等保、能给每一次操作留痕、能管住几百号人权限的合规入口，那需要的才是真正意义上的堡垒机。

这篇文章我结合自己用过的几套方案，带你把两者的区别从原理到实操彻底过一遍。不搞教科书式定义，就用我实际部署和维护时的视角，讲清楚什么场景该选哪种，真到了搭建的时候又有哪些可以抄作业的经验。

1. 先想清楚一个事儿：堡垒机和跳板机到底是不是同一个东西

很多新手看到运维文档里出现“Bastion Host”就直接翻译成堡垒机，看到“Jump Host”又翻译成跳板机，然后在不同资料里来回摇摆，越看越迷糊。我自己刚开始接触这块的时候也懵过，后来被一个前辈点醒：跳板机是“路”，堡垒机是“路+闸机+摄像头+门禁记录员”，两者根本不在一个维度上。

1.1 从角色定位看本质差异

跳板机的原始定义很朴素：它是放置在安全边界区域的一台服务器，外部网络不能直接访问内部资源，必须先登录这台机器，再由这台机器跳转访问目标主机。它解决的核心问题是网络可达性。

打个比方，你家小区有门禁，来访者进不了单元门，只能先到小区门口的物业岗亭登记，再由物业人员帮你刷开门禁。跳板机就是那个“物业岗亭”——它是一个公网可达的中转点，本身不产出管理策略，也不关心你来干什么，甚至很多时候它就是一台开了SSH转发功能的普通Linux机器。

堡垒机则是在跳板机的基础上，把“身份认证、权限控制、操作审计”三件事做成了完整闭环。它不只是送你进门，还会记录你进门之后的所有动作，并且在进门之前就决定好你只能去哪几层、能碰哪些房门。

从产品形态上讲，堡垒机通常包含这几个核心组件：

• 认证中心：负责对接企业LDAP、AD域、OTP动态口令等身份源，确认“你是谁”。
• 授权引擎：基于RBAC或更细粒度的规则，定义“你能访问哪些资产、以什么账号访问、什么时间段允许”。
• 代理通道：用户连接的不是目标机器本身，而是堡垒机的代理端口，再由堡垒机建立到目标机的会话。
• 审计中心：全量记录会话，包括字符协议的命令级日志、图形协议的屏幕录像，以及文件传输操作。

看到这你应该明白了，跳板机是堡垒机的一个子集能力，或者说堡垒机是一个“加了管理大脑的跳板机”。

1.2 一张表看懂关键差异

很多运维选型时最关心的就是差别在哪，我按实际运维关注的维度整理了一份对照表，可以直接收藏：

从表格里可以看出，如果你现在管理的服务器不超过10台，团队人员也就三五个，大家彼此熟悉、信任度也高，那确实没必要硬上堡垒机——杀鸡不用牛刀。但如果是生产环境，或者有外部人员要临时进场，甚至公司已经在为等保发愁，那就别省这个事了。

2. 面向实操的工具选型：开源堡垒机和自建跳板机到底怎么挑

理清概念后，下一个问题就是：方案落地时选什么工具？我见过不少人一上来就搜“开源堡垒机有哪些”，然后对着几款产品挑花了眼。其实选型不用跟风，要把自己的真实需求列出来再匹配。

2.1 主流的开源堡垒机怎么选

目前活跃度高、社区使用人数多的开源堡垒机，我接触过的大致是这几个：

如果你问我哪个最推荐，我会选JumpServer。原因不是它功能最强，而是它把堡垒机该有的核心模块都做成了开箱即用：用户导入、资产纳管、授权规则、会话审计，默认功能已经能覆盖90%的运维日常需求。而且它自带Web SFTP、数据库运维连接这种实用功能，省去自己拼凑各种工具的麻烦。唯一要注意的是，JumpServer启动的组件比较多，官方现在的部署方式也是用Docker Compose或Kubernetes编排，对服务器的内存有要求的，购买机器时别买太小了，建议至少4G内存起步。

teleport的最大优势是简单，一个二进制文件扔到服务器上就能起来。我疫情期间帮朋友公司救过一次急，就是用的teleport，20分钟就从零搭好了一套小规模访问入口。如果你所在团队有Linux基础的人不多、只想解决“外网怎么安全地连内网机器”的问题，teleport这种“轻堡垒”会更合适。

2.2 别照着教程盲选：先量化自己的三组问题

选型不是看哪张功能列表长，而是先回答下面几个问题，答案自然就会帮你筛掉大半选项：

第一组问题：运维方式是什么样的？是纯SSH命令行为主，还是经常需要远程连Windows桌面、操作数据库客户端？如果以SSH为主，teleport这类轻量工具就够用；如果要连Windows的RDP、要运维Oracle/MySQL，那直接看JumpServer，它把这些协议支持都内置了，省心很多。

第二组问题：身份源和管理规模有多大？公司有没有现成的LDAP/AD域？如果有，必须选支持协议对接的产品，否则每个季度光是同步离职员工账号就能让人崩溃。超过50个管理账号后，手写配置文件授权的方式根本不现实，必须要有可以可视化管理权限的后台。

第三组问题：合规要求和时间成本是怎样的？是被内审部门盯着做整改，还是要过正式的等保测评？如果是前者，可以用开源堡垒机把“审计录像”和“命令记录”功能开启，能撑过审计；如果是后者，还要考虑产品是否能提供必要的报表能力。建议做个小表，把自己关心的功能打钩，再对比产品文档，很快就能锁定目标。

3. 从零搭建一套最小可用的堡垒机（JumpServer实操记录）

概念清楚了，工具选定了，接下来就是动手。我以当前社区使用量比较大的JumpServer为例，一步步演示在一台全新的Linux服务器上把堡垒机跑起来。这里假设你已经有一台4核8G、操作系统为Ubuntu 22.04的服务器，并且域名解析或者IP地址已经准备好。

3.1 部署前的流程设计和准备

很多人拿到部署文档就开始复制粘贴命令，装完发现自己漏了规划，访问入口乱七八糟。这个习惯不好。部署之前，建议先画一下自己的访问链路：

外部用户 -> 登录堡垒机Web界面 -> 发起SSH/RDP连接 -> 堡垒机代理 -> 跳转到目标内网机器

围绕这个链路，你需要在部署前决定三个参数：

• 堡垒机的Web访问端口：默认是80，如果你已经有Nginx在跑，需要规划成一个不冲突的端口，比如8080。
• 核心组件暴露方式：按官方默认配置即可，等能跑通后再做安全加固。
• 数据库和缓存：JumpServer依赖MySQL和Redis，如果你不想单独维护这两套服务，部署时可以直接用Compose文件里内置的容器化实例。但如果是要上生产，我强烈建议把它们拆出来，用独立的数据库实例。

设计思路是：先跑通最小闭环，再逐步补充高可用和外部依赖。

用Docker Compose部署JumpServer是最省心的方式。先把项目代码拉下来：

bash复制cd /opt
git clone https://github.com/jumpserver/jumpserver.git
cd jumpserver

然后复制一份配置模板：

bash复制cp config_example.conf config.txt

这里需要打开config.txt，把关键项调整成自己的环境：

text复制# 改成自己的服务器IP或域名
DOMAINS=192.168.1.100
# 会话录像存储路径，建议单独挂数据盘
VOLUME_DIR=/data/jumpserver
# MySQL连接信息，如果复用外部实例则改成外部地址
DB_HOST=mysql
DB_PORT=3306
DB_USER=jumpserver
DB_PASSWORD=你的强密码
# Redis连接信息
REDIS_HOST=redis

配置完先别急着启动，看一下Docker Compose文件里默认启动的服务清单，了解整个系统大概长什么样。以JumpServer 3.x版本为例，核心容器包含：

• jms_core：主服务，处理认证、授权、API请求。
• jms_lion：Web终端服务，负责Web-SSH和Web-RDP代理。
• jms_luna：前端静态页面服务，负责渲染Web界面。
• jms_magnus：数据库代理组件，用于支持通过堡垒机连接数据库。
• mysql 和 redis：数据存储。

看到没，这就是为什么说堡垒机比跳板机复杂，它不是一个单一进程，而是一组协同工作的服务集群。

3.2 初始化配置和账号准备

修改好config.txt后，执行一键初始化命令：

bash复制./jmsctl.sh install

这个脚本会自动生成必要的密钥、创建数据库目录、初始化数据库表。等看到类似“Install complete”的输出，就可以执行启动：

bash复制./jmsctl.sh start

首次启动会比较久，因为要拉取多个镜像。如果你的服务器网络拉取镜像比较慢，可以配置Docker镜像加速地址。启动完成后访问http://你的服务器IP，会来到初始化页面，创建一个管理员账号，这个账号就是整个堡垒机的超级管理员。

创建完管理员账号后，别忘了做两件初始化的关键动作：

第一个是修改管理员的绑定手机号和邮箱，后续找回密码、接收OTP动态口令都要靠这两个信息。第二个是生成并保存好备份密钥，JumpServer里所有托管的资产密码和SSH密钥都是加密存储的，如果这个备份密钥丢了，将来即使拿到数据库备份也恢复不了资产账号，我朋友就遇到过把服务器数据全部备份好但忘了保存密钥文件的事，最后只能手动重置所有资产密码，费了很大劲。这一步一定要重视。

3.3 纳管第一台目标服务器

堡垒机自己跑起来不算完，真正的工作从纳管资产开始。在JumpServer管理界面里，找到“资产管理 - 资产列表”，点击创建资产，需要填写下面几个关键项：

• 资产IP：目标服务器的内网IP
• 协议：SSH
• 端口：22
• 登录账号：如果运维账号统一用deploy，可以填deploy

填写完资产信息后，保存会提示你选择凭据。如果你想让堡垒机自动纳管这台机器的账号密码，选择“账号密码”方式，直接输入这台服务器的sudo账号密码；如果资产开启了密钥登录，则粘贴私钥内容。这里的选择关系到后续运维人员能不能免密登录目标机器，建议直接输root账号或具备sudo权限的部署账号。

保存好资产后，在用户管理里创建一个普通用户，比如叫ops_zhang，然后把资产授权给这个用户。等这个用户登录Web界面，点击SSH按钮就能直接进入目标机器的命令行会话了。

我第一次演示给同事看的时候，他们觉得这跟跳板机没区别：反正都是通过一个入口进到服务器里。直到我在后台打开了实时监控，把他们敲的每条命令都同步刷到屏幕上时，大家才真正震惊：这个系统能看到每个人正在执行什么。这就是审计的价值，也是堡垒机相对跳板机的杀手锏级差异。

4. 把跳板机安全策略迁移到堡垒机的核心配置拆解

如果以前用的是传统的跳板机，本质上是一台Linux机器上加了一堆别名、脚本和SSH公钥管理。现在换到堡垒机，很多旧习惯需要改。我在推进这种迁移时发现，最核心的工作不是技术，而是把原来的“隐形信任”转变成“显性控制”。

4.1 账号管理和密码托管

传统跳板机模式下，每个人的SSH公钥被追加到目标机器的authorized_keys文件里，公钥一多，管理就乱了；在堡垒机模式下，你不再需要把公钥分发到每一台目标机器。目标机器只需要信任堡垒机的“系统用户”，所有人员通过堡垒机连接时，实际登录目标机器的操作系统账号是由堡垒机代填的，整个流程对业务系统来说完全透明。

因此建议你在目标机器上统一创建一个或少数几个运维账号分配给堡垒机，比如opsadmin，将其加入sudo组，关闭或限制直接用root登录。然后将这个账号的密码或私钥录入到堡垒机的资产管理中。

有个操作细节值得注意：开启自动改密功能时，堡垒机会定期修改目标机器的登录密码。大多数情况下这很安全，但需要确保目标机器上开启了SSH密码认证，否则自动改密会失败，所以建议先把自动改密关掉，确认SSH密钥登录稳定后再打开。

权限模型上，我个人的最佳实践是用“角色-用户组-资产组”三层。创建两个用户组，一个叫“DBA-数据库组”，一个叫“开发-应用组”；把资产按类型也分成资产组，再设置授权规则：开发组的用户只能访问应用服务器组，DBA组的用户只能访问数据库服务器组。这样即使用户数量再多，新增一个员工也只需要把他拉进对应的用户组，权限自动生效，不用一条条去配。

4.2 运维人员使用方式和命令限制

账号、资产、授权规则配好之后，运维人员的使用方式从原来的ssh user@jump-server 变化成：先用浏览器或客户端登录堡垒机，再在堡垒机页面上发起目标连接。

我在生产环境推广时，是要求学生都优先用Web终端。原因有两个：一是Web界面天然就把审计功能带了出来，每次会话都会自动录像，不用额外配置；二是Web终端不依赖本地SSH客户端，换一台电脑、用手机临时救急都能连，灵活性更好。

不过部分资深运维会觉得Web界面效率低，喜欢用Xshell、Termius这类本地终端工具。JumpServer对这种情况也支持：在用户个人信息页开启SSH通道，配置好本地密钥后，可以用ssh 用户名@堡垒机IP -p 2222的方式先登录堡垒机，再通过堡垒机的交互菜单选择目标资产进行跳转。这种方式体验最接近原来的跳板机，同时又保留了堡垒机的审计能力。

命令黑白名单是另一个容易忽略的点。默认情况下堡垒机不会限制用户能执行什么命令，但从安全角度，我建议你对低权限用户开启命令过滤规则。比如，拦截rm -rf、拦截shutdown -h now、拦截mkfs这类高危指令，对那些误操作风险高的“小萌新”账号非常有价值。配置界面里提供命令模板库，直接引用现成的危险命令模板，两分钟就能生效。

4.3 登录保护策略：MFA是必须做的

如果让我从所有安全配置里只能选一条，我选强制开启多因子认证。很多服务器被黑，不是系统漏洞，而是口令泄露，你永远不知道哪个同事会把密码贴到自己的云笔记里。

在JumpServer后台的“系统设置 - 安全设置”里，可以设置全局的登录策略。我的建议是：

开启MFA后，每个用户首次登录时需要用手机下载任意一款OTP应用，然后扫描页面上的二维码。之后每次登录都需要输入6位动态验证码。我实测下来，增加这一步的登录耗时也就多三秒，但安全性提升是质的飞跃，尤其是当你需要把堡垒机映射到公网供员工远程办公时，MFA就是最后一道防线。

5. 这些年在生产环境踩过的坑和排查思路

工具本身的使用学习成本其实不高，真正常见的故障都出在部署环境、网络拓扑和配置细节上。总结几个我真实遇到过的问题，都是文档里不太会主动告诉你的。

5.1 Web界面登录不进去，页面一直报错

这个场景出现过好几次。先看服务状态：

bash复制./jmsctl.sh status

如果容器一切正常，还是登录不了，八成是数据库连接问题。我在升级JumpServer到3.x版本时遇到过数据库字符集不兼容导致登录写入失败的情况，表现为页面白屏或提示数据库异常。处理方式是把原有数据库备份出来，按新版本要求重置字符集为utf8mb4并重建数据库。

还有一种情况是企业内网开了防火墙，拦掉了WebSocket协议流量。Web终端连不上、页面显示连接失败，但登录却是正常的，大概率就是这个原因。检查防火墙时，不只是要放开TCP端口，还要确认负载均衡、反向代理没有关闭WebSocket升级请求头。

5.2 从堡垒机连不上目标机器，提示超时或权限拒绝

先按顺序检查网络连通性和凭据。在堡垒机系统里可以用“快速检测”功能，输入目标机器的IP和端口，看能不能通。网络通了但连接还是被拒，多半是目标机器上的账号凭据填错了，尤其是启用了SELinux的CentOS机器，SSH默认可能限制某些用户的登录行为。

我把这个检查流程整理成速查表，可以直接沿着这个顺序排查：

5.3 会话录像文件找不到或无法播放

审计录像文件找不到，一般是存储路径满了导致的。JumpServer的会话录像默认存放在MySQL中或挂载的卷里。当服务器磁盘空间满了之后，录像写入会静默失败，等审计的时候才发现啥也没有。

建议提前给存储目录挂了独立数据盘，并配置录像文件自动清理策略：比如在线保存90天，到期后自动转存到对象存储或冷数据服务器。条件不允许的话，至少设置一个crontab任务，定期清理3个月之前的录像文件打包上传，避免磁盘被塞满。

5.4 高并发场景下的性能瓶颈

如果公司规模扩大了，上百人同时用堡垒机操作，会出现卡顿甚至连接超时。这是因为JumpServer的Web终端组件是有并发连接数上限的。我经历过一次，连着几十个同事远程开会演示后，新用户的SSH连接直接超时，后来查出来是Web终端容器的连接数打满了。

解决思路有两个方向：一个是调大容器的并发连接参数，增加WebSocket的最大连接数；另一个是把连接分发到多套Lion组件上，做横向扩容。更稳妥的方案是给堡垒机服务器多分配几个CPU核心，Web终端对CPU的消耗远高于对内存的消耗，尤其是多人同时在线敲命令的时候。如果预算允许，把堡垒机部署成双节点，用负载均衡把流量分发到两个节点上，稳定性会明显好一个档次。

6. 从效率和体验角度，聊聊堡垒机日常运营的加分习惯

到这一步，堡垒机基本可以正式上岗了。但工具上了不代表万事大吉，日常运营里有哪些好习惯决定这套系统能发挥多大价值，我觉得很值得聊一聊。

6.1 定期做账号权限治理

我在季度检查时发现过一个情况：某外包同事离职几个月了，但他在堡垒机里的账号仍然是有效的。要问他为什么没被删，管理人员也答不上来，只是说“可能漏了”。为了减少这种漏网之鱼，堡垒机的账号授权规则一定要周期性复核，建议每月清理一次：

• 检查是否有长期未登录的僵尸账号，超过30天未登录就禁用。
• 检查授权规则是否出现新员工权限过大的情况，及时收敛。
• 关注提权操作日志，堡垒机的“特权操作”报表里会列出所有sudo和提权行为。

6.2 把关键操作录像用起来

很多团队搭了堡垒机之后，录像功能就从来没有回放过，只有出事故了才去翻。这种情况其实把审计的价值浪费了大半。更合理的做法是，当生产环境出现数据异常或配置被改动时，第一时间通过堡垒机的会话搜索，定位到问题时间点的操作人，直接看回放确认事故原因。

这里有个操作习惯值得培养：堡垒机界面里可以用“标签”功能，在关键操作前给会话打上一个说明标签，例如“发布版本v2.3.1”，这样回溯时直接按标签搜索，几秒钟就能定位到对应的那一次操作，不需要从几十个会话里逐个排查。

6.3 API自动化集成

堡垒机如果只靠人工点击管理，运维效率依然有瓶颈。JumpServer提供了完善的API接口，我尝试过把新员工开通堡垒机账号的流程做成了自动化脚本。流程是这样：新员工在内部工单系统提交申请后，工单系统调用堡垒机API自动创建用户、绑定用户组、同步授权规则。

这一个小小的自动化，就把原本需要运维手工操作15分钟的事情缩短到了几秒，同时减少了权限配置不一致的风险。如果你的公司有研发资源，强烈建议把堡垒机的账号生命周期流程接进工单系统，收益非常高。

结尾

最后再分享一个我个人在运维实操里的体会：不要贪功能多，先稳住核心链路。很多人第一次接触堡垒机，恨不得把所有功能都打开，命令过滤、自动改密、双因子、数据库代理、应用发布全安排上，结果最后发现出了问题无从排查，反而影响了业务访问。

我现在最推荐的做法是，先按“纳管资产—配好授权—记录审计”这三个最基础的能力起步，稳定运行后再逐步打开高级安全策略。当你真正体会过“出了问题能在一分钟内精确找到操作人、看到完整操作录像”的那种爽感，就不会再想回到过去那种靠信任和运气维护服务器的日子了。

这套方案能做的事情还有很多扩展空间，比如结合云上审计、导入Kubernetes集群节点等等。现在先把基础打好，将来再做扩展心里就有底了。