企业官网建设流程全解析

先明确一个事：很多人把堡垒机和跳板机混着叫，其实这俩根本不是同一个东西。跳板机更像一个中转入口，你通过它跳到内网服务器上，但跳上去之后干了啥，它基本不管。堡垒机不一样，它要管身份认证、权限控制、操作审计，甚至能录下你敲的每一条命令。这次我选择JumpServer来落地，就是看中它开源免费、社区活跃、功能基本对标商业堡垒机的特点。这篇文章我按自己的实际搭建过程来写，从选型思路到部署细节，再到日常使用和踩坑记录，尽量把每一步都交代清楚，让没接触过堡垒机的人也能照着搭起来。

1. 先搞清楚需求：为什么要给团队上堡垒机

1.1 没有堡垒机之前，团队是怎么管服务器的

小团队初期管服务器，基本就是一个共享账号走天下。所有人共用root，密码放在微信群里，谁要用谁自己去登。今天张三改了个配置，明天李四重启了个服务，出了问题都说是对方干的，最后查无可查。

我接手过一个维护项目，服务器有二十多台，团队六个人。出过一次线上事故：有人把生产库的索引删了，但没有人承认。因为没有操作记录，最后只能看数据库binlog慢慢分析，折腾了一晚上才定位到人。那次之后，领导当场拍板要上堡垒机。

这个场景应该是很多团队的真实写照。堡垒机解决的不只是“谁能登服务器”的问题，更重要的是“登上去做了什么”必须有据可查。

1.2 堡垒机在安全体系里的定位

从信息安全角度看，堡垒机属于运维安全审计范畴，核心功能可以拆成三块：

• 认证管理：统一入口，所有运维人员必须先登录堡垒机，再通过堡垒机跳转到目标服务器，服务器本身不直接暴露给个人。
• 权限控制：按用户、按资产、按账号粒度定义谁能访问哪台机器，细化到IP、端口、命令级别，实现最小权限原则。
• 操作审计：完整记录会话过程，包括命令行输入、屏幕录像、文件传输记录，事后可回放，形成闭环追溯。

对比一下商业堡垒机和开源方案，商业产品通常在合规报表、国密算法、硬件化方面做得更好，但价格不低。对于中小型团队，JumpServer的社区版覆盖80%以上的日常需求，完全够用。

1.3 为什么我选了JumpServer

选型的时候我对比了市面上几款开源堡垒机方案，包括一些老牌的跳板机工具。JumpServer胜出主要因为这几点：

• 功能完整：认证、授权、审计、资产纳管、数据库连接都在一个平台上解决，不用拼凑多个工具。
• 部署简单：官方提供一键部署脚本，通过Docker Compose方式拉起所有组件，半小时内能跑起来。
• 界面现代化：Web终端体验好，还能通过浏览器直接操作RDP、VNC、数据库资产，比传统只能SSH的方案强太多。
• 社区活跃：文档、issue、视频教程都很全，遇到问题基本能搜到解决方案，不会卡住。

我实测下来的结论是，JumpServer适合大多数有运维合规需求的团队，尤其是预算有限但想认真做审计的公司。

2. 部署前的准备工作：版本选择、硬件评估与架构理解

2.1 版本选择：稳定版优先

JumpServer的版本迭代很快，我在部署时选择的是当前最新的稳定发布版本。这里建议不要盲目追求最新，因为新版本偶尔会有一些还没暴露出来的问题。官方在GitHub Releases页面会明确标注稳定版和预发布版，认准稳定版下载即可。

社区版的核心功能包括资产纳管、Web终端、SSH客户端连接、录像审计、命令过滤、批量命令执行，这些足够支撑一个几百台服务器的团队日常使用。企业版则额外提供一些增值能力，比如改密计划、账号收集、合规报表、工单审批等，这些后面统一说，先按社区版搭建。

2.2 硬件与操作系统评估

关于硬件配置，官方推荐的基线是4核8GB内存、50GB磁盘。我自己的实践是：

• 测试环境：2核4GB可以跑起来，但并发会话高的时候会明显卡顿，视频录像回放也会有延迟。
• 生产环境：建议至少4核8GB起步，如果资产数量多、在线会话频繁，往上加到8核16GB会更从容。
• 磁盘：录像和日志会持续增长，建议单独挂一块数据盘，容量按每台资产每天约5MB录像文件估算，留足余量。

