解构堡垒机：从内核、协议到分布式架构的运维审计系统设计

作者： /

本文面向中高级工程师，旨在深度剖析堡垒机（Bastion Host）这一关键基础设施的内部工作原理。我们将超越“什么是堡垒机”的表层概念，深入探讨其在操作系统内核层面（特别是 TTY/PTY 子系统）、网络协议层面（SSH 协议细节）的核心实现，并结合一线工程经验，分析其从单体到分布式高可用架构的演进路径。本文的目标不是一份操作手册，而是一次对运维安全、系统编程与分布式架构设计的综合性技术拆解，适用于需要构建或评估运维审计系统的技术负责人。

现象与问题背景

在任何一家稍具规模的公司，服务器资产的管理都是一个棘手的问题。最初，可能是通过 Excel 表格管理人、密码和服务器的对应关系，运维人员通过本地 SSH 客户端直接连接线上服务器。这种“原始”模式带来了几个致命的问题：

  • 身份认证混乱：普遍使用共享账号（如 root），或者多个运维共享一个普通用户的 key。一旦出现安全事件，无法追溯到具体责任人。

    • – 权限控制失控：权限控制完全依赖于服务器本地的 `sudoers` 或文件权限配置，管理复杂且极易出错。一个“临时”赋予的高权限，往往会成为永久性的安全后门。

    – 操作审计缺失：谁，在什么时间，对哪台服务器，执行了什么命令，结果如何？这些问题完全是黑盒。当出现线上故障或数据泄露时，复盘和追责变得几乎不可能。

    – 安全凭证泄露：SSH 密钥、服务器密码等敏感信息散落在各个工程师的本地电脑上，一旦某台设备失陷，整个内网都可能面临风险。

为了解决上述问题，堡垒机应运而生。它的核心思想是“集中管控”。所有对内网服务器的访问请求，都必须首先通过一个统一的入口——堡垒机。堡垒机作为运维流量的必经网关，从而获得了实施 AAA 安全模型 的能力：

  • Authentication (认证)：强制所有用户通过统一认证方式登录堡垒机（如 LDAP, OAuth2, MFA）。
  • Authorization (授权)：在堡垒机上集中配置用户、用户组对服务器资产的访问权限。
  • Auditing (审计)：记录并审计所有经由堡垒机的操作会话，包括命令、文件传输等。

堡垒机将原本分散、混乱的运维访问模型，收敛成一个标准化的、可审计的“代理”模型，从根本上解决了运维安全的核心痛点。

关键原理拆解

作为一名架构师，我们不能满足于知道堡垒机“能做什么”，而必须理解它“如何做到”。这需要我们深入到操作系统和网络协议的底层。堡垒机的核心功能——会话代理与操作审计，其技术基石是 Linux 的 TTY/PTY 子系统和对 SSH 协议的深度利用。

大学教授视角：Linux TTY/PTY 伪终端子系统

要理解命令如何被记录，首先要理解在 Linux 系统中，用户与 Shell 之间是如何交互的。这背后的功臣是终端（Terminal）。物理终端（TTY）早已被淘汰，我们现在使用的是在图形界面中模拟出来的终端模拟器（如 Gnome Terminal, iTerm2），它们通过伪终端（Pseudo Terminal, PTY）与系统交互。

PTY 机制是理解堡垒机录屏和命令抓取原理的核心。一个 PTY 设备对由两部分组成：

  • PTY Master (主设备)：例如 /dev/ptmx。它由终端模拟器这样的应用程序持有和控制。应用程序写入 PTY Master 的数据，会成为 PTY Slave 的输入；从 PTY Master 读出的数据，则来自 PTY Slave 的输出。
  • PTY Slave (从设备)：例如 /dev/pts/0。它表现得像一个真正的物理终端设备。Shell 进程（如 bash）的标准输入、标准输出、标准错误都连接到这个从设备上。

当用户在终端模拟器里敲下键盘时，数据流是这样的：键盘 -> 终端模拟器 -> PTY Master -> (内核处理) -> PTY Slave -> Shell 进程。Shell 执行命令后的输出流则反向：Shell 进程 -> PTY Slave -> (内核处理) -> PTY Master -> 终端模拟器 -> 屏幕。

