本文由 莫潇羽@无忆研习社（www.wuyi.wiki） 原创撰写，转载请注明出处。
快速摘要
核心结论一览（适合快速阅读）
JumpServer 是什么： 全球首款完全开源的堡垒机（运维安全审计系统），遵循 GNU GPL v2.0 开源协议，符合 4A 规范（认证 Authentication、授权 Authorization、账号 Accounting、审计 Auditing），用 Python/Django 开发，目前已演进至 v4.x 版本，并在 v4.10 LTS 中正式融合 PAM 特权账号管理能力。
关键数据： 2014 年开源，12 年持续迭代，GitHub Star 突破 3 万，累计部署超 50 万次，服务 3000+ 企业，发布 260+ 个版本。
核心能力： 统一浏览器访问入口，支持 SSH、RDP、数据库、Kubernetes、Web 等多类型资产，具备命令过滤、会话录像、MFA 认证、PAM 特权账号管理等能力。4 核 8G 的机器即可运行，一条命令完成快速部署。
往下看有更详细的架构原理拆解、组件解析和完整操作指南。
一、运维安全的现实困境
任何一家有一定规模的互联网公司或传统企业，都绕不开一个问题：服务器越来越多，人员越来越杂，权限越来越难以管理。
早年间，大家的做法很粗暴——把一台有公网 IP 的服务器当"跳板机"，所有运维人员先 SSH 登录到这台机器，再从这里跳到内网的目标服务器。这个方案在小团队里勉强能用，但随着公司规模扩大，问题就暴露出来了：
跳板机本质上只是一台普通服务器，它解决了"网络可达性"的问题，却完全没有能力回答以下这些关键问题——谁登录了哪台机器？在上面执行了什么命令？出了事故该找谁负责？某个已离职员工的账号有没有及时注销？运维人员有没有对数据库执行了危险的 DROP TABLE？
一旦发生数据泄露或误操作，往往难以溯源，法律层面的举证也无从谈起。与此同时，多人共用同一组账号密码这种情况在不少公司里依然普遍，安全隐患相当严重。
这就是堡垒机诞生的背景。而 JumpServer，正是这一领域中开源界最具代表性的解决方案。
二、从跳板机到堡垒机：一个概念的演进
要理解 JumpServer，先得搞清楚"堡垒机"和"跳板机"的区别。
跳板机（Jump Host），顾名思义，就是一台作为中间节点的服务器，运维人员先登录跳板机，再从跳板机跳转到目标服务器。它的作用只是网络层面的中转，本身不具备任何权限管控、操作审计的能力。
堡垒机（Bastion Host），则是在跳板机的基础上，增加了一套完整的安全管控体系。行业里通常用"4A 规范"来描述它需要覆盖的能力：
- 认证（Authentication）：用户是谁？支持密码、密钥、MFA、LDAP/AD 等多种验证方式，确保"你是你声称的那个人"。
- 授权（Authorization）：你能做什么？基于角色和资产节点进行细粒度权限分配，不同的人只能看到并访问被授权的资产。
- 账号（Accounting）：谁拥有什么账号？统一管理系统账号与资产凭据，实现账号的全生命周期管理。
- 审计（Auditing）：你做了什么？全程录像、命令记录、文件传输记录，事后可回放、可检索、可取证。
JumpServer 正是一套完整实现了 4A 规范的开源堡垒机系统。它的核心价值在于：以软件的方式，为企业构建一套"事前授权、事中管控、事后审计"的运维安全闭环，而无需为此购买动辄数十万元的商业硬件堡垒机。
三、JumpServer 是什么
JumpServer 由飞致云（FIT2CLOUD）旗下团队主导开发和维护，其开源项目于 2014 年 6 月写下第一行代码，同年 8 月发布 v0.1.0 版本，是迄今为止全球范围内部署量最大的开源堡垒机产品。
项目的 GitHub 地址为：https://github.com/jumpserver/jumpserver
技术选型上，JumpServer 使用 Python/Django 作为核心后端框架，前端遵循 Web 2.0 规范，提供了浏览器原生的 Web Terminal，无需在客户端安装任何插件即可完成所有运维操作。这一点在实际使用中极为友好——哪怕是第一次接触堡垒机的运维新人，也能在几分钟内上手。
从定位上看，JumpServer 不仅是一个"让你跳转到服务器的工具"，更是一套完整的特权访问管理平台（PAM, Privileged Access Management）。它可以统一纳管包括 Linux/Windows 主机、网络设备、各类数据库、Kubernetes 集群、Web 应用在内的多种 IT 资产类型，覆盖企业 IT 运维的绝大多数场景。
截至 2025 年，JumpServer 已累计部署超过 50 万次，服务超过 3000 家企业客户，覆盖金融、制造、物流、媒体、互联网等行业，并在 2025 年 5 月发布了重要的 v4.10 LTS 长期支持版本，将 PAM 特权账号管理能力正式融合进主干产品。
四、JumpServer 的系统架构原理
理解 JumpServer 的底层架构，是用好它的关键。整个系统采用分层架构设计，由外到内依次分为：负载层、接入层、核心层、数据层和存储层。这种分层思路使得 JumpServer 既能以单机形式运行在 4 核 8G 的普通虚拟机上，也能通过水平扩展支撑数万台资产的大规模企业环境。
4.1 整体架构分层
负载层是整个系统的流量入口，通常由 Nginx 担任反向代理和负载均衡的角色，负责将外部 HTTP/HTTPS 请求、WebSocket 请求以及 SSH 流量分发到后端各个组件。在分布式部署场景下，也可以引入 HAProxy 等专业负载均衡软件。
接入层是 JumpServer 架构中最具特色的部分，由若干专用的协议接入组件构成，每个组件负责处理特定类型资产的连接协议。
核心层（Core）是系统的大脑，承担权限校验、用户管理、资产管理、授权规则引擎、审计数据写入等所有业务逻辑，由 Django 二次开发而来，内置了 Celery 异步任务调度、Gunicorn 应用服务器、Daphne WebSocket 服务等关键进程。
数据层由 MySQL（或 MariaDB）和 Redis 组成。MySQL 负责持久化存储所有业务数据，包括用户信息、资产列表、授权规则、命令记录、审计日志等；Redis 则承担会话状态共享、Celery 任务队列、缓存加速等职责，在多节点部署时尤为重要——多个 Koko 实例需要借助 Redis 来共享会话状态。
存储层主要用于存放会话录像文件。本地部署时默认存放在 /opt/jumpserver/data/media 目录下；生产环境中强烈建议对接对象存储服务（如阿里云 OSS、华为云 OBS、MinIO 等），以应对海量录像文件的存储压力。
4.2 核心组件详解
JumpServer 的接入层由以下几个专用组件构成，它们各司其职，共同支撑起对多协议、多类型资产的连接能力：
Core（核心服务）
Core 是整个系统的控制中枢，运行在 8080 端口（HTTP）和 8070 端口（WebSocket）。所有其他组件在启动时都需要向 Core 注册自身，注册过程使用一个预共享的 BOOTSTRAP_TOKEN 进行身份认证。Core 负责维护用户会话、权限策略、资产凭据等核心数据，并通过 RESTful API 向各组件提供服务。
Koko
Koko 是 Go 语言重写的 SSH/SFTP 服务组件，专门服务于类 Unix 资产（Linux、BSD 等）。它监听 2222 端口提供 SSH 服务，同时在 5000 端口提供 WebSocket 接口供浏览器的 Web Terminal 使用。
当用户通过浏览器打开 Web Terminal 或通过 SSH 客户端连接到堡垒机的 2222 端口时，实际上建立的是与 Koko 的连接。Koko 在收到用户的连接请求后，会向 Core 查询该用户对目标资产的授权情况，校验通过后才代理建立到目标资产的真实 SSH 连接。
整个过程中，Koko 会实时解析用户输入的命令，与 Core 中配置的命令过滤规则进行匹配。一旦触发高危命令（如 rm -rf /），可以立即阻断并告警。会话结束后，Koko 将操作录像（本质上是一个带时序的 JSON 日志文件）上传到 Core 的存储目录，供后续审计回放。
Lion
Lion 负责处理 RDP 和 VNC 协议，用于 Web 端访问 Windows 资产。它基于 Apache Guacamole 项目进行改造，使用 Golang 和 Vue 重构了 Guacamole 的 RDP/VNC 协议栈，使 Windows 远程桌面操作可以直接在浏览器中进行，无需安装 Windows 远程桌面客户端。
Magnus
Magnus 是 JumpServer 的数据库代理组件，支持 MySQL、MariaDB、PostgreSQL、Redis 等主流数据库的代理直连。它的独特之处在于：用户可以使用 Navicat、DBeaver、SQLyog 等本地原生数据库客户端，透过 Magnus 组件以代理直连的方式访问受管控的数据库资产，而无需在客户端手动配置数据库账号密码——Magnus 会在中间层自动注入由 JumpServer 托管的数据库凭据。
Razor
Razor 是专为 JumpServer Client（桌面客户端）设计的 RDP 协议组件，是 JumpServer Client 访问 Windows 资产的默认方式，提供比浏览器方式更接近原生的 Windows 远程桌面体验。
Chen
Chen 是以 Web GUI 方式访问数据库的组件，相当于在浏览器里内嵌了一个数据库管理界面，用户无需安装任何本地数据库客户端即可对数据库资产进行查询和操作。
Celery
Celery 是 JumpServer 的异步任务处理组件，负责执行账号推送、批量改密、硬件信息采集、审计数据汇总等后台定时任务。
Lina 与 Luna
这两个是纯前端静态文件项目。Lina 是基于 Vue + Element UI 构建的管理控制台前端；Luna 是基于 Angular CLI 构建的 Web Terminal 前端。二者最终由 Nginx 整合并对外提供服务。
4.3 一次完整的 SSH 访问流程
理解上述组件之后，我们来梳理一下用户通过浏览器访问一台 Linux 服务器的完整链路，这有助于在实际运维中快速定位问题：
用户浏览器
│
▼
Nginx（80/443 端口，反向代理）
│ HTTP/HTTPS 请求分发
├──► Lina（/ui/ 路径，管理控制台静态页面）
├──► Luna（/luna/ 路径，Web Terminal 静态页面）
│
│ WebSocket 代理
└──► Koko（/koko/ 路径，ws://host:5000）
│
│ 1. 用户建立 WebSocket 连接
│ 2. Koko 向 Core API 查询用户权限
│ 3. Core 返回授权的资产列表与凭据
│ 4. Koko 代理建立到目标资产的 SSH 连接
│ 5. 会话过程中实时解析命令，匹配过滤规则
│ 6. 会话结束后上传录像到 Core 存储
▼
目标 Linux 服务器（22 端口）对于 Windows 资产，链路中的 Koko 被替换为 Lion 组件，使用 RDP/VNC 协议；对于数据库资产，则由 Magnus 或 Chen 组件处理。核心的权限校验和审计数据写入始终由 Core 负责。
4.4 Koko 的内部工作机制
Koko 是整个系统接入层中实现最为复杂的组件，理解它的内部工作方式有助于排查各类连接故障和命令过滤失效的问题。
Koko 启动时，会使用配置文件中预设的 BOOTSTRAP_TOKEN 向 Core 的 /api/v1/terminal/terminals/ 接口发起注册请求，注册成功后获取一个专属的 Service Account Token，用于后续所有与 Core 之间的 API 通信。这一机制确保了只有经过授权的 Koko 实例才能接入 JumpServer 系统，防止非法节点伪装接入窃取凭据。
用户通过 SSH 客户端连接到 Koko 的 2222 端口时，Koko 会首先验证用户凭据（账号密码或公钥）。认证通过后，Koko 向 Core 查询该用户被授权的资产列表，并以交互菜单的形式展示给用户选择，或者直接指定要连接的资产（通过 SSH 目标格式 ssh 用户名@资产IP@JumpServer地址 -p 2222）。
确定连接目标后，Koko 再向 Core 请求该资产对应账号的实际凭据（密码或私钥），Core 将加密存储的凭据解密后返回给 Koko，Koko 据此建立到目标资产的真实 SSH 连接。整个凭据传输过程在内部网络中完成，外部用户完全感知不到实际的密码内容。
在会话过程中，Koko 持续捕获用户的键盘输入，当检测到回车键（命令提交信号）时，提取并解析当前完整的命令字符串，与 Core 中配置的命令过滤规则进行匹配。匹配到拒绝规则时，Koko 会在向目标资产发送该命令之前将其拦截，向用户返回拒绝提示，同时通过 Core API 写入一条命令拦截审计记录，并根据配置决定是否触发告警通知。
会话录像的实现方式也颇具巧思。Koko 并不是真正意义上的"视频录制"，而是以 JSON 格式记录每一个输出字符及其精确的时间戳，形成一份时序操作日志。回放时，前端根据这份时序日志在浏览器中模拟重放，效果上与视频无异，但文件体积要远小于真正的视频文件，在大规模部署中能节省大量存储空间。
4.5 组件间的通信安全
JumpServer 各组件之间的通信安全主要依靠两层机制保障。
第一层是 BOOTSTRAP_TOKEN 注册机制，各接入组件（Koko、Lion、Magnus 等）在首次启动时必须携带有效的 BOOTSTRAP_TOKEN 向 Core 完成注册，注册后才能获取 Service Account 凭据。这个 Token 是一次性使用的注册令牌，注册完成后可以从配置文件中删除。
第二层是 SECRET_KEY 加密机制。JumpServer 在安装时会生成一个 50 位以上的随机字符串作为 SECRET_KEY，用于对数据库中存储的敏感数据（如资产账号密码）进行 AES 加密。这个密钥需要妥善保管，一旦丢失将导致所有加密的账号凭据无法解密恢复。在备份和迁移时，务必同时备份 SECRET_KEY。
# 生成安全的 SECRET_KEY
cat /dev/urandom | tr -dc A-Za-z0-9 | head -c 50; echo
# 生成 BOOTSTRAP_TOKEN
cat /dev/urandom | tr -dc A-Za-z0-9 | head -c 24; echo生产环境中，这两个密钥的值应配置在系统环境变量或 Docker Compose 的 .env 文件中，不要直接写入代码仓库。
五、JumpServer 的核心功能详解
5.1 资产管理：统一纳管一切
资产管理是 JumpServer 的基础能力。系统支持将以下类型的资产纳入统一管理：
- Linux/Unix 主机（通过 SSH/Telnet 协议）
- Windows 主机（通过 RDP/VNC 协议）
- 网络设备（支持 Cisco、Huawei 等主流网络设备的 SSH 管理）
- 数据库（MySQL、PostgreSQL、MariaDB、Oracle、Redis、MongoDB 等）
- Kubernetes 集群（支持直接在 Web Terminal 中执行 kubectl 命令）
- Web 应用（支持将内部 Web 系统纳入 JumpServer 的访问控制体系）
- 云服务（支持与阿里云、AWS、华为云等公有云 API 集成，自动同步云主机列表）
资产可以按照节点（Node）树状结构进行组织管理，类似于文件夹目录层级，便于大规模资产的分类维护。支持通过 CSV 批量导入资产，也支持与 CMDB 系统集成，实现资产信息的自动同步。
每个资产可以绑定多个账号（即登录这台机器所使用的系统用户），账号的密码和密钥可以由 JumpServer 统一托管——用户登录目标资产时，无需知道资产的实际密码，所有凭据由 JumpServer 在代理层自动填充。
5.2 权限控制：细粒度的授权体系
JumpServer 的权限控制基于"用户/用户组 + 资产/资产节点 + 账号 + 时间"四个维度构建授权规则，颗粒度极细。
一条授权规则可以定义：哪些用户（或用户组）在哪个时间段内，可以使用哪个账号，访问哪些资产（或资产节点下的所有资产），并且在访问过程中允许执行哪些操作（是否允许上传、下载文件、复制粘贴等）。
对于有复杂组织结构的企业，JumpServer 支持多租户（Organization）体系，不同的业务部门可以在同一套 JumpServer 系统下拥有各自独立的资产空间、用户体系和权限策略，互不干扰。
5.3 命令过滤：主动拦截高危操作
命令过滤是 JumpServer 安全能力中最为核心的功能之一，在实际生产环境中极具价值。
管理员可以在 JumpServer 中预先定义"命令过滤器"，为不同的资产或用户组配置允许/禁止执行的命令规则。规则支持正则表达式，覆盖能力极为灵活。例如：
# 禁止执行 rm 命令（防止误删文件）
^rm\s
# 禁止执行 shutdown 和 reboot
^(shutdown|reboot|halt|poweroff)
# 禁止 DROP TABLE 类 SQL 语句（数据库安全）
(?i)drop\s+(table|database)当用户执行的命令匹配到禁止规则时，JumpServer 可以选择直接阻断并返回错误提示，同时产生告警事件通知管理员。这一机制能有效防止运维人员因手误或权限滥用导致的生产事故。
5.4 会话审计与录像回放
所有通过 JumpServer 发起的会话都会被完整记录。审计数据包含以下几个层次：
命令记录层面，JumpServer 会提取用户在终端中实际执行的每一条命令，连同执行时间、所在资产、操作账号一并存入数据库，支持全文检索。
会话录像层面，整个终端会话被录制为可回放的视频（本质上是带时序的操作日志），管理员可以在 Web 界面中按时间轴回放任意历史会话，就像看视频一样查看当时的每一步操作细节。
文件传输记录层面，通过 SFTP 或 RZ/SZ 进行的所有文件上传、下载操作都会被记录，包括文件名、大小和传输方向。
实时监控层面，管理员可以查看当前所有在线会话的实时状态，并在必要时强制断开某个正在进行的会话。
5.5 MFA 多因子认证
JumpServer 支持 TOTP（Google Authenticator 类型的动态口令）作为第二认证因素。在公网暴露堡垒机访问地址或远程办公场景下，强烈建议为所有用户开启 MFA 认证。
JumpServer v4.10 LTS 进一步引入了 Passkey 作为 MFA 选项，支持使用硬件安全密钥（FIDO2 标准）进行无密码登录。同时，该版本还新增了 AI 人脸识别认证能力，通过毫秒级活体检测算法，有效防范照片和视频冒充攻击，可在高危操作执行前触发人脸验证，进一步筑牢访问安全防线。
5.6 批量运维与自动化
JumpServer 集成了 Ansible，支持在 Web 界面中向批量资产下发命令，无需逐台登录。这一功能在需要对大量服务器执行相同操作时（如批量安装软件、批量修改配置）效率极高，同时整个批量操作过程也会被完整审计记录。
六、部署实战：从零搭建 JumpServer
6.1 环境要求
JumpServer 对基础环境的要求如下：
|
资源 |
最低配置 |
推荐配置（生产） |
|
CPU |
2 核 |
4 核及以上 |
|
内存 |
4 GB |
8 GB 及以上 |
|
磁盘 |
50 GB |
200 GB 及以上（含录像存储） |
|
操作系统 |
Linux x86_64 / ARM64 |
CentOS 7/8、Ubuntu 18.04/20.04/22.04 |
|
Python |
3.x |
— |
|
数据库 |
MySQL 5.7+ / MariaDB 10.x |
MySQL 8.0 |
对于运维人员较多、资产规模较大的企业，建议单独规划数据库服务器，并将录像存储对接至对象存储服务，以避免磁盘 I/O 成为瓶颈。
6.2 一键快速部署（推荐入门使用）
官方提供了一个自动化安装脚本，适合快速体验和中小规模部署。执行以下命令即可完成全部安装流程：
curl -sSL https://github.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash脚本会自动完成 Docker 环境检测、镜像拉取、数据库初始化、配置文件生成等所有步骤。安装完成后，通过浏览器访问服务器 IP 的 80 端口即可打开 JumpServer 管理控制台，初始账号为 admin，初始密码为 ChangeMe（请务必在首次登录后立即修改）。
值得注意的是，一键脚本本质上是基于 Docker Compose 的容器化部署，它会在系统上拉起包含 Core、Koko、Lion、Magnus、Nginx、MySQL、Redis 在内的完整服务栈，每个组件都运行在独立容器中。
6.3 Docker Compose 手动部署
如果需要对部署过程有更多控制，可以使用 Docker Compose 手动部署。首先拉取官方的安装包：
# 下载最新版本的安装包
wget https://github.com/jumpserver/jumpserver/releases/download/v4.10.0/jumpserver-installer-v4.10.0.tar.gz
tar -xf jumpserver-installer-v4.10.0.tar.gz
cd jumpserver-installer-v4.10.0
# 执行安装
./jmsctl.sh install安装过程中会交互式地询问数据库配置、Redis 配置、外部访问地址等参数。安装完成后，常用的管理命令包括：
# 启动 JumpServer
./jmsctl.sh start
# 停止 JumpServer
./jmsctl.sh stop
# 查看运行状态
./jmsctl.sh status
# 升级版本
./jmsctl.sh upgrade
# 数据备份
./jmsctl.sh backup_db6.4 分布式高可用部署
对于资产数量超过 2000 台、实时会话数超过 200 条的大规模企业，单机部署往往无法满足性能需求，此时需要采用分布式架构。
主备架构是最简单的高可用方案：部署两套 JumpServer，通过 Keepalived 或云负载均衡实现主备切换，审计录像统一存储在对象存储服务中。主备两套系统共享同一个数据库，当主节点故障时，备节点接管流量，保障业务连续性。
分布式集群架构适用于资产数量超过 1 万台的超大规模场景：Core 组件水平扩展部署多个实例，Koko、Lion、Magnus 等接入组件也各自部署多个实例，通过 Redis 共享会话状态，Nginx 在前端进行负载均衡。数据库可以进一步采用主从架构或分片方案应对高并发读写压力。
多区域部署则适用于企业在多个地域有数据中心的场景。JumpServer 提供"服务端点"功能，可以为不同地域的资产指定就近的接入节点，例如为北京区域的资产指定部署在北京的 Koko 实例，为上海区域的资产指定部署在上海的 Koko 实例，从而解决跨地域运维的网络延迟问题。
下面是一个典型的分布式部署场景下 Docker Compose 扩展配置示例，展示如何将 Koko 服务扩展为多实例以支撑更高并发：
# docker-compose.override.yml 示例（扩展 Koko 实例数量）
version: '3'
services:
koko:
deploy:
replicas: 3 # 扩展为 3 个 Koko 实例
environment:
- SHARE_ROOM_TYPE=redis # 多实例必须使用 Redis 共享会话
- REDIS_HOST=redis
- REDIS_PORT=6379
nginx:
# 配置 upstream 将请求分发到多个 Koko 实例
volumes:
- ./nginx/upstream.conf:/etc/nginx/conf.d/upstream.conf在正式的生产分布式部署中，还需要考虑以下几个关键点：
第一，数据库连接池优化。随着并发会话数增加，MySQL 连接数会成为瓶颈。建议在 Core 的配置文件中合理设置数据库连接池大小，并在 MySQL 端适当调大 max_connections 参数。对于极大规模场景，可以在 Core 和 MySQL 之间引入 ProxySQL 或 PgBouncer（PostgreSQL 场景）进行连接池管理。
第二，Redis 的持久化配置。JumpServer 使用 Redis 存储在线会话状态，如果 Redis 数据丢失（例如 Redis 宕机重启），所有正在进行的会话将会中断。生产环境建议开启 Redis 的 AOF 持久化，并配置 Redis Sentinel 或 Redis Cluster 保证高可用。
第三，对象存储的接入。单机部署时，会话录像默认存放在本地磁盘。当 Core 服务扩展到多个实例时，必须将录像存储切换为共享存储（NFS 或对象存储），否则不同 Core 实例写入的录像文件会分散在各自的本地磁盘上，导致审计回放时找不到录像文件。对象存储的配置入口在 JumpServer 管理控制台的"系统设置 → 存储设置 → 录像存储"中。
6.5 升级与数据迁移
JumpServer 的版本升级需要遵循"小步快跑"的原则，不建议跨多个大版本直接升级，应按照官方文档指定的升级路径逐步进行。
使用 jmsctl 脚本部署的环境，升级流程如下：
# 停止当前服务
./jmsctl.sh stop
# 备份数据库（务必在升级前执行）
./jmsctl.sh backup_db
# 下载新版本的 installer
wget https://github.com/jumpserver/jumpserver/releases/download/v4.10.0/jumpserver-installer-v4.10.0.tar.gz
tar -xf jumpserver-installer-v4.10.0.tar.gz
# 使用新版本的 jmsctl 执行升级
cd jumpserver-installer-v4.10.0
./jmsctl.sh upgrade
# 启动新版本服务
./jmsctl.sh start
# 验证服务状态
./jmsctl.sh status升级过程中，jmsctl 脚本会自动处理数据库 Schema 变更（即数据库迁移），将现有数据结构升级到新版本所需的格式。如果升级过程中出现异常，可以通过之前备份的数据库快照回滚到升级前的状态。
需要特别注意的是，SECRET_KEY 在升级前后必须保持一致，否则数据库中加密存储的账号凭据将无法解密，导致所有资产账号失效。如果曾经修改过 SECRET_KEY，升级时务必检查新版本配置文件中的 SECRET_KEY 是否与旧版本一致。
七、操作指南：JumpServer 的日常使用
7.1 初始化配置
首次登录后，建议按以下顺序完成基础配置：
第一步：修改管理员密码。 进入"用户列表"，找到 admin 账号，修改为强密码，并开启 MFA 认证。
第二步：配置邮件通知。 进入"系统设置 → 消息通知 → 邮件配置"，填写 SMTP 服务器信息，开启邮件通知，以便在有告警事件时及时收到通知。
第三步：配置 LDAP/AD 集成（如有企业目录服务）。 进入"系统设置 → 认证配置 → LDAP"，填写域控服务器地址和绑定账号，开启 LDAP 认证后，企业员工可以直接使用域账号登录 JumpServer，无需在堡垒机中单独创建账号，也便于员工离职时统一注销访问权限。
第四步：全局安全策略配置。 在"系统设置 → 安全配置"中，可以设置登录失败次数限制、会话超时时间、IP 白名单等全局安全参数，建议根据企业实际情况进行调整。
7.2 添加资产
以添加一台 Linux 服务器为例，操作流程如下：
进入"资产管理 → 资产列表"，点击"创建资产"按钮，填写以下信息：
资产类型：Linux
资产名称：prod-web-01（建议使用有意义的命名，便于检索）
IP/主机名：10.0.0.100
端口：22
所属节点：/Default/生产环境/Web服务器（节点路径，用于组织资产树）
平台：Linux（选择对应的操作系统类型）资产创建后，还需要为其绑定账号（即登录资产所使用的系统用户）。进入"资产详情 → 账号"，添加账号：
用户名：root（或其他有权限的系统账号）
密码/密钥：填写实际的登录凭据
是否特权用户：是（root 账号通常需要勾选）配置完成后，可以点击"测试连通性"按钮验证 JumpServer 是否能成功连接到该资产。
7.3 用户管理与授权
创建用户并完成授权是让运维人员能够登录目标资产的必要步骤。
进入"用户管理 → 用户列表"，创建新用户，填写姓名、邮箱、所属用户组等信息。创建后，系统会向用户邮箱发送包含初始密码的邮件。
用户创建完成后，需要为其配置授权规则。进入"资产权限 → 授权管理"，点击"创建授权"，按如下逻辑填写：
授权名称：运维组-Web服务器-访问
用户/用户组：选择需要授权的用户或用户组
资产/节点：选择 /Default/生产环境/Web服务器 节点
账号：选择 root 账号（或配置"同名账号"让用户使用与自身用户名相同的账号登录）
Action：SSH 连接（可细化控制是否允许文件上传/下载、剪切板操作等）
有效时间：可设置临时授权的有效期授权生效后，该用户在登录 JumpServer 的 Web Terminal 时，会看到被授权的资产节点，点击即可连接，全程无需知道目标服务器的实际账号密码。
7.4 命令过滤配置
进入"系统设置 → 安全配置 → 命令过滤"，可以创建命令过滤器。一个完整的命令过滤器包含若干条过滤规则，每条规则指定一个正则表达式，以及匹配时的动作（拒绝/警告/通知）。
命令过滤器创建后，需要在"资产权限 → 授权管理"中为特定的授权规则绑定过滤器，才会对相应用户的操作生效。
一个适用于大多数生产环境的基础命令过滤器，通常会包含以下规则：
# 禁止删除根目录或系统目录
^rm\s+(-[a-zA-Z]*\s+)*\/(\s|$)
^rm\s+(-[a-zA-Z]*\s+)*/etc
^rm\s+(-[a-zA-Z]*\s+)*/boot
^rm\s+(-[a-zA-Z]*\s+)*/usr
# 禁止系统重启/关机
^(shutdown|reboot|halt|poweroff|init\s+[06])(\s|$)
# 禁止格式化磁盘
^mkfs
^dd\s+if=
# 禁止修改关键系统文件
^(vi|vim|nano)\s+/etc/passwd
^(vi|vim|nano)\s+/etc/shadow
^(vi|vim|nano)\s+/etc/sudoers7.5 查看审计日志与回放录像
进入"审计 → 会话审计 → 历史会话"，可以查看所有历史会话的列表，支持按用户、资产、时间范围等多个维度进行过滤检索。
点击某条会话记录右侧的"回放"按钮，即可在浏览器中直接播放该会话的终端录像，完整重现当时的每一步操作。时间轴可以拖拽跳转，也可以倍速播放，大幅提升审计效率。
进入"审计 → 命令记录"，可以搜索特定命令在所有会话中的执行记录，例如搜索 rm 命令，可以快速定位所有曾经执行过删除操作的会话和用户。
八、PAM 特权账号管理：JumpServer 的重要进化
8.1 为什么需要 PAM
在传统的企业安全体系中，堡垒机和 PAM 是两个独立的产品，分别由不同的团队维护，数据相互割裂。堡垒机管的是"谁能登录到哪台机器"，PAM 管的是"机器上有哪些特权账号，这些账号的密码是什么、何时轮换"。
由于两套系统各自维护一套用户体系和资产清单，运维人员往往需要在两个管理控制台之间来回切换，管理成本较高。更严重的问题是，两套系统的权限策略无法联动，容易产生管理盲区——例如，一个账号在堡垒机中已被注销了访问权限，但在 PAM 中的特权账号凭据可能仍然有效，攻击者一旦获取到这些凭据，就能绕过堡垒机的访问控制直接登录目标系统。
JumpServer v4.10 LTS 版本的核心突破，正是将堡垒机与 PAM 功能无缝整合，在同一套系统内实现"访问控制 + 特权管理"的一体化解决方案。
8.2 JumpServer PAM 的六大核心能力
账号发现
PAM 的第一步，是要知道企业的 IT 环境中究竟存在哪些特权账号。JumpServer 的账号发现功能支持定时或周期性地对纳管资产进行深度扫描，自动采集服务器、网络设备、数据库上的所有账号信息，包括那些可能被遗忘或不在正式授权范围内的"僵尸账号"。
账号推送
在新资产上线或需要批量创建账号时，账号推送功能可以将统一配置的账号和密码一键下发至多台目标资产，无需管理员逐台登录手动创建。同时，密码生成策略支持自定义复杂度要求（长度、字符组合等），确保所有新创建的账号密码都符合企业安全规范。
账号备份
账号密码是企业的核心资产，一旦丢