操作系统我选的是CentOS 7.9，因为团队现有服务器大多是这个版本，运维习惯一致。其实官方支持Ubuntu、Debian等多主流系统，选自己熟悉的就行，关键是要能正常装Docker。

2.3 JumpServer的组件架构

想要排查问题，必须先理解JumpServer的组件构成。它不是一个单体服务，而是多个组件配合工作：

• Core：核心服务，负责API、认证、资产授权、审计存储等逻辑处理。
• Koko：SSH客户端服务，负责处理通过SSH协议接入的连接。
• Lion：Web终端服务，支持通过浏览器访问RDP、VNC、SSH等协议资产。
• Celery Worker：异步任务处理，比如批量执行命令、录像转码等。
• MySQL：存储用户、资产、授权策略等元数据。
• Redis：缓存会话状态、任务队列信息。

理解这个架构之后，你会发现日常排障基本都围绕这几个组件的状态展开。比如会话连不上，优先看Koko和Core的日志；录像丢失，大概率是Celery Worker处理异步任务出了问题。

3. 实际操作：从零开始完成JumpServer的部署

3.1 环境准备：关闭防火墙和SELinux

这一步被很多人忽略，但恰恰是新手最容易卡住的地方。JumpServer需要监听80、443、2222等端口，CentOS默认的firewalld和SELinux如果不处理，后续访问会莫名其妙被拒。

我的操作顺序是：

# 1. 关闭firewalld，并禁止开机自启 systemctl stop firewalld systemctl disable firewalld # 2. 永久关闭SELinux，需要修改配置文件 sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config setenforce 0 # 3. 验证状态 getenforce

提示：setenforce 0只是临时生效，重启后还会恢复。修改/etc/selinux/config文件才是永久方案。生产环境如果安全策略不允许关闭SELinux，也可以配置放行对应的端口和策略，但复杂度会高不少。

3.2 安装Docker和Docker Compose

JumpServer的部署脚本依赖Docker Compose来编排容器。如果你的服务器之前装过旧版Docker，建议先卸载干净再重装，避免版本兼容问题。

安装Docker用官方源或者国内镜像源，执行常规安装流程即可：

# 安装依赖包 yum install -y yum-utils device-mapper-persistent-data lvm2 # 配置Docker yum源 yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo # 安装Docker社区版 yum install -y docker-ce docker-ce-cli containerd.io # 启动Docker并设置开机自启 systemctl start docker systemctl enable docker

再检查一下docker compose命令是否可用。新版Docker引擎已经内置compose v2插件，可以直接用docker compose version验证，老版本没有的话需要单独装docker-compose。

3.3 使用官方一键脚本部署JumpServer

JumpServer官方提供了一个快速部署脚本，它的作用是拉取当前最新稳定版的安装配置和镜像编排模板，然后根据交互式提示自动生成配置文件并启动容器。

# 下载并执行快速开始脚本 curl -sSL https://github.com/jumpserver/installer/releases/latest/download/quick_start.sh | bash

脚本执行过程中，它会引导你设置一些关键参数，比如安装目录、数据库配置方式等。默认情况下，MySQL和Redis会随JumpServer一起以容器方式部署，这样可以开箱即用。脚本完成后，检查所有容器是否正常运行：

docker ps

正常情况下你至少能看到jms_core、jms_koko、jms_lion、jms_celery、jms_mysql、jms_redis这些容器，状态都是Up。看到容器起来了，部署这一关就算过了一大半。

这里要提醒一下：GitHub在某些网络环境下的下载速度可能不太稳定，如果你执行脚本时长时间卡住，或者镜像拉取超时，需要自己配置镜像加速器，或者从备用源下载安装包。不过这不影响使用，目的是把整套组件拉起来。

3.4 初始化Web控制台

浏览器访问http://服务器IP（默认80端口），第一次打开会进入初始化页面。这里需要创建一个管理员账号，注意这个账号是堡垒机自己的超级管理员，不是后面创建运维用户用的普通账号。

初始化步骤通常会涉及几个配置项：

• 管理员用户名和密码：设置一个强密码，注意和业务密码区分开。
• 邮件服务器配置：如果不打算用邮件发通知，可以先跳过，后面在系统设置里补。
• 密钥配置：JumpServer会自动生成加密密钥，用于数据加密存储。

