JumpServer 开源 PAM 平台深度指南：架构、组件与快速部署实战-育师

JumpServer 开源 PAM 平台深度指南：架构、组件与快速部署实战

【免费下载链接】jumpserverJumpServer is an open-source Privileged Access Management (PAM) platform that provides DevOps and IT teams with on-demand and secure access to SSH, RDP, Kubernetes, Database and RemoteApp endpoints through a web browser.项目地址: https://gitcode.com/GitHub_Trending/ju/jumpserver

本指南以仓库 readmes/README.es.md（西班牙语版项目介绍）为主线，结合当前仓库源码，系统讲解 JumpServer 作为开源特权访问管理（PAM）平台的核心定位、组件架构与快速部署流程，并深入到 jms 启动脚本、config_example.yml 配置体系与 apps/terminal/connect_methods.py 协议支持矩阵等源码细节。读完本文，你将掌握 JumpServer 的整体架构分层、各连接器组件的职责边界，以及从零快速拉起一套可用的堡垒机环境的方法。

一、JumpServer 是什么：面向 DevOps 与 IT 团队的开源 PAM 平台

JumpServer 是一个开源的PAM（Privileged Access Management，特权访问管理）平台，即通常所说的"堡垒机"。它通过 Web 浏览器为 DevOps 和 IT 团队提供对 SSH、RDP、Kubernetes、数据库以及 RemoteApp 远程应用等终端的按需、安全访问能力。

这一核心定位意味着 JumpServer 解决的是运维安全中最关键的一类问题：特权账号集中管控。所有运维人员不再直接接触目标服务器的真实地址与凭据，而是统一经由 JumpServer 进行身份认证、权限校验、会话接入与全程审计，实现"先登录、再授权、后访问、全留痕"的安全闭环。

从仓库目录结构可以直观看到支撑这一定位的业务模块布局（apps/jumpserver/settings/base.py 中的INSTALLED_APPS）：

业务模块	职责
`orgs`	多组织架构，支撑租户隔离
`users`	用户、用户组管理
`assets`	资产（主机、数据库、云资产等）与节点管理
`accounts`	账号（特权账号）与改密、收集等自动化
`perms`	资产授权与权限策略
`terminal`	终端会话与连接方式管理
`audits`	登录日志、操作审计
`acls`	命令过滤、登录控制等访问控制规则
`tickets`	工单审批流
`rbac`	基于角色的访问控制
`authentication`	本地/LDAP/SSO/OIDC/CAS 等多源认证

这些模块共同构成了一个功能完整的特权访问管理平台，而非单纯一个"SSH 跳板机"。

二、快速启动：一条命令拉起 JumpServer

官方 README 提供了面向生产环境的一键部署方式。前提是准备一台干净的 Linux 服务器，要求：

64 位操作系统
硬件规格不低于4 核 CPU / 8 GB 内存（4c8g）

在满足条件的服务器上执行：

curl -sSL https://github.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash

安装完成后，在浏览器中访问：

http://你的-jumpserver-IP/

初始登录凭据为：

用户名：admin
密码：ChangeMe

安全提示：首次登录后应立即修改admin密码，并为生产环境生成独立的随机SECRET_KEY（下文配置章节会详细说明）。

从源码视角看启动链路

如果你希望在本地以源码方式运行 JumpServer，而不是使用一键脚本，仓库提供了完整的启动链路。核心入口是根目录的 jms 脚本，它是一个 Python 编写的服务控制工具（基于 Django 的management.call_command）：

python jms start all -d # 启动全部服务（后台守护模式） python jms start web # 仅启动 Web 服务 python jms start task # 仅启动 Celery 任务服务 python jms stop all # 停止全部服务 python jms restart all # 重启 python jms status # 查看状态 python jms upgrade_db # 升级数据库结构 python jms collect_static # 收集静态文件

从 jms 的argparse定义可见，它支持start / stop / restart / status / upgrade_db / collect_static六种动作，服务类型可选all / web / task / ai，还支持-d/--daemon守护模式、-w/--worker指定 worker 数、-f/--force强制模式。首次start all时会依次执行数据库连接检查、migrate、collectstatic、IP 地理库下载、内置 Applet 安装与 OAuth2 Provider 初始化等准备工作。

容器化部署时，Dockerfile 使用jumpserver/core-base作为构建基础镜像，通过uv pip install安装依赖，最终以 entrypoint.sh 作为入口（默认执行start all），并暴露8080（Web）与8088端口。

三、组件架构：一个平台，多个专业连接器

JumpServer 采用"核心平台 + 协议连接器"的分布式架构。根据 README 的组件表，官方将其划分为若干关键项目，共同组成 JumpServer 的功能框架：

项目	说明
Lina	JumpServer Web 用户界面（前端控制台）
Luna	JumpServer Web 终端（浏览器内字符/图形会话界面）
KoKo	字符协议连接器（SSH、Telnet 等）
Lion	图形协议连接器（RDP、VNC 等）
Chen	Web 数据库访问组件
Tinker	RemoteApp 远程应用连接器（Windows 平台）
Panda	RemoteApp 远程应用连接器（企业版，Linux 平台）
Razor	RDP 代理连接器（企业版）
Magnus	数据库代理连接器（企业版）
Nec	VNC 代理连接器（企业版）
Facelive	人脸识别组件（企业版）

