开源堡垒机Next-Terminal：Web化运维审计与协作平台搭建指南

1. 项目概述：从“查密码半小时”到“一条命令进生产”

先交代一下背景。我手底下管着两百多台服务器，分布在好几个机房和云厂商，既有 CentOS 7 这种老古董，也有 RockyLinux、Ubuntu 22.04 这些新系统。之前很长一段时间，团队干活的方式就是典型的“运维混乱”：每个人手里一堆 IP、一堆账号密码，有人用 Xshell 有人用 SecureCRT 有人用 Termius，还有人干脆在浏览器里开个在线终端。结果就是——新同事入职第一周全在问“生产环境的 root 密码多少”“那台 Redis 的 IP 是多少”“上次谁改完没退出 root 会话”。登录审计基本靠自觉，出了问题只能靠“猜”。

后来我花了两个周末把Next-Terminal搭起来，整体体验可以说是脱胎换骨。它是一个开源的 Web 终端管理平台，基于 SSH、VNC、RDP 协议直接把服务器、网络设备、数据库统一收口到浏览器里。不需要装客户端，不需要每台机器维护账号密码，只要浏览器能上网，就能安全地连到任意一台设备上。它解决的痛点非常直接：账号统一纳管、操作全程录像、多人协作共享会话、权限分级审批，还有资产台账自动发现。

如果你是运维工程师、SRE、网工，或者哪怕只是帮实验室管着几台 Linux 机器，这篇文章都值得看完。我会从设计方案、部署细节、日常使用到排坑实录，把我踩过的坑和总结出的最佳实践全部写出来。这套东西不只是“装一个工具”，它是把整个运维工作流从“人肉记忆”变成“系统管理”的一次思路重组。

2. 整体设计与思路拆解：为什么选择 Web 化终端管理

2.1 传统运维终端的三大痛点

先别急着谈 Next-Terminal 怎么装，得先讲清楚我为什么一定要干掉原来的 Xshell + Excel 密码表方案。

第一个痛点是凭据散落。我盘点过一次，光 root 密码就有十来个版本，有的服务器密码改了但 Excel 里没更新，有的密码表倒是在共享盘里，但权限完全失控，谁都能看到生产环境密码。更可怕的是，交换机、防火墙的 enable 密码和服务器密码记在同一张表里，一泄露就是全线崩溃。

第二个痛点是操作无审计。终端窗口一关，谁改过什么配置、执行过什么命令、是不是有人在生产环境跑过 rm -rf，完全无从追溯。以前出过一次事故：某天凌晨 3 点数据库连接数被打满，查了半天发现是有人手动执行了一个没加 where 条件的 delete。但问题是，根本没人承认，也没有任何日志能证明是谁干的。

第三个痛点是协作割裂。两个人同时排查一个问题，只能靠口头“你上我下，你操作我看看”，屏幕共享画质差还不实时。想给新人演示一段运维操作，要么录屏要么搬个小板凳坐旁边看。

Next-Terminal 的整体设计思路恰好就是冲着这三点去的：凭据集中托管在服务端，浏览器统一入口，连接过程走 WebSocket 加密，操作全程录屏录像，支持在线协作围观。它的架构本质上是一个 Web 化的“跳板机 + 堡垒机”合体，比传统 SSH 跳板机用户体验顺滑得多，又比商业堡垒机便宜得多（纯开源，零 License 费用）。

2.2 Next-Terminal 的核心架构与选型逻辑

Next-Terminal 服务端主要组件分成几位：

• 核心网关：负责处理 WebSocket 连接、认证鉴权、资产路由，所有终端数据流都走它中转
• 前端资产面板：提供资产管理、会话管理、用户权限、审计录像等操作界面
• 数据库：存资产清单、用户表、授权规则、会话元数据，支持 MySQL / SQLite 等后端
• 录像存储：为了录制操作回放，会把整个终端 I/O 流存下来，用文件或对象存储

