SSH-CA仅解决身份可信问题，认证通过后shell交互默认不记录，需配合ForceCommand、ttylog或跳板机才能实现命令级审计。
SSH-CA 证书体系本身不直接提供会话内容审计能力，必须配合 ForceCommand、session log 或跳板机架构才能实现可回溯的操作审计。
为什么直接用 SSH-CA 无法审计命令执行过程
SSH-CA 解决的是「身份可信」问题：它让服务器确认“这个用户确实是 LDAP 里叫 john 的人，且证书没过期、没被吊销”。但一旦认证通过，后续所有 shell 交互都走标准 SSH 通道，服务端默认不记录具体输入输出。
常见误解是以为启用 TrustedUserCAKeys 后就能看到用户干了什么——实际日志里只有登录/登出时间、源 IP、用户名，看不到 rm -rf / 或 mysql -e "DROP DATABASE" 这类关键操作。
- OpenSSH 默认只记录认证事件（
/var/log/secure或journald中的sshd日志） - 用户启动的交互式 shell（如 bash）完全脱离 sshd 控制，除非显式介入
- CA 证书和普通公钥登录在会话层无区别，审计能力取决于后续链路设计
必须配置 ForceCommand + ttylog 或 script 实现命令级审计
要在目标主机本地完成基础审计（不依赖跳板机），核心是拦截用户登录后的 shell 启动过程。OpenSSH 提供 ForceCommand 指令，在用户认证成功后强制执行指定命令，绕过其 ~/.ssh/authorized_keys 中的 command= 或 shell 设置。
实操建议：
- 在
/etc/ssh/sshd_config中为需审计的用户或组添加匹配规则：Match Group audit-teamForceCommand /usr/local/bin/ttylog-wrapper -
ttylog-wrapper是一个封装脚本，负责调用script -q -f -t 0 /var/log/audit/$(date +%Y%m%d)/$USER-$(date +%s).log，再 exec 用户真实 shell - 确保
/var/log/audit目录权限为750，属主为root:audit-log，且audit-log组不可写入日志文件 - 禁用用户修改
~/.bashrc或~/.profile中的HISTFILE，防止绕过历史记录
真正可靠的企业级审计必须落在跳板机上
单台服务器本地审计有明显短板：日志可被提权用户删除、无法统一策略、难以关联多跳行为。2026 年主流方案已收敛到「跳板机 + CA 认证 + 会话录像」三层结构。
关键配置点：
- 跳板机自身必须用 SSH-CA 认证（用户证书 + 主机证书双向验证），杜绝中间人风险
- 所有内网服务器
/etc/ssh/sshd_config中设置AllowUsers @jump-hosts，仅允许跳板机 IP 登录，关闭直接公网访问 - 跳板机上启用
MaxSessions 1和PermitTunnel no，防代理穿透 - 会话录像工具推荐
asg-ssh或teleport（非 openssh 自带），它们能捕获完整终端流并生成可搜索的 web 回放
CA 证书生命周期管理直接影响审计有效性
审计日志里的 user-john 标识是否可信，取决于证书签发时的上下文是否真实可控。如果 CA 私钥泄露或签发流程未绑定 HR 系统，那么日志里所有 “john” 操作都可能伪造。
容易被忽略的硬性要求：
-
ssh-keygen -s签发时必须用-I指定唯一标识（如emp-12345@hr-system），不能只用john这种易冲突名 - 所有证书必须带
-V +4w类有效期限制，避免长期有效证书成为审计盲区 - CA 的
revoked_keys文件需每日同步到所有服务器，且sshd配置中启用RevokedKeys /etc/ssh/revoked_keys - 证书吊销事件必须触发 SIEM 告警，而非仅写入文件
最常被跳过的环节是证书与账号生命周期解耦——HR 系统里员工已离职，LDAP 账号被禁用，但其 SSH 证书仍有效两周。此时审计日志显示“合法证书登录”，实际已是越权访问。CA 不是银弹，它只是把信任锚点从密码转移到密钥，而审计的可靠性永远取决于这个锚点怎么铸、怎么管、怎么废。
