配置auditd审计ssh密钥认证需监控sshd执行、authorized_keys读取及密钥签名系统调用，并关联openssh verbose日志实现四维证据链，同时持久化规则、导出合规报告并规避agent、容器和auid混淆等盲区。
配置 auditd 审计 SSH 密钥认证，核心不是“记录登录成功”，而是捕获密钥使用全过程——包括私钥调用、公钥比对、签名验证等底层行为。OpenSSH 本身不直接向 auditd 上报密钥认证事件，必须通过 auditd 主动监控关键系统调用和文件访问，再结合 OpenSSH 的 VERBOSE 日志交叉验证，才能满足等保2.0、ISO 27001 等对“操作可追溯、行为可定责”的刚性要求。
监控 SSH 认证关键路径
auditd 需聚焦三个不可绕过的环节：sshd 进程执行、authorized_keys 文件读取、私钥签名操作（由 ssh-agent 或内核 crypto 模块触发）。仅靠日志无法证明“谁在何时调用了哪把密钥”，必须从系统调用层抓取证据。
- 监控 sshd 主进程及其子进程的 execve 调用：
sudo auditctl -a always,exit -F path=/usr/sbin/sshd -F perm=x -k ssh_exec - 监控所有用户 authorized_keys 文件的读取行为：
sudo auditctl -a always,exit -F path=/home/*/authorized_keys -F perm=r -k ssh_authkeys_read
（注意：实际路径需根据用户主目录结构调整，可用 find /home -name "authorized_keys" -type f 确认） - 捕获 ssh-agent 或系统级密钥服务的密钥签名动作（如 Secretive 调用 Secure Enclave）：
sudo auditctl -a always,exit -F arch=b64 -S ioctl,openat,read -F auid>=1000 -F auid!=unset -k ssh_key_use
（该规则覆盖大部分密钥加载与签名调用，需配合 ausearch -m avc -ts recent 排查 SELinux 干预）
关联 OpenSSH 日志实现行为闭环
auditd 单独记录的是“系统动作”，而 OpenSSH 的 VERBOSE 日志记录的是“协议语义”。二者必须时间戳对齐、事件 ID 关联，才能构成完整审计链。例如：auditd 显示某 IP 在 14:22:03 读取了 /home/admin/.ssh/authorized_keys，而 /var/log/auth.log 同一毫秒出现 sshd[12345]: debug1: PAM: setting PAM_RHOST to "192.168.10.5" 和 debug1: key_parse_private_pem: read private key，即形成“谁、从哪、用哪把密钥、何时尝试登录”的四维证据。
- 确保 OpenSSH 启用详细日志：
在 /etc/ssh/sshd_config 中设置：
LogLevel VERBOSE
SyslogFacility AUTH - 强制日志时间精度到毫秒（避免时间漂移导致关联失败）：
sudo timedatectl set-ntp on
sudo systemctl restart rsyslog - 将 auth 日志单独路由至独立文件，便于与 auditd 日志并行分析：
在 /etc/rsyslog.d/50-ssh-audit.conf 中添加：
if $programname == 'sshd' then /var/log/ssh/verbose.log
& stop
审计规则持久化与合规输出
临时 auditctl 规则在重启后失效，必须写入规则文件，并导出结构化报告供等保测评或内部审计使用。
- 将上述规则写入 /etc/audit/rules.d/ssh.rules，然后重载：
sudo augenrules --load - 每日生成 SSH 密钥使用审计摘要（含异常模式识别）：
sudo ausearch -m SYSCALL -i -ts yesterday | grep -E "(sshd|authorized_keys|key_use)" | aureport -f -i --summary
重点关注：同一私钥被多个进程调用、非标准路径下的 authorized_keys 被读取、无 PAM 记录却有密钥读取行为 - 导出符合 GB/T 22239—2019（等保2.0）要求的原始审计数据包：
sudo aureport -m -ts 7days --raw | gzip > /var/log/audit/ssh_audit_$(date +%Y%m%d).log.gz
该压缩包应包含完整 syscall、path、auid、uid、comm 字段，且不可被普通用户修改或删除（建议设置 chattr +a）
规避常见审计盲区
很多团队以为开了 auditd 就万事大吉，实际存在三类高频盲区，直接导致审计证据链断裂：
- 忽略 ssh-agent 生命周期：若用户使用 ssh-agent -s 启动代理，后续密钥调用不再经过 sshd 进程，auditd 必须额外监控 agent socket 文件（如 /tmp/ssh-XXXXXX/agent.XXXX）的 connect 和 write 行为；
- 未覆盖容器环境：Docker/Podman 中运行的 sshd 不共享宿主机 auditd 规则，需在容器启动时挂载 /etc/audit/rules.d/ 并启用 --privileged 或明确授权 audit_write capability；
- 混淆 real uid 与 audit uid：sudo 切换用户后，sshd 进程的 uid 变为目标用户，但 auid（audit uid）仍为原始登录者。审计时必须用 auid 匹配责任人，而非 uid，否则无法追溯到真实操作人。