连接器与协议支持矩阵（源码级验证）

仓库 apps/terminal/connect_methods.py 中ConnectMethodUtil.components()明确定义了各连接器与协议之间的对应关系，这是对组件表最直接的源码佐证：

KoKo（TerminalType.koko）：提供web_cli方式，监听 HTTP/SSH/SFTP，支持 SSH、Telnet、SFTP、Redis、MongoDB、K8s、ClickHouse、MySQL、MariaDB、SQLServer、PostgreSQL、Oracle 等协议；
Chen（TerminalType.chen）：提供web_gui方式，支持 MySQL、PostgreSQL、Oracle、SQLServer、MariaDB、DB2、达梦（dameng）等数据库的 Web 访问；
Lion（TerminalType.lion）：提供web_gui方式，支持 RDP、VNC 图形协议；
Magnus（TerminalType.magnus）：数据库代理，支持 MySQL、PostgreSQL、Oracle、MariaDB、Redis、SQLServer、MongoDB；
Razor（TerminalType.razor）：RDP 代理；
Nec（TerminalType.nec）：VNC 代理。

同时，NativeClient枚举定义了 SSH Client、SFTP Client、DB Client/Guide、Remote Desktop（mstsc）、VNC Client 等原生客户端连接方式，说明 JumpServer 不仅支持纯 Web 访问，也支持通过本地客户端软件直连目标资产（会话仍由平台代理并审计）。此外，Tinker/Panda 通过AppletMethod与VirtualAppMethod提供 RemoteApp 与虚拟应用接入能力。

这套"Web 方式 + 原生客户端 + 远程应用"三层连接方法体系，正是 JumpServer 能够覆盖 SSH、RDP、Kubernetes、数据库与 RemoteApp 五类终端的底层原因。

四、核心配置详解：从 config_example.yml 看平台可调参数

JumpServer 的配置集中在根目录 config_example.yml，实际部署时通常将其复制为config.yml使用（jms 脚本在找不到配置时会提示cp config_example.yml config.yml）。配置加载逻辑由 apps/jumpserver/conf.py 的Config类实现，其中定义了大量带默认值的配置项，并结合 apps/jumpserver/settings/base.py 注入 Django settings。以下分类说明关键配置：

1. 安全密钥（必改项）

SECRET_KEY: BOOTSTRAP_TOKEN:

SECRET_KEY：Django 加密密钥，生产环境必须改为随机字符串且勿外泄，官方建议用cat /dev/urandom | tr -dc A-Za-z0-9 | head -c 49;echo生成；
BOOTSTRAP_TOKEN：KoKo、Guacamole 等组件注册服务账号使用的预共享 Token，替代旧的注册接受机制。

2. 数据库与 Redis

DB_ENGINE: postgresql DB_HOST: 127.0.0.1 DB_PORT: 5432 DB_USER: jumpserver DB_PASSWORD: DB_NAME: jumpserver REDIS_HOST: 127.0.0.1 REDIS_PORT: 6379

数据库支持 SQLite、MySQL、PostgreSQL 等（默认示例为 PostgreSQL 5432）；默认库名jumpserver；
Redis 同时作为 Celery 消息代理（broker）与 WebSocket 通道，示例中默认库为REDIS_DB_CELERY: 3（Celery）、REDIS_DB_CACHE: 4（缓存）；支持密码、SSL 与 Redis Sentinel 高可用配置。

3. 服务监听端口

HTTP_BIND_HOST: 0.0.0.0 HTTP_LISTEN_PORT: 8080 WS_LISTEN_PORT: 8070

Web 服务默认绑定0.0.0.0:8080，WebSocket 服务监听8070。

4. Vault 凭据保险库（OpenBao 默认后端）

VAULT_ENABLED: true VAULT_BACKEND: openbao VAULT_OPENBAO_ADDR: http://openbao:8200 VAULT_OPENBAO_MOUNT_POINT: pam VAULT_OPENBAO_TOKEN: VAULT_OPENBAO_TIMEOUT: 10

开启后将敏感凭据托管至 OpenBao（HashiCorp Vault 的开源分支），另有独立的 SSH CA 配置（SSH_CA_*系列，用于基于 OpenBao 的 SSH 客户端证书签发），以及 HCP、Azure、AWS 等云厂商 Vault 后端选项。仓库 apps/accounts/backends/ 目录下的openbao/、hcp/、azure/、aws/、local/子目录即对应这些后端的具体实现。

5. 认证与身份源

AUTH_LDAP_SYNC_IS_PERIODIC: True AUTH_LDAP_SYNC_INTERVAL: 12 AUTH_LDAP_SEARCH_PAGED_SIZE: 1000 AUTH_LDAP_USER_LOGIN_ONLY_IN_USERS: False

