堡垒机这个词，做运维的人肯定不陌生。团队手里服务器一多，账号管理、权限分配、操作审计就全成了问题，jumpserver安装搭建的需求也基本都是从这时候冒出来的。它在国产开源运维系统里几乎是最常被提到的那一个，能解决的问题很直接：所有管理员和开发者的登录入口统一收口，资产凭据不直接暴露，每一个操作都有录像和回放，权限按人按资产去控制。刚接触这块的人，或者想在自己团队里搭一个统一运维入口，都可以照着这篇实操记录走一遍。

我最近刚在一台4核8G的云服务器上完成了一套jumpserver部署，从选版本、准备环境、执行安装脚本，到后面的基础配置和问题排查，整个过程踩了几个不大不小的坑。这篇内容不打算写成官方文档的复述，而是把我真正动手时的处理逻辑和细节写清楚。如果你现在正准备部署，或者已经被装到一半的堡垒机卡住了，这篇文章应该能帮上忙。

1. 为什么要自己部署堡垒机：先把需求想清楚

1.1 堡垒机解决的真实痛点

我见过不少团队最初的做法，就是人手一个服务器root密码，谁要连服务器就直接ssh上去了。服务器少的时候还好说，等到十台二十台的时候问题就冒出来了：有人离职了密码要不要改，改的话所有机器都要动一遍；线上出了问题想查是谁操作的，翻日志翻到头大，最后还是不知道是哪个人敲了什么命令。

jumpserver的核心思路是把“登录服务器”这个动作全部收口到一个统一入口。用户不再直接去连目标机器的IP和端口，而是先登录堡垒机的Web控制台，经过身份校验和权限校验之后，再由后端组件建立到目标资产的访问通道。这样带来的好处很直接：目标机器的密码可以托管在堡垒机里，个人手上不接触明文凭据；每一次连接和操作都有审计记录；权限可以按用户、用户组、资产、资产组做细粒度控制。本质上就是给服务器集群装了一扇带门禁和摄像头的门。

1.2 核心组件与一次访问的数据走向

jumpserver不是一个大而全的单体程序，而是由多个组件协作完成的。按我部署时接触到的版本来看，几个核心组件的分工大致如下：

这里面的关系可以理解为：CORE是大脑，负责判断“你是谁、你能连哪台机器、你有哪些权限”；KOKO和远程桌面网关是手，负责真正把手伸到目标资产上；数据库和Redis是记事本和临时备忘录，所有决策依据都从这里来。

用户一次完整的操作路径大概是这样的：用户打开Web控制台登录，浏览器把账号密码交给CORE做身份校验；登录成功后用户点击某个资产发起连接，CORE校验用户对该资产的授权；校验通过后，用户会话被接入到对应协议的接入组件，由接入组件去连接目标资产；整个操作过程的输入输出流会被记录，生成回放录像存到数据目录。

1.3 部署方式选型：为什么All-in-One最实际

部署jumpserver的方式，目前最常见的是这么几种：

我这次选的是All-in-One。理由很简单：组件多，手动部署要管数据库初始化、Redis连接、各组件之间的密钥配对，任何一个环节出错排查起来都费劲。用Docker Compose可以把所有组件编排在一起，版本一致性有保证，升级也走官方脚本。对于大多数场景来说，All-in-One已经足够可靠，后续真到了性能瓶颈再考虑拆分也不迟。

1.4 硬件与项目规划

资源规划这块，我直接说结论：

• 纯测试环境：2核4G可以跑，但只建议体验功能。
• 生产环境最低建议：4核8G，磁盘独立数据盘50GB以上。
• 团队规模大、并发连接多：8核16G起，磁盘按录像量再单独评估。

这里有一个很多人容易忽略的点：磁盘。录像和日志是这个系统里增长最快的两类文件。字符会话的录像体积不大，但是图形会话录像，也就是RDP/VNC的操作录制，是按小时甚至百MB级别累积的。如果系统盘本身就不大，用不了多久就会被撑满。我在部署前就单独准备了一块数据盘，安装目录和容器数据都往数据盘上放，后面会细说怎么规划。

域名规划同样值得提前想清楚。如果只是内网用IP访问，问题不大。如果后续要挂域名、上HTTPS证书，建议一开始就把端口和访问方式定下来，避免后面再返工改配置。