堡垒机正是将自己巧妙地插入到了这个数据流的中间。 当一个用户通过 SSH 连接到堡垒机，并希望再跳到目标服务器时，堡垒机扮演了“终端模拟器”的角色。它会创建一个 PTY 设备对：

  1. 堡垒机持有 PTY Master 端。
  2. 堡垒机在 PTY Slave 端启动一个真正的 SSH 客户端进程，去连接目标服务器。
  3. 用户的 SSH 连接输入，被堡垒机接收后，写入 PTY Master。
  4. 目标服务器通过 SSH 返回的输出，最终从 PTY Master 被堡垒机读出，再转发给用户。

在这个过程中，堡垒机作为中间人，看到了所有进出 PTY Master 的字节流。这个完整的双向字节流，就是最原始的操作会话记录。通过解析这个字节流，就可以实现命令审计和会话录屏回放。

极客工程师视角：SSH 协议的“滥用”

单纯理解 PTY 还不够，堡垒机还需要深度理解和利用 SSH 协议。当用户 ssh bastion_user@bastion_host 时，堡垒机上的 SSH 服务（SSHD）会为这个连接创建一个会话。堡垒机的核心程序会接管这个会话，而不是简单地给用户一个堡垒机上的 Shell。

SSH 协议中有不同的“通道（Channel）”类型，最常见的是 session 通道。在一个 session 通道中，客户端可以请求执行一个命令（exec 请求），或者请求一个交互式的 Shell（shell 请求）。

当堡垒机程序接管会话后，它会根据用户的意图（比如 Jumpserver 会提供一个资产列表让用户选择），发起一个到目标服务器的 SSH 连接。这个连接所使用的凭证（密钥或密码）是从堡垒机的数据库中获取的，完全对最终用户透明。这就是凭证托管的核心。

整个流程就像一个“协议代理”：User SSH Client <--> Bastion SSHD & Proxy Logic <--> Target SSHD。堡垒机在中间对 SSH 流量进行解包、审计、再打包转发。对于RDP、VNC等图形化协议，原理类似，只是代理和审计的对象从字符流变成了图形绘制指令流或像素流，实现上更为复杂，通常会借助 Guacamole 这样的开源网关。

系统架构总览

一个生产级的堡垒机系统，绝不是一台简单的 SSH 跳板机。它是一个复杂的分布式系统。我们以主流开源堡垒机 Jumpserver 的架构为蓝本进行文字描述：

逻辑分层架构图描述：

  • 接入与展现层 (Access & Presentation):
    • Web UI (Nginx + Jumpserver Web): 用户通过浏览器进行资产管理、授权申请、审计日志查看、会话录屏回放等操作。通常是前后端分离架构，前端使用 Vue/React，后端是 Django/Flask 等。
    • SSH/RDP 接入网关 (Koko / Guacamole): 这是运维人员实际连接的入口。Koko 是 Jumpserver 自研的 SSH/Telnet 网关，Guacamole 则是一个通用的远程桌面网关，支持 RDP/VNC 等协议。
  • 核心业务逻辑层 (Core Logic):
    • Core API (Jumpserver Core): 核心的业务逻辑，提供 RESTful API 供 Web UI 和其他组件调用。负责用户管理、资产管理、权限模型、认证授权等所有核心功能。
  • 任务与消息处理层 (Task & Messaging):
    • 任务队列 (Celery + Redis/RabbitMQ): 用于处理异步任务，例如：批量执行命令、推送资产硬件信息、发送通知邮件等。这避免了同步操作阻塞核心 API。
  • 数据与存储层 (Data & Storage):
    • 关系型数据库 (MySQL/PostgreSQL): 存储所有元数据，包括用户、资产、权限、审计日志（元信息）等。
    • 缓存 (Redis): 缓存常用数据、维护 Session、作为 Celery 的 Broker。
    • 录像存储 (对象存储/NFS): 存储大量的会话录像文件。使用 S3、MinIO 或 Ceph 等对象存储是最佳实践，因为录像文件数量多、体积大，且需要高可用。

这个架构体现了典型的微服务思想，将不同职责的组件解耦。例如，接入网关 Koko 是无状态的，可以水平扩展；核心 Core API 也可以部署多个实例。这种架构为后续的高可用和性能扩展打下了坚实的基础。

核心模块设计与实现

我们来深入到几个最关键模块的实现细节，用“极客工程师”的语言和代码来剖析。

SSH 网关与会话拦截

SSH 网关是堡垒机的灵魂。我们用 Go 语言来展示一个最简化的 PTY 拦截代理的核心逻辑。Go 的并发模型和强大的网络库非常适合做这类中间件。


// 伪代码，展示核心思想
package main