这套架构的设计精妙之处在于：连接目标设备不需要装任何 Agent，只用标准 SSH / RDP 协议即可。这让它在入侵面控制上占了大便宜——即使被攻击，也只是堡垒机本身被攻击，不会全军覆没；而像 Puppet、SaltStack 这类“Agent 全家桶”方案，管理几百台机器首先得解决 Agent 本身的部署和版本兼容问题。Next-Terminal 完全不用碰目标系统，对生产环境侵入性几乎为零。

协议层面我重点顺序是：SSH 管 Linux / 网络设备，RDP 管 Windows 跳板机，VNC 管虚拟化控制台。它还有个非常聪明的细节：支持数据库资产类型，直接走 Web 界面连接 MySQL、PostgreSQL，不用再装 Navicat，日常查数据效率快很多。

从选型角度给一句经验之谈：如果你的环境里 Windows 机器占比超过 30%，或者必须在手机 / 平板应急登录运维，Web 化是最优解。SSH 客户端类工具（Xshell、SecureCRT）虽然手感上依然有优势，但在“统一入口 + 审计 + 协作”这个维度上，它们和 Web 终端完全不在一个世代。

2.3 同类型工具对比：我为什么没选 JumpServer、Guacamole 或 webssh

我知道很多人会问：同样的需求，为什么不用 JumpServer（堡垒机）？或者 Apache Guacamole？或者开源的 webssh 小程序？我全部实测过，这里给你我的横向结论：

我当时试过 JumpServer，功能确实完整，但光初始化就要配 MySQL、Redis、Koko、Lion 一堆服务，升级还容易出问题。对小团队来说，靠 Next-Terminal 一个容器 + 一个数据库就能跑起来，这降低的不仅是部署时间，而且是日常维护的心智负担。One more thing：Next-Terminal 带有在线聊天协作窗口，可以直接把终端会话链接发给同事，对方无需登录凭据即可“观看”或接管，这是 JumpServer 社区版没有提供的能力。

2.4 命名与定位：Next-Terminal 不是“又一代终端”而是一套工作台

“Next-Terminal”这个名字容易让人以为它只是“新一代终端模拟器”。刚开始我自己也差点被名字带偏，以为它是 xterm.js 那种终端组件。实际用下来，它给我的感觉更像一个“运维工作台”：资产、凭据、权限、会话、审计全部收口在一个界面，日常 90% 的远程运维动作都能在浏览器里点开完成。它把“终端工具”从单机软件重构为一个团队协作平台，这才是它能成为效率利器的真正原因。

3. 核心细节解析与实操要点：从部署到日常使用

3.1 Docker 部署与初始化配置：一台 2C4G 机器就能扛住全团队

部署 Next-Terminal 本身就是个 Docker 操作，推荐用 Docker Compose 一把梭。我这里给出实际跑通的配置文件组合，你们可以直接抄作业。

version: "3" services: next-terminal: image: ghcr.io/dromara/next-terminal:latest container_name: next-terminal restart: always ports: - "8088:8088" environment: - DB=sqlite - STORAGE=local - TZ=Asia/Shanghai volumes: - ./data:/usr/local/next-terminal/data - ./rec:/usr/local/next-terminal/rec

老实说，对于团队规模在 10 人以内、资产数量 500 台以下，SQLite 后端完全够用。我用 SQLite 模式跑了半年，日常并发连接 20 个左右，没有任何压力。如果团队更大、并发更多，可以把 DB 换成 MySQL，配置项改成：

- DB=mysql - DB_HOST=your-mysql-host - DB_PORT=3306 - DB_NAME=next_terminal - DB_USER=next_terminal - DB_PASSWORD=ReplaceMe

启动之后，浏览器打开http://你的服务器IP:8088，第一次访问会引导设置管理员账号。这一步我建议设置一个独立邮箱，别用管理员个人常用邮箱，后面做审计追踪时“谁操作”的归属更干净。

3.2 凭据与资产纳管：把 Excel 密码表彻底扔进回收站

这是整个系统里最让我舒爽的部分：资产与凭据分离管理。

