Linux 跳板机部署需构建可管控、可追溯、可审计的运维入口，核心是先隔离访问路径、再统一身份入口、最后记录全部操作。
Linux 跳板机部署不是单纯装一台中转服务器，而是构建可管控、可追溯、可审计的运维入口。核心在于：** 先隔离访问路径，再统一身份入口，最后记录全部操作 **。JumpServer、Teleport 等开源方案已大幅降低部署门槛，关键在配置逻辑是否闭环。
一、选型与基础环境准备
跳板机本质是“人—资产”之间的强制通道，部署前需明确目标：
- 轻量快速上线：选 Teleport（单二进制部署，5 分钟可运行，支持 SSH/RDP/SFTP，自带会话录像）
- 需要完整 4A 能力 ：选 JumpServer（Python+Django 架构，支持 LDAP/ 双因子、命令 防火墙、工单审批、Ansible 集成）
- 已有容器环境：优先用 Docker Compose 部署 JumpServer 或自研堡垒服务，便于日志挂载与权限隔离
系统要求通用原则：
- 关闭 SELinux 和防火墙（或仅开放 Web 端口 + SSH 网关端口）
- 独立磁盘分区存放审计日志（建议 ≥20GB，避免日志写满导致服务中断）
- 操作系统 推荐 CentOS 7+/Ubuntu 20.04+，内核需支持 auditd（用于底层命令捕获）
二、用户与权限体系搭建
跳板机失效常因权限设计松散——不能只建一个“ops”账号了事。必须分层控制：
- 三类角色分离：系统管理员（管平台）、审计员（查日志）、普通运维员（连资产），避免一人兼多权
- 资产分组管理：按业务线（如“支付集群”“风控 DB”）或环境（prod/staging）划分资产组，授权时按组分配，不直接授单台 IP
- 系统用户映射：为每台被管服务器创建专用运维账号（如
jump_user），禁止复用 root；该账号仅用于跳板机登录，密码由堡垒机托管或通过密钥自动分发 - Sudo 精确授权：在目标服务器上限制 jump_user 只能执行必要命令（如
/bin/ls, /usr/bin/systemctl status），禁用sudo su -
三、连接方式与审计落地要点
真正起作用的审计，不是“能录屏”，而是“录得准、查得快、不可删”：
- 协议兼容性：确认堡垒机支持目标资产的实际访问方式——MySQL 运维需数据库协议代理，Windows 服务器需 RDP/H5 桌面，网络设备常用 Telnet/SSH
- 命令级记录：启用 shell 命令审计（非仅登录日志），记录完整命令行（含参数），例如
rm -rf /data/tmp/*而非模糊的“执行了 shell 命令” - 会话录像存储：录像文件应落盘到独立路径，并开启定期归档（如自动压缩上传至对象存储），本地保留≤30 天
- 敏感操作阻断：配置命令防火墙，对高危指令（
dd if=, chmod 777, mkfs）实时告警并可选阻断，需结合黑白名单策略
四、安全加固与日常维护
跳板机本身是高价值攻击目标，自身防护不能妥协：
- 禁用密码直连堡垒机：仅允许密钥登录 + 双因子（如 Google Authenticator 或短信），root 登录必须关闭
- 审计日志防篡改：启用 Linux auditd 服务，监控堡垒机自身关键目录（
/opt/jumpserver/logs/,/var/log/teleport/）的写入行为 - 定期凭证轮换：堡垒机后台数据库密码、管理员账号、各资产系统用户的密码 / 密钥，按策略（如 90 天）自动更新
- 操作回溯验证：每月抽样 10 条生产问题工单，反向验证对应时间点的命令记录与录像是否完整可回放
