堡垒机审计完全由其实例侧完成，Linux服务器只需开放SSH并确保堡垒机能成功代理连接；需在堡垒机侧开启字符命令审计开关，并配置匹配的认证方式与审计策略。

堡垒机本身不依赖 Linux 服务器做审计，审计行为完全由堡垒机实例侧完成；Linux 服务器只需按标准方式接入并开启 SSH 协议即可被审计。关键不是“在 Linux 上配置”，而是“让 Linux 成为堡垒机可审计的资产”。

Linux 服务器必须开放 SSH 且密码/密钥能被堡垒机验证

堡垒机审计字符会话的前提是：它能成功代理并建立 SSH 连接。如果连不上，就不可能记录命令、剪切板、文件操作等任何行为。

• 确保 sshd 服务运行中，且监听端口（默认 22）未被防火墙拦截（含系统防火墙和云安全组）
• 堡垒机添加主机账户时，“认证类型”选 密码 或 私钥，必须与 Linux 实际登录方式一致
• 若用密码，需确认该账户密码未过期、未被 passwd -l 锁定；若用私钥，私钥格式必须为 PEM（-----BEGIN RSA PRIVATE KEY-----），不能是 OpenSSH 新格式（-----BEGIN OPENSSH PRIVATE KEY-----）
• 验证密码失败常见于：PermitRootLogin no 且堡垒机填了 root 账户但未开允许；或 AllowUsers 白名单里没包含该账户

堡垒机侧必须启用字符会话审计开关

即使 Linux 接入成功，若堡垒机未开启对应审计策略，所有命令操作仍不会落库、不可回放、无法搜索。

• 进入堡垒机控制台 → 操作审计 → 审计策略 → 找到对应 Linux 资产或资产分组的策略
• 确认 字符命令审计 已开启（不是仅开“会话录像”）
• 检查 剪切板审计 和 文件传输审计 是否按需打开——SCP/SFTP 操作只有后者开启才可记录上传/下载动作
• 企业双擎版支持按用户、资产、时间范围设置差异化策略；基础版通常全局统一开关

多运维人员审计数据隔离靠用户身份而非 Linux 账户

审计日志里的 user_name 字段来自堡垒机用户（如 zhangsan@aliyun.com），不是 Linux 的 root 或 ops。这意味着：同一台 Linux 服务器上，不同堡垒机用户执行的命令，在 SLS 日志中天然通过 user_id 和 user_name 隔离。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• 不要让多个运维共用一个堡垒机账号——否则审计日志无法区分谁执行了 rm -rf /
• Linux 主机账户可以复用（例如都用 admin），但堡垒机用户必须一一对应真实人员
• 若需限制某人只能执行 ls/cat，需配置命令控制策略，而非靠 Linux 的 sudoers——后者绕过堡垒机审计
• SLS 中查询某人操作：过滤 user_name: "zhangsan" + resource_address: "192.168.1.100" 即可

审计日志转存到 SLS 后字段含义要对得上

归档到日志服务后，content 字段才是真实敲的命令，但容易误读。比如 content: "ls -la\n" 是正常命令，而 content: "\x1b[2J\x1b[H" 是清屏控制符（非用户输入），需结合 event_type 判断语义。

• event_type: "command" 表示终端键入的命令（含回车）
• event_type: "output" 是命令执行返回的内容（如 ls 列出的文件名），默认不入库，需在审计策略中显式开启“命令输出审计”
• result: "success" 或 "failed" 对应命令是否执行成功，但注意：rm xxx 返回 success 不代表文件真删了，只是 shell 没报错
• 敏感操作如 scp、curl http://xxx、mysql -h 会完整出现在 content 中，无需额外解析

真正容易被忽略的是：审计录像和字符日志是两套机制。RDP 黑屏、SSH 命令漏记，往往不是 Linux 配置问题，而是堡垒机侧的协议解析能力或网络抖动导致会话断连重连——这种间隙期的操作，既不会进 content，也不会有录像帧。