先创建“凭据”，类型选 SSH 密码、SSH 私钥或 RDP 密码。我推荐能上密钥就上密钥，把私钥直接贴到 Next-Terminal 凭据里，服务器那端只留公钥。对于必须用密码的 Legacy 设备，密码也统一托管在这边，团队成员不再需要知道真实密码，只需要申请资产授权即可。

然后创建“资产”，填写主机名、IP、协议、端口、网关（可选的跳板机），再关联一个或多个凭据。注意它支持同一资产为不同用户分配不同凭据：比如 DBA 连数据库时用只读账号，开发同学连应用服务器用应用账号，而 root 权限只绑定给运维负责人。这种粒度比“所有人共用一个 root”安全了不止一个数量级。

接下来是用户和授权。在“用户”里把团队成员加进来，然后在“授权”里配置“谁可以访问哪些资产”。默认情况下，未授权用户是看不到这些资产条目的，等于把“资产地图”也做了隔离。这一点真的救了我：以前新员工随便找台机器猜密码就能进生产，现在没授权就连 IP 都看不到。

注意。资产 IP 的录入、凭据测试、连通性检测这三件事我是在一天内集中做完的。Next-Terminal 资产列表里提供“测试连接”按钮，刚才录入完立刻点一遍，能当场筛出不少密码过期或者端口不通的老机器，顺便就把资产台账给更新了一遍，相当于白送一次巡检。

3.3 会话连接与界面技巧：小细节提升大效率

页面右上角那个“新建连接”按钮是我的高频操作。点开之后，不需要记任何密码，选择“资产”下拉框，回车即可建立会话。由于终端模拟基于 xterm.js，复制粘贴快捷键是 Ctrl+Insert / Shift+Insert，这点和 Xshell 的 Ctrl+C / Ctrl+V 习惯不太一样，第一次用的人特别容易被坑。我去 Next-Terminal 的 Issues 区翻过，这是 xterm.js 的默认键位设计，可以在前端设置里把“粘贴”改为 Ctrl+Shift+V 映射，我改完之后舒服多了。

另一个高频需求是批量操作。它支持“批量执行命令”，选中多台 Linux 资产，一次性在各台机器上执行同一命令。这个适合统一巡检，例如同时跑df -h，或者批量执行uptime。实测 60 台机器并发执行，结果返回大概 5 秒上下。比一台台连上去跑快得不是一星半点。日常批量发 key、批量看负载、批量查日志都靠这个。

3.4 审计录像回放：事故排查的“时光机”

如果只让我挑一个“为什么离不开 Next-Terminal”的理由，我会选会话录像。后台会自动录制每一次终端会话，播放器支持倍速（1x / 2x / 4x / 8x），可以精确回看任何一次操作。有一次排查线上故障，怀疑是有人误改了 Nginx 配置，我直接搜会话记录，把那个时间段的录像拉出来，2 倍速看了 30 秒就锁定了执行nginx -s reload的操作者，并且从回放里确认了他当时的上下文。这件事要是放在以前，不知道要拉多少人开会“回忆”。

更狠的是，它支持命令搜索：在录像回放里直接搜“rm -rf”“drop table”“shutdown”这种危险词条，命中位置立刻跳转。相当于给每台生产服务器都装了个“行车记录仪”。我每个季度会主动抽几段录像做操作规范检查，抽查周期大概两小时，重点看有没有人绕过跳板机直连——说实话这让团队的操作习惯收敛了很多。

4. 实操过程与核心环节实现：从零到服务生产流量

4.1 初始化部署的完整流程：一次刷通，零返工

我自己部署时碰到过一次比较闹心的配置问题，所以把步骤整理得尽可能细致。以下流程适用于 Ubuntu 20.04/22.04 或 Debian 11/12 服务器：

1. 准备一台独立主机：我放在内网 DMZ 区，2 核 4G 内存即可。如果要长时间保存录像，建议另外挂一块 500G 以上的数据盘，单独挂到/data目录下存录像文件。
2. 安装 Docker 与 Compose 插件：官方安装脚本一把过，没什么好说的。关键是把 Docker 的>