初始化完成后，登录进去看到的是JumpServer的管理控制台，到这里部署工作就算完成了。从开始装Docker到看到登录页，整个流程顺利的话半小时左右。

4. 核心功能配置：用户、资产与授权策略

4.1 创建用户：分管理员和普通用户

JumpServer的用户角色分为系统管理员、审计管理员、普通用户等。系统管理员可以管理整个平台，普通用户只能看到被授权给自己的资产。

创建普通用户的位置在控制台左侧菜单“用户管理 - 用户列表 - 创建用户”。需要填用户名、姓名、邮箱、密码等基本信息。这里建议：

• 用户名为员工工号或拼音，方便统一管理。
• 密码首次由管理员设置，并强制用户在第一次登录时修改。
• 邮箱必须真实有效，因为后续开通MFA、接收通知都会用到。

4.2 纳管资产：填入服务器的连接信息

资产纳管是堡垒机的核心，所有服务器都要在JumpServer里被当成资产管理起来，用户才能通过堡垒机跳转过去。

创建资产的入口是“资产管理 - 资产列表 - 创建资产”。对于一台Linux服务器，需要填的关键信息包括：

• 主机名：给资产起个容易识别的名字，比如“生产-应用服务器-01”。
• IP地址：服务器的内网IP。
• 协议和端口：SSH默认22，RDP默认3389。
• 账号信息：可以后续单独维护资产账号库，也可以在资产上直接填root或普通账号和密码。

这里有个实用的功能是“批量导入”。如果有一批服务器要加入，可以先下载Excel模板，把资产IP、协议、账号、端口等按模板填好，然后一次性导入，效率会高很多。

4.3 授权策略：资产和用户的绑定关系

资产建好、用户建好，两者之间还需要授权策略关联起来。授权策略的作用是规定“谁”在“什么时间”能访问“哪些资产”的“哪个账号”。

创建授权的入口是“权限管理 - 授权策略 - 创建授权规则”。我的实践习惯是：

• 按业务线分组资产，比如前端组、后端组、数据库组。
• 按角色创建授权，比如给研发人员授开发环境的Linux资产，给DBA授数据库应用资产。
• 尽量细化到资产账号级别，不要一个授权把所有资产全部开放，避免权限过大。

授权策略支持设置有效时间段，比如只在工作时间开放，这个对控制风险很有效。比如某个外包人员只需要在项目期内访问测试服务器，那授权时间就设置在项目周期内，到期自动失效。

4.4 命令过滤：限制高危命令

JumpServer支持命令过滤，这是运维安全里非常实用的一环。可以定义一组正则规则，对用户在终端里敲的命令进行实时匹配，命中后可以选择阻断或者审批。

我自己设置的过滤规则包括：

• 禁止执行rm -rf /、mkfs等破坏性命令。
• 禁止在非授权网段使用scp、rsync大量传输文件。
• 对drop table、truncate table等数据库高风险操作进行二次审批。

命令过滤配置好之后一定要先用测试账号自己试一遍，确认规则能生效再对全员开放。我见过有人配了规则但没生效，原因是协议版本选错了，过滤规则只对SSH协议生效，而实际连接走的是Web终端，两者容易混淆。

5. 日常使用实战：三种常见连接方式与审计查看

5.1 Web终端：浏览器里的Linux操作台

用户在浏览器里登录JumpServer后，进入“我的资产”，能看到分配给自己的所有资产列表。点击“连接”按钮，会在当前浏览器窗口拉起一个Web Terminal，体验和本地SSH终端几乎一样，还支持文件上传下载。

这个方式对前端同学特别友好，不用装Xshell、Putty之类的软件，打开浏览器就能干活。我测试过延迟情况，在同等网络条件下，Web终端比本地SSH客户端多了20毫秒左右的中转延迟，日常操作感知不明显，排障时如果觉得卡顿，可以记录网络链路耗时作为参考。

5.2 SSH客户端方式：用本地终端连接堡垒机

习惯用本地终端的运维人员，也可以通过SSH协议直接连接堡垒机：

ssh -p 2222 用户名@堡垒机IP

这里的2222端口是JumpServer的SSH接入端口，用户登录后进入的不是系统Shell，而是一个对话式菜单，界面上会列出你可访问的资产列表，然后按提示输入资产编号即可跳转到目标服务器。