支持 LDAP/AD 定时同步用户、分页搜索（默认 1000 条/页）；apps/jumpserver/conf.py 中还定义了 OpenID/OIDC、CAS、SAML2、OAuth2、RADIUS、Passkey、企业微信、钉钉、飞书、Lark、Slack、自定义 SSO、UKey 等一整套第三方认证配置，对应 apps/authentication/backends/ 下的cas/、oidc/、oauth2/、saml2/、radius/、passkey/、ukey/等实现目录。

6. 安全策略（会话、密码与水印）

SESSION_COOKIE_AGE: 3600 SESSION_EXPIRE_AT_BROWSER_CLOSE: false SECURITY_WATERMARK_ENABLED: False SECURITY_MFA_AUTH: 0 SECURITY_PASSWORD_MIN_LENGTH: 6 OTP_ISSUER_NAME: JumpServer

会话过期默认 1 小时，也可设置浏览器关闭即过期；
SECURITY_MFA_AUTH：0 不开启、1 全局开启、2 仅管理员开启 MFA；SECURITY_MFA_METHODS支持 OTP、短信、邮箱、人脸、Passkey 等多种方式；
Luna 界面水印默认关闭，可开启以强化防泄露；
密码复杂度（大小写、数字、特殊字符）均可单独配置。

7. Ansible 自动化任务的超时体系

config_example.yml 对大规模改密等自动化场景给出了非常详细的容量规划建议：

ANSIBLE_RUNNER_JOB_TIMEOUT: 1800 # 单批（80 资产）硬超时：30 分钟 ANSIBLE_RUNNER_IDLE_TIMEOUT: 900 # 单批无输出超时：15 分钟 ANSIBLE_AUTOMATION_TASK_TIMEOUT: 300 # 单主机单 Ansible task 超时：5 分钟 ANSIBLE_AUTOMATION_TOTAL_TIMEOUT: 54000 # 整个任务总超时：15 小时

关键设计：资产自动化按每 80 个资产分批、每批串行启动一个 ansible-runner。总超时估算公式为ceil(资产总数 / 80) × 单批 P95 耗时 × 1.3（预留 30% 余量）。例如 1 万资产、单批 P95 为 3 分钟时，建议总超时至少 32400 秒（9 小时）。这类面向超大规模改密的工程化细节，体现了 JumpServer 在自动化运维能力上的深度。

8. 人脸识别（默认关闭）

FACE_RECOGNITION_ENABLED: false FACE_RECOGNITION_DEVICE: auto # auto, cpu, gpu FACE_LIVENESS_MODE: motion # off, motion, onnx, hybrid

人脸识别默认关闭，需先通过uv run python requirements/download_face_models.py下载模型后再显式开启，并支持活体检测（motion/onnx/hybrid 模式）与 GPU 推理（对应 requirements/download_face_models.py）。

五、仓库布局与二次开发指引

Django 应用组织

JumpServer 后端是一个标准的 Django 多应用工程，所有业务代码位于 apps/ 目录：

每个业务域（如users、assets、accounts、terminal、audits、perms）都遵循api / models / serializers / migrations / tasks / signal_handlers的标准分层；
公共能力沉淀在 apps/common/（DRF 扩展、SDK、存储、缓存、工具函数等）与 apps/libs/（Ansible 执行器等）；
平台常量与版本号定义在 apps/jumpserver/const.py（VERSION = '2.0.0'），全局路由入口为 apps/jumpserver/urls.py。

自动化与审计能力

apps/accounts/automations/ 与 apps/assets/automations/ 分别承载账号侧（改密、推送、收集、验证、删除）与资产侧（Ping、事实采集）的自动化任务，配合utils/ansible_executor/下的 playbook 模板与 apps/accounts/tasks/、apps/assets/tasks/ 中的 Celery 任务调度；
审计侧由 apps/audits/ 负责，登录日志、操作日志支持数据库与 Elasticsearch 双后端（apps/audits/backends/）。

六、许可协议与社区贡献

社区贡献方面，欢迎通过提交 Pull Request 参与开发，具体规范请参考 CONTRIBUTING.md。仓库同时提供了多语言 README 以便全球开发者阅读，包括简体中文 readmes/README.zh-hans.md、繁体中文 readmes/README.zh-hant.md、英文 README.md、日文 readmes/README.ja.md、葡萄牙语 readmes/README.pt-br.md、俄文 readmes/README.ru.md 与韩文 readmes/README.ko.md。

七、总结

JumpServer 通过"核心平台 + 多协议连接器"的架构，将 SSH、RDP、Kubernetes、数据库与 RemoteApp 五类访问场景统一收敛到一套 PAM 体系中：前端由 Lina/Luna 提供控制台与 Web 终端，接入侧由 KoKo/Lion/Chen/Magnus/Razor/Nec/Tinker/Panda 分别承载字符、图形、数据库与远程应用协议，后端则由 config_example.yml 驱动的配置体系支撑认证、Vault 凭据托管、自动化改密与全面审计。无论是通过quick_start.sh一键部署，还是基于 jms 脚本做源码级定制，这套架构都能为 DevOps 与 IT 团队提供可审计、可管控、可自动化的特权访问基础设施。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

JumpServer 开源 PAM 平台深度指南：架构、组件与快速部署实战