为什么密码加跳板机已经不够用了
多数运维团队还在使用密码登录服务器，即使加了跳板机，也只是把多台机器的密码收集到一个入口，攻击者一旦拿下跳板机就能横向移动。密码本身存在泄露、暴力破解、共享账号无法追溯等问题。更致命的是，跳板机日志只能记录谁什么时候连过，却不知道他在机器上执行了什么命令——事后审计形同虚设。
真正的运维安全需要做到三点：免密认证、强制跳板、全程录像。SSH Key + 堡垒机（Bastion Host）正是针对这三个目标设计的主流通用方案。下面直接拆解这个体系的组成与实施要点。
体系核心组件：SSH Key 与堡垒机
SSH Key 认证如何消除密码隐患
SSH Key 采用非对称加密，客户端持有私钥，服务器存储公钥。相比密码，Key 无法被在线暴力破解（除非私钥文件本身被窃），而且可以针对不同用户、不同机器独立签发。配合 authorized_keys 文件中的 command= 约束或 ForceCommand，还能强制每次登录后执行特定脚本（如记录环境变量、锁定Shell）。
但单靠 Key 管理如果依赖手动分发，很快就会失控——密钥数量膨胀、遗忘吊销、员工离职后私钥未回收，都是实际见过的事故。所以必须用堡垒机作为Key的统一签发和访问控制点。
堡垒机的三层架构
一个生产级堡垒机不是简单的“跳板机+日志”就能胜任的。我们把它拆成三层：
- 接入层：用户通过Web Portal或原生SSH客户端连接堡垒机，不需要知道目标机器IP。堡垒机对外暴露唯一入口，内部网络完全隔离。
- 控制层：负责认证（LDAP/AD/OTP）、权限校验（用户-资产-命令集）、会话授权与录像。
- 代理层：内核实现SSH协议代理，将用户操作转发给目标机器，同时旁路抓取所有输入输出流，形成录像文件。
这里的关键差异在于：堡垒机自身不能持有目标机器的SSH Key直连权限，而是由管理员在堡垒机的资产模块中配置“托管Key”或通过密钥托管系统定期轮换。用户通过堡垒机访问资产时，堡垒机用自己的Key代理登录，用户始终不知道目标机器的任何密码或私钥。
审计体系的具体组成
全量操作录像与回放
不是只记录谁登录了，而是每一组输入、每一次回显、甚至终端窗口大小变化都被记录为可回放的时间流。常规的 script/ttyrec 录像容易因为网络中断而丢失尾部，堡垒机采用会话内缓存+异步上传机制，即使代理进程崩溃，已记录的I/O也不会丢。
回放时支持倍速、暂停、搜索关键字（如 rm -rf、chmod 777）。配合敏感命令告警，运维人员只要敲了高危指令，审计系统立即在管理后台弹窗并通知负责人。
命令白名单与审批流
不可能对所有操作都放行再事后追责。更有效的做法是：
- 定义继承自用户组的命令白名单（如
top,tail,grep允许；passwd,useradd禁止）。 - 匹配白名单之外的命令自动触发临时授权审批，审批通过后堡垒机动态打开一个短暂可用的命令池，3分钟后自动关闭。
- 白名单本身由安全团队管理，定期审计其合理性。
这一套完全基于操作层面的会话颗粒度，不依赖操作系统内部的sudo日志，因此即使客户端通过 scp -t 或 rsync 绕过shell也一样被拦截（堡垒机代理层能识别协议类型）。
密钥轮转与回收
SSH Key 体系里最容易被忽略的是密钥失效机制。堡垒机内置定时任务：
- 每隔N天自动登录目标机器，替换
~/.ssh/authorized_keys中的公钥。 - 新密钥由堡垒机内部的HSM或密钥管理服务生成，旧密钥立即标记为不可用并写入回收日志。
- 管理员手动吊销某个用户的全部密钥时，堡垒机同时更新所有已托管资产的
authorized_keys，避免某个离职员工的私钥仍能登录。
这个过程必须支持回滚：如果轮转后发现目标机器失联（比如网络分区、密钥错误），堡垒机能自动使用上一次的备份公钥恢复连接，并通过邮件告警。
落地实施的最佳步骤
环境适配：非标准SSH端口和跳板嵌套
很多企业内网资产不是标准22端口，或者前面已有另一层网络跳板。堡垒机需要支持资产代理链配置：用户 -> 堡垒机 -> 外部跳板 -> 目标机器。代理链上每一跳都必须记录I/O，否则录像会出现断层。
端口映射不应该写死在堡垒机配置里，而是通过资产管理模块动态注册，并定期做连通性探测，探活失败时从负载池中摘除。
密钥分发不落地
用户私钥应该只存储在本地物理 YubiKey 或 TPM 芯片中，堡垒机不保存用户私钥。用户的公钥可以通过 Web 界面手动上传，或者由堡垒机在用户首次登录时自动生成并加密存储。
私钥永不经由网络传输到堡垒机，任何需要私钥的操作（如本地终端连接）都由客户端自己的SSH agent完成。堡垒机只做公钥认证转发+流代理。这样即使堡垒机被攻破，攻击者也拿不到用户的私钥。
验证审计链条的完整性
部署后必须做以下验证：
- 通过堡垒机执行
echo $SSH_CONNECTION，观察显示的源IP是否为堡垒机内网IP（而不是用户客户端IP），表明流量被正确代理。 - 手动断开会话（比如拔掉客户端网线），等待30秒后重新查看录像，确认录像没有丢失最后几秒的操作。
- 尝试修改本地时间并再次通过堡垒机登录，确认录像时间戳统一使用堡垒机的NTP时间而非客户端时间。
- 使用另一个低权限用户试图绕过堡垒机直接访问目标服务器，确认已被防火墙或安全组拦截。
常见风险与应对策略
会话重放攻击
录像文件是明文的SSH流，如果存储被窃，攻击者可以从中提取密码或敏感数据。应对措施：录像存储必须加密（AES-256-GCM），密钥由堡垒机的主密钥派生，并定期轮换主密钥。回放时只在沙箱浏览器中解密播放，不允许下载原文件。
堡垒机自身成为单点
堡垒机故障可能导致所有运维通道瘫痪。生产环境必须部署主备集群（Active-Passive或Active-Active），共享后端数据库和录像存储。当主节点失联时，备用节点自动接管所有会话，且已建立的SSH连接不会中断（需要代理支持TCP keepalive重连）。
Key托管暴露面
堡垒机持有的目标机器公钥/私钥一旦泄露，所有资产都会失陷。最小化原则：堡垒机只保存用于自动化任务的服务账户Key，个人用户的Key由堡垒机代理动态生成并立即销毁。且必须对Key存储目录实行文件系统级加密+最小权限（仅堡垒机进程可读）。
回滚与应急恢复
任何运维变更都要有回退预案。针对密钥轮转、配置更新、堡垒机版本升级，建议：
- 保留至少3轮轮转前的公钥备份在加密存储区，通过单独的管理通道（如带外串口）可手动恢复。
- 堡垒机配置采用Git仓库管理，每次发布前自动执行
terraform plan或等价校验，失败则回滚到上一commit。 - 万一堡垒机完全不可用时，运维团队应保留一条备用SSH通道（如通过VPN连接管理网段），但该通道必须启用双因子认证并记录所有登录流水。
SSH Key本质是一个信任传递工具，堡垒机则是信任的裁判员。两者结合才能真正做到认证不落地、操作全留痕、权限可回收。这套体系不是银弹，但在当前工程实践中，它是投入产出比最高的运维安全基线方案。
延伸阅读