需要注意的是，这种方式要求用户在JumpServer中开启了SSH公钥认证或者允许密码认证。默认情况下密码认证是开的，但建议生产环境把公钥认证开起来，密码认证关掉，更加安全。

5.3 数据库应用连接：MySQL、Redis都能通过堡垒机访问

JumpServer一个很方便的扩展功能是支持数据库类型资产。你可以把MySQL、Redis、PostgreSQL等数据库服务也纳管进堡垒机，用户通过Web页面连接时，JumpServer会自动拉起一个数据库客户端页面，直接操作SQL查询或数据变更。

这个能力对有数据库审计需求又不想装商业数据库审计系统的团队来说很省事。配置数据库资产的要点：

• 在创建资产时选择协议为MySQL或Redis，并填入地址、端口。
• 资产账号信息填数据库用户的连接信息。
• 授权策略中单独给DBA或开发人员配置访问数据库资产的授权。

数据库操作全程会被记录下来，包括执行的每一条SQL语句，出问题可以精确回放。

5.4 录像审计与操作回放

审计功能是堡垒机的核心价值所在。在“审计台 - 会话审计”里，可以查看所有历史会话记录，包括会话时间、用户、资产、登录IP、时长等信息，还可以点击播放录像，回看当时的屏幕操作。

录像回放对事故定位的帮助非常大。有一次我们排查线上配置被改动的问题，通过会话录像一帧一帧看，很快发现有人用Navicat直连数据库执行了敏感操作，而他的操作路径根本没有经过堡垒机。这件事反过来推动了网络层规则调整，把数据库端口收窄为仅允许堡垒机服务器访问，从根源上杜绝了绕行。

6. 进阶配置：MFA、LDAP集成与高可用规划

6.1 开启MFA多因子认证

堡垒机的账号本身就很重要，如果密码泄露，所有纳管资产都会暴露。所以我强烈建议开启MFA多因子认证。JumpServer支持TOTP动态令牌，也就是常见的Authenticator类App扫码验证。

开启方式是在“系统设置 - 安全设置”中，将两步认证开关打开。之后每个用户需要在自己的账号资料里绑定动态令牌：手机上下载一个支持TOTP的认证器，扫描JumpServer显示的二维码，再输入动态验证码即可完成绑定。

从实际使用体验看，MFA的麻烦程度很低，每次登录多花几秒钟，但安全提升是很明显的。如果用户手机丢了，管理员可以在后台重置该用户的MFA绑定，不用怕被锁死。

6.2 LDAP/AD域控集成

公司如果已经用OpenLDAP或微软AD统一管理账号，JumpServer可以直接对接，省去单独维护堡垒机用户和密码的麻烦。集成后，员工登录JumpServer时直接使用域账号密码，人员离职只要在AD里禁用账号，堡垒机就自动无法登录。

配置位置在“系统设置 - 认证设置 - LDAP/AD”。需要填写域控服务器地址、Base DN、过滤条件等。我实践中的一个建议是：先开启“用户自动导入”，让域内用户登录后自动同步到JumpServer，不要手动逐个创建。等人员同步正常后，再做授权策略的批量绑定。

6.3 备份策略与高可用规划

堡垒机上保存着所有用户、资产、授权和审计录像，一旦数据丢失，影响非常大。我建议至少做两件事：

• 数据库备份：JumpServer的元数据都在MySQL里，可以配置每日mysqldump备份到远端存储。如果MySQL是容器方式部署，需要进容器执行备份，或者使用docker exec命令在宿主机上把备份脚本写好，配合crontab定时执行。
• 配置和录像备份：配置文件目录和录像存储目录也要定期打包。尤其是录像文件，一旦磁盘损坏很难恢复。

高可用方面，社区版默认是单机部署。如果业务规模更大、对稳定性要求更高，可以考虑将MySQL和Redis外置到独立的高可用集群，再通过负载均衡把Web和Koko服务多节点部署。这样架构会复杂一些，但换来了故障容忍能力。

6.4 企业版功能值得升级吗

JumpServer社区版免费，企业版需要商业授权。企业版主要在以下几个方向做扩展：