2. 环境准备：系统、Docker与网络三件事

2.1 操作系统与基础设置

jumpserver对操作系统的要求不算苛刻，主流Linux发行版都能跑。我在部署时用的是Ubuntu 22.04 LTS，官方文档对它的支持也相对完善，如果你手头没有特别偏好，照这个来就行。CentOS 7.9也能装，但系统本身已经进入维护尾声，新部署就不推荐了，更建议考虑Debian 12或者Ubuntu 22.04这类还长期维护的版本。

系统装好之后，第一件事是把时区设置好。时区不对，后面Session录像打出来的时间和实际对不上，审计的时候很尴尬。命令很简单：

sudo timedatectl set-timezone Asia/Shanghai timedatectl

低配机器建议顺手加一点swap。jumpserver启动时要同时拉起数据库、Redis、Web服务、协议网关等多个容器，内存压力集中在启动那几分钟。2G内存的机器如果不加swap，很容易在初始化阶段被系统OOM杀掉。

2.2 安装Docker和Compose插件

新版Docker推荐使用包含Compose插件的安装方式。我用的是发行版仓库自带的docker.io，好处是跟系统集成度高，少折腾源的问题。命令如下：

sudo apt update sudo apt install -y docker.io docker-compose-plugin sudo systemctl enable --now docker docker --version docker compose version

执行完上面几条命令，Docker和Compose插件就绪。如果你是在内网环境部署，需要提前准备好离线镜像包，或者把Docker的registry mirror配置好，否则后面拉取镜像时会有漫长的等待。这个配置写在/etc/docker/daemon.json里，改完重启Docker生效。

2.3 端口与防火墙放行

默认情况下，All-in-One部署会用到这些端口：

这里有个容易踩坑的地方：Docker服务起来之后会往iptables里写入规则，端口映射本身没有问题，但云主机的安全组如果没放行80端口，外部依然访问不到。反过来也是一样，安全组放行了80，主机防火墙没放行，同样不行。两层都要检查。

我的处理方式是：对外访问尽量只开80和443，用于运维管理的22端口限制到内部办公网段，组件间通信端口全部走Docker内部网络，不对公网暴露。这样即使堡垒机本身出了安全问题，攻击面也小很多。

2.4 数据目录与磁盘挂载

安装目录约定俗成放在/opt/jumpserver，后续升级脚本也默认往这个目录找。部署前我先检查了数据盘的情况：

lsblk sudo mkfs.ext4 /dev/vdb sudo mkdir -p /opt/jumpserver sudo mount /dev/vdb /opt/jumpserver echo '/dev/vdb /opt/jumpserver ext4 defaults 0 0' | sudo tee -a /etc/fstab mount -a df -h

注意一点：如果目标数据盘要挂到/opt/jumpserver，一定要在安装之前挂载完成。装到一半再去挂载，目录里的数据会被新挂载点挡住，看起来就像数据凭空消失了。

3. 完整安装过程：从下载到首次登录

3.1 获取Release安装包

安装包从官方发布页直接下载就行。我习惯在/opt目录下载，解压后目录名自带版本号，方便后面做多版本切换。

cd /opt wget <官方发布页提供的下载地址> tar xf jumpserver-release-xxx.tar.gz cd /opt/jumpserver-release-xxx ls -l

解压后目录里能看到quick_start.sh、.env.example、docker-compose.yml这些关键文件。.env.example是环境变量模板，真要开始装之前，先把它复制成.env再改。

3.2 修改.env前的关键决策

.env是整套部署的核心配置，里面变量很多，但真正需要关心的没有几个。我整理了这几个必看项：

cp .env.example .env vim .env

改.env的时候，SECRET_KEY和BOOTSTRAP_TOKEN这两项一定要写上自己生成的随机值。生成随机串的办法很多，最简单的：

echo $RANDOM$(date +%s) | md5sum

拿到结果后贴到.env对应位置。这两串字符是整套系统的“命根子”：升级时要保持一致，恢复时要保持一致，组件间互相通信也要靠BOOTSTRAP_TOKEN校验身份。一旦中间变了，轻则组件连不上，重则加密数据解不开。改完配置后，把这两项单独备份一份到密码管理器里。

