企业官网建设流程全解析

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能在众多堡垒机方案里被选出来，主要因为三个特点：开源免费、组件清晰、部署不复杂。

它的核心逻辑围绕着四个组件转：

• Core：Python编写的核心服务，负责用户管理、资产管理、权限规则、审计日志存储，相当于堡垒机的大脑。
• 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默认需要用到以下端口，安装前先在防火墙和安全组里放通：

如果你公司的网络策略比较严格，需要把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访问，直接写DOMAIN=192.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和Redis，KoKo通过内部地址连接Core，Web通过反向代理的方式把请求转发给Core和KoKo。这些容器之间的连接不需要你操心，Compose文件已经全部定义好了。你要关心的只是对外暴露的端口：Web控制台的80/443，SSH接入的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 jump='ssh -p 2222 myname@192.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 常见问题速查表

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 --tail=50 koko作为巡检的第一条命令。

9. 聊聊我踩过的坑和最后的一点建议

堡垒机本质上是一个“管控入口”，它不是装完就一劳永逸的工具，而是需要持续运营的流程体系。部署阶段多花一点时间把规则设计好，日常使用才会省心。

有几个具体建议，按优先级排序：

第一，MFA一定要强制开启。堡垒机集中了公司所有服务器的入口，一旦堡垒机的管理员账号被攻破，所有资产都等于裸奔。MFA是目前成本最低、效果最明显的防护措施。

第二，系统用户不要一股脑全用root。你可以用root做初始连接，但尽量在目标机器上创建一个专用账号，加入sudo权限组，通过命令过滤控制提权行为。这样即使JumpServer被入侵，对方拿到的也不是直接root权限。

第三，定期做一次权限审计。把授权规则列表导出来，逐个核对哪些用户还在活跃、哪些资产已经下线、哪些授权关系是三个月前临时加的但已经没人记得了。这种“权限清理”比装任何安全工具都有效。

第四，日志备份不要只放本机。堡垒机的审计日志是安全追责的重要依据，如果被攻击者连同服务器一起删掉，审计能力就失效了。日志定期同步到独立的日志平台或存储桶，是最好的保险。

我在实际使用中体会最深的一件事是：堡垒机不是为了限制运维人员的自由度，而是为了让所有人在出问题时能快速定位责任、恢复现场。有了这套体系之后，团队在操作生产环境时反而更自信了，因为每个操作都有迹可循，每次变更都能复盘。JumpServer的开源属性让它成为一个非常灵活的底座，你可以按团队的实际情况定制授权模型和审计策略，而不是被商业产品的固定流程绑住手脚。

最后再分享一个小技巧：如果你们团队使用JumpServer比较频繁，可以把“资产命名规范”和“用户命名规范”单独写一份简单的内部文档，和JumpServer配合使用。命名不乱，权限规则就不会乱，审计的时候才能快速定位到具体的人和机器。这个细节很多人一开始不在意，等资产上了几百台之后就知道有多重要了。