• 自动化运维：改密计划、账号收集、资产自动发现，减轻管理员重复劳动。
• 合规报表：自动生成符合等保、审计要求的报表，减少人工整理。
• 工单审批：高危操作和资产访问走工单流程，流程化管理。
• 团队协同：多人Share会话、同事代录等场景的支持。

如果公司有等保合规要求，且预算充足，企业版确实省心。但如果没有硬性合规需求，社区版加上一些人工流程规范，也能把安全水位提得很高。

7. 部署和日常使用中遇到的典型问题

7.1 Web控制台无法访问

Web控制台打不开，我遇到的情况一般是：

• Docker容器没起来：先执行docker ps，看是否有容器处于Exited状态。然后docker logs jms_core（或对应容器名）查看日志，多半是数据库连接失败或端口被占。
• 防火墙没有放行80端口：虽然前面关了firewalld，但有的云服务器安全组也需要放行对应端口。
• Nginx容器配置问题：JumpServer前端默认通过容器内的Nginx服务入口，如果Nginx容器有异常，整体访问会受影响。

排查思路是先用curl -I http://127.0.0.1在服务器本地测试，再检查云安全组和网络策略，逐层排除。

7.2 SSH连接不上资产

这个问题出现频率最高。用户能从JumpServer登录，但点击连接资产时卡住或者超时，可能的原因有两个：

• 资产账号密码错误：建议先在本机用其他SSH工具直接连一下资产，确认账号密码没问题。
• 网络不通：JumpServer服务器和目标资产之间的网络不通。注意，JumpServer的访问链路是“用户电脑 -> 堡垒机 -> 资产服务器”，所以堡垒机本身必须能访问到目标资产的内网IP。

还有一种情况是多网段环境。JumpServer服务器在192.168.1.x网段，目标资产在10.0.0.x网段，中间没有路由，这种情况下需要通过网域功能配置网络代理跳转，让Koko通过指定的网络出口转发请求。

7.3 录像无法回放或回放卡顿

录像回放依赖Celery Worker对原始会话进行转码处理。如果录像一直加载不出来，优先看Celery Worker容器的日志，确认转码任务是否正常执行。

转码本身是CPU密集型操作，如果服务器资源紧张，批量转码会排队。操作上，不要积压太多录像才回放，定期做录像备份和清理，同时保证Celery Worker所在容器有足够的CPU配额。

7.4 用户忘记密码或MFA失效

用户密码忘了，管理员可以在“用户管理 - 用户列表 - 编辑”里重置。MFA失效（比如手机丢失、验证码总是不对），管理员在用户详情页可以关闭两步认证，让用户重新绑定。

这里有个经验：MFA解绑操作本身应该走一个审批流程，否则管理员可以私下控制任何用户的账户。我在团队里指定只有安全组负责人有这个权限，避免单人操作风险过大。

7.5 版本升级的注意点

JumpServer升级前，一定要做两件事：备份数据库和备份配置文件。升级过程中官方安装包会拉取新镜像并执行数据库迁移，如果迁移中途失败，有备份还能回滚到旧版本。

升级完成后，建议先检查所有容器状态和Web页面是否正常，再用测试账号执行一次完整的资产连接流程，确认核心链路没受升级影响，再通知其他用户恢复正常使用。

8. 部署完成后的个人体会

整套JumpServer搭完并稳定运行之后，我最明显的感觉是：以前那种“密码满天飞、操作无人认”的混乱状态彻底结束了。

有一次一个新同事入职，给他的账号做完授权之后，他直接就能看到自己权限范围内的所有测试服务器，不用再找人要密码；后来他误操作把测试环境的配置改坏了，我们通过会话录像还原了整个操作过程，第一时间定位了原因，也让他意识到每一步都会被记录。

给还想自己动手部署的人一个建议：不要一开始就追求高可用和复杂架构，先用官方一键脚本单机部署，跑通“用户->堡垒机->资产”这条主链路，再逐步加上MFA、命令过滤、LDAP这些进阶功能。等真正用起来、遇到真实业务问题了，你自然知道自己该往哪个方向优化。

最后再分享一个配置技巧：上线之后先用一两个测试账号和低风险资产试运行两周，让团队逐步适应通过堡垒机操作服务器的习惯。如果一上来就给全员推强制变更，运维同事往往抵触情绪比较大。磨合期之后，大家体会到“再也不用记一堆密码”的好处，推广阻力反而会小很多。