提示：.env备份这件事，很多人在安装时完全不重视，直到第一次升级失败才追悔莫及。我和身边朋友都吃过这个亏，提前写在这里，希望你能绕开。

3.3 执行一键安装脚本

所有前置工作就绪之后，执行安装：

cd /opt/jumpserver-release-xxx ./quick_start.sh

脚本做的事情大致是：检查Docker环境、读取.env配置、拉取所需镜像、生成并启动容器、初始化数据库。第一次执行时大部分时间都花在拉镜像上，耐心等就行。如果网络条件不理想，建议提前把registry mirror配置好，能明显缩短这个阶段的时间。

脚本执行完，终端会输出初始管理员的账号信息。这一步不要急着关终端，或者先把输出截图存下来，后面登录要用。

3.4 安装结果核验

安装完成不等于所有容器都正常启动，一定要动手核验一遍。我习惯先看容器状态：

docker ps

正常情况下，核心的几个容器都应该是Up状态。然后看核心服务日志，确认Web服务是否真的就绪：

docker compose logs -f core

日志输出稳定之后，在浏览器里访问http://服务器IP/，正常会跳到登录页。第一次访问看到登录界面，基本可以判定安装成功。

3.5 首次登录后的三件事

用脚本输出的初始管理员账号登录之后，我建议立刻做三件事，顺序按紧急程度排：

第一，修改默认密码。初始密码是随机的，但为了保险起见还是改掉，并且设置的复杂度要高一点。第二，打开多因素认证。堡垒机管着所有服务器的登录入口，多一层验证就多一道防线。第三，把之前备份的SECRET_KEY、BOOTSTRAP_TOKEN以及数据库相关账号密码整理好，放进密码管理器。后续配置LDAP、对接外部系统、执行升级恢复，都会用到这些信息。

4. 生产化配置与日常维护

4.1 会话录像的容量规划

录像文件是这个系统里吃磁盘的主要来源之一。字符会话，也就是SSH操作的录制，本质是文本型操作记录，体积很小，哪怕一天几十次操作也就几MB到几十MB。但图形会话完全不一样，RDP和VNC的操作录制是视频流，一个小时可能要占用几百MB甚至1GB以上。

我按一个20人团队的场景估算过：假设每天有40次图形会话，平均每次半小时，按每小时400MB估算，一个月就是240GB左右。这个数字很惊人，所以磁盘规划一定不能只看初始占用。

实际操作层面的建议有这么几点：录像存储路径要落在独立数据盘上；监控磁盘使用率，超过70%就要开始处理；定期清理已经没有审计价值的旧录像，或者把录像归档到对象存储。不要等到磁盘告警才想起来处理，那时候可能已经影响正常录像写入和会话录像回放了。

4.2 账号统一认证对接思路

团队规模小的时候，直接在堡垒机里维护用户账号问题不大。人一多，尤其是已经有企业统一账号体系的情况，再逐个在堡垒机里建账号就是重复劳动，而且容易出现人离职了堡垒机账号还在的情况。

更合理的做法是把认证源接到统一目录上。常见的方式有LDAP接入和OAuth协议对接两类。LDAP适合内部有用户目录服务的组织，账号密码统一在那里维护；OAuth适合企业内部已有统一登录门户的场景，用户点一下就可以用企业账号登录。

我建议的节奏是：先在控制台完成LDAP或OAuth配置，小范围试测几个账号，确认登录通畅之后再推广到全团队。同时，保留本地管理员账号作为紧急通道，不要把所有登录方式都绑到外部认证源上，否则外部认证一抖动，所有人都会被挡在门外。

4.3 升级与备份策略

升级这件事，最大的禁忌是“不备份就动手”。我给自己定的流程是这样：

升级步骤本身不复杂：备份完成后，下载新版本release包，解压后执行官方升级脚本，恢复容器，检查日志。真正容易出问题的从来都不是升级这个过程，而是备份不完整导致无法回滚。保留上一版本release包的目录，也是一种简单有效的回滚手段。

4.4 常用的安全加固项

安装完成只是起点，安全加固要做在前面。几个我实际操作中认为性价比最高的加固项：