import (
    "golang.org/x/crypto/ssh"
    "github.com/creack/pty"
    "io"
    "os/exec"
    "log"
)

// handleUserSSHChannel 函数处理一个来自用户的SSH连接请求
func handleUserSSHChannel(channel ssh.Channel) {
    // 1. 为这个会话创建一个PTY设备对
    // ptm是master端，由我们的堡垒机程序控制
    // tty是slave端，将作为新进程的“终端”
    ptm, tty, err := pty.Open()
    if err != nil {
        log.Printf("Failed to create pty: %v", err)
        return
    }
    defer tty.Close()
    defer ptm.Close()

    // 2. 在PTY slave端启动一个真正的SSH客户端，连接到目标服务器
    // 这里的凭证应该从数据库动态获取
    targetUser := "root"
    targetHost := "10.0.1.100"
    targetPort := "22"
    cmd := exec.Command("ssh", targetUser+"@"+targetHost, "-p", targetPort)
    cmd.Stdin = tty
    cmd.Stdout = tty
    cmd.Stderr = tty
    
    if err := cmd.Start(); err != nil {
        log.Printf("Failed to start ssh client to target: %v", err)
        return
    }

    // 3. 核心：数据双向拷贝与拦截
    // 将用户SSH连接的输入，同时写入PTY Master和我们的审计日志
    go func() {
        // TeeReader会把从channel读到的数据，再写一份到auditLogWriter
        // auditLogWriter可以是文件、Kafka、或任何实现了io.Writer的组件
        teeReader := io.TeeReader(channel, auditLogWriter)
        io.Copy(ptm, teeReader)
    }()

    // 将PTY Master的输出（来自目标服务器），同时写回给用户的SSH连接和审计日志
    go func() {
        teeWriter := io.MultiWriter(channel, auditLogWriter)
        io.Copy(teeWriter, ptm)
    }()

    cmd.Wait()
}

代码中的坑点和细节：

  • `io.TeeReader` 和 `io.MultiWriter` 是这里的精髓。它们实现了流量的“分叉”，一份流向目的地，另一份流向审计模块，优雅且高效。
  • PTY 窗口大小同步：上面的代码是简化的。在真实场景中，用户的终端窗口大小可能会变化，这个变化需要通过 SSH 的 pty-req 和 window-change-req 请求来捕获，并使用 `ioctl` 系统调用设置到 PTY Master 上，否则 `vim`、`top` 这类应用会显示错乱。
  • 命令解析的脏活累活：从 `auditLogWriter` 拿到的字节流是混杂了大量控制字符（如退格、方向键、`^C`）的原始数据。要从中准确解析出用户最终执行的命令，需要一个相当复杂的状态机。简单地用回车分割是极其不可靠的。很多开源堡垒机在这块儿都有专门的解析库。

会话录屏与回放

录屏的实现相对直接，就是将上文 `auditLogWriter` 捕获的完整双向字节流，连同时间戳信息，一起存储下来。`asciinema` 是一个流行的开源工具，它定义了一种很好的录屏文件格式（JSON Lines），记录了每个数据块的时间偏移和内容，非常适合作为堡垒机的录屏存储格式。

回放时，Web 前端会读取这个录屏文件，并使用像 `xterm.js` 这样的前端终端模拟器库，按照时间戳，定时将数据“喂”给模拟器，从而在浏览器上完美重现当时的操作场景。

对于 RDP 等图形化会话，由于不存在字符流，录制就变成了视频录制。Guacamole 网关会将 RDP 的绘图指令转换成自己的协议，堡垒机可以在这一层进行录制，或者干脆在 Guacamole 服务端进行屏幕截图，并用 `ffmpeg` 编码成视频文件。这种方式资源消耗巨大，是图形化审计的一个主要成本。

性能优化与高可用设计

当堡垒机承载了公司所有运维流量后，其自身的性能和可用性就成了生命线。

对抗层：架构的 Trade-off

  • 单点瓶颈 vs. 分布式扩展：

    单个 SSH 网关（如 Koko）既是性能瓶颈，也是单点故障源。当并发会话数超过千级，单机 CPU 和网络IO都会成为瓶颈。解决方案是部署多个无状态的网关实例，前端使用 L4 负载均衡（如 LVS/HAProxy）分发 TCP 连接。这里的坑是：SSH 是长连接，简单的轮询分发会导致同一个用户的不同会话落在不同网关上，管理不便。更好的方式是基于源 IP 的哈希策略，保证同一用户的连接尽可能落在同一个网关，但这又会在某些场景下导致负载不均。最完善的方案是引入一个集中的会话注册中心（如 Redis），网关在处理连接时上报会话信息，实现真正的无状态化，但架构复杂度会增加。

  • 实时阻断 vs. 事后审计:

    在命令审计时，我们面临一个抉择：是实时解析命令，发现高危操作（如 `rm -rf /`）后立刻阻断，还是仅仅记录日志，用于事后审计？

    • 实时阻断：安全性最高，能防患于未然。但挑战巨大：首先，命令解析必须极快，否则会严重影响用户的交互体验，感觉“卡顿”；其次，阻断规则的定义非常复杂，容易误判（比如 `echo “rm -rf /” > a.sh` 这种命令是否该阻断？）。这要求堡垒机具备一个高性能、高准确率的命令解析引擎。
    • 事后审计：实现简单，对性能影响小。但无法阻止破坏性操作的发生，只能作为追溯依据。

    大多数商业堡垒机都提供这两种模式的组合，对特别危险的命令（如 `reboot`, `passwd`）进行实时阻断，对大部分命令进行事后审计，这是一个务实的平衡。

高可用设计

  • 网关层高可用: 如上所述，通过部署多个无状态网关节点，并使用负载均衡实现。健康检查是关键，需要对网关的 SSH/RDP 服务端口进行 TCP 存活性探测。

    • – 核心服务高可用: Core API 和 Web UI 都是无状态的，可以部署多个实例，通过 Nginx 等 L7 负载均衡实现高可用和负载均衡。

    – 数据层高可用: 这是最关键也是最复杂的部分。MySQL 需要主从复制或 MGR/Galera Cluster 方案。Redis 需要 Sentinel 或 Cluster 模式。录像文件存储必须使用高可用的对象存储或分布式文件系统，绝不能存在本地磁盘。

架构演进与落地路径

一个堡垒机系统的构建不是一蹴而就的，应该分阶段演进。

  1. 阶段一：MVP – 统一入口与核心审计 (1-3 个月)

    此阶段目标是解决最痛的“有无”问题。可以基于开源方案（如 Jumpserver、Teleport）快速搭建一个单体实例。核心功能是实现 SSH 协议的统一认证和会话录屏。先将最核心、最敏感的服务器资产纳管进来，让团队养成通过堡垒机登录的习惯。

  2. 阶段二：生产可用 – 完善权限与多协议支持 (3-6 个月)

    在 MVP 基础上，将系统拆分为 Web/Core/Gateway 等独立组件。引入 RBAC（基于角色的访问控制）权限模型，实现精细化授权。增加对 Windows RDP、数据库（MySQL/PostgreSQL 协议代理）等协议的支持。将数据层进行高可用改造，例如 MySQL 主从分离。此时，系统已经可以满足大部分中型企业的生产要求。

  3. 阶段三：企业级增强 – 高可用与智能化 (6-12 个月)

    全面实现所有组件的高可用部署，特别是网关的水平扩展。引入实时命令阻断功能。与公司的 CMDB、SIEM（安全信息与事件管理）平台、告警系统进行深度集成。例如，将审计日志实时推送到 SIEM 进行关联分析，发现异常行为时自动告警或触发工作流。这个阶段的堡垒机，已经从一个单纯的运维工具，演变成了企业安全态势感知的关键数据源。

  4. 阶段四：云原生与零信任演进 (未来)

    随着业务全面容器化和云原生化，堡垒机的形态也在演进。它需要能审计 `kubectl exec` 这样的操作，与 Kubernetes 的认证体系（如 OIDC）集成。更进一步，堡垒机将融入零信任网络访问（ZTNA）架构，作为策略执行点（PEP），基于用户身份、设备状态、访问上下文等多维度信息，对每一次访问请求进行动态授权。这标志着堡垒机从一个静态的“跳板机”，进化为动态、智能的安全服务网关。

总而言之，堡垒机看似是一个简单的“跳板”，但其背后是操作系统、网络协议、分布式系统设计等计算机科学核心知识的综合应用。理解其深层原理，不仅能帮助我们更好地构建和使用它，更能深化我们对整个后台技术体系的认知。

延伸阅读与相关资源

  • 想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
    交易系统整体解决方案。
  • 如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
    产品与服务
    中关于交易系统搭建与定制开发的介绍。
  • 需要针对现有架构做评估、重构或从零规划，可以通过
    联系我们
    和架构顾问沟通细节，获取定制化的技术方案建议。
滚动至顶部