• 调整Web访问方式，把纯HTTP改成HTTPS，避免登录密码在网络上明文传输。
• 管理入口限制来源IP，即使是内网环境，也只允许办公网段访问管理后台。
• 关闭不需要的端口暴露，只保留Web访问和必要的管理通道。
• 定期清理长期未使用的账号、资产和授权关系。
• 目标资产的托管密码要定期轮换，减少凭据泄露后的影响面。

这些都是常规操作，并不复杂，但能显著降低系统被攻击的风险。堡垒机本身的定位就是高权限系统，一旦被攻破，等于所有服务器都暴露了，所以安全方面花的每一分钟都值得。

5. 常见问题与排查实录：五个真实坑位

5.1 页面打不开但容器都正常

有一次我部署完成后在浏览器里访问页面，转了半天空白。docker ps看所有容器都是Up状态，很让人困惑。后来排查发现是云主机安全组只放行了22端口，根本没放行80端口。Docker内部的端口映射没问题，但流量进不了主机，页面自然打不开。

排查这个问题，我通常按这个顺序来：先在本机curl http://localhost/看看响应是否正常；如果正常，说明服务本身没问题，问题在网络层；接着检查防火墙状态和安全组规则；再不行就去看核心容器的访问日志，确认请求是否真的到达。很多“装好了却访问不了”的问题，最后都出在端口放行这一层。

5.2 数据库初始化超时导致服务异常

第一次启动时，数据库容器需要初始化数据，这个过程可能持续几分钟。如果在数据库还没有就绪时后台服务就已经开始连接，就会出现“数据库连接失败”或者登录报错的情况。我在测试环境就遇到过安装脚本执行完了，但打开页面登录时报数据库异常。

处理方式很简单：先等几分钟，然后重启后台服务容器。

docker compose restart core

如果依然不行，就把整套编排整体重启一次：

docker compose down docker compose up -d

数据库初始化完成之后，这个问题基本不会再出现。这里想提醒的是，看到报错不要第一时间就去改动配置文件，先确认是不是初始化时序导致的临时问题。

5.3 磁盘空间被日志和录像吃满

磁盘报警是我在运维过程中见过最高频的问题之一。Docker默认会把容器标准输出日志全部收集到json格式的日志文件里，如果一直不清理，/var/lib/docker/containers目录会越来越膨胀。再加上录像文件不断累积，磁盘告警几乎是必然发生的。

我的处理方案是提前给Docker配好日志轮转规则，在/etc/docker/daemon.json里加上：

{ "log-driver": "json-file", "log-opts": { "max-size": "20m", "max-file": "5" } }

保存后重启Docker生效。注意这个操作会影响所有容器，尽量选在维护窗口执行。录像文件的清理，则通过堡垒机自身的审计数据管理策略设置定期清理，避免手动挨个删。

5.4 内存不足引发容器被杀

在资源比较紧张的机器上部署，最典型的故障是容器莫名其妙消失，docker ps看不到，但docker ps -a能看到容器处于Exited状态。这种情况大概率是系统内存耗尽触发了OOM，把占用内存较多的容器进程杀掉了。

低配机器上我建议这样处理：给系统配置swap，至少和内存等量；使用docker compose的资源配置，限制每个容器能使用的内存上限；启动时观察内存占用曲线，确认swap和内存的配合情况。更稳妥的办法是直接把机器规格升上去，尤其在生产环境，内存这种资源真的不适合抠。

5.5 升级后组件之间认证失败

升级完成之后，后台服务可能报出组件之间访问异常的日志，比如令牌验证失败、核心服务拒绝请求这类信息。排查这类问题的第一站不是网络，而是确认.env里的SECRET_KEY和BOOTSTRAP_TOKEN有没有发生变化。升级脚本正常不会改动这两个值，但如果你中间手动覆盖过.env，或者恢复配置时用错了文件，这两个值一变，组件之间的信任关系就断了。

处理方式也比较直接：用之前备份好的.env替换回去，重启整套服务。这也是为什么前面反复强调这几个密钥一定要提前备份的原因。

备份这件事，我每次升级前一定会做一遍，因为丢过数据才懂得心疼。希望这篇jumpserver安装搭建的记录能帮你少走一圈弯路，把系统尽快跑起来，也把运维的基础规范立起来。