真正能查到“谁在何时干了什么”的只有 auditd 的 execve 日志，因为 ~/.bash_history 不完整、不可靠、易被绕过；auditd 记录内核级 execve 调用，含 UID、PID、tty、真实路径和参数，且无法被用户层绕过。
不能只看 ~/.bash_history，它不完整、不可靠、易被绕过；真正能查到“谁在何时干了什么”的，只有 auditd 的 execve 日志。
为什么直接 cat /home/user/.bash_history 不行
普通用户自己的 .bash_history 文件只存 shell 会话退出时写入的命令，且默认没时间戳；多个终端之间不同步；history -c、HISTFILE=/dev/null、非交互式执行（如 ssh user@host 'rm -f /tmp/*'）全都不记录；root 虽能读别人家目录下的该文件，但内容可能已被手动清空或伪造。
-
~/.bash_history是用户自己维护的缓存，不是系统审计日志 - 它不记录 UID、PID、tty、真实路径（比如软链接展开后的真实二进制）、参数内容
- 同一账号多人共用（如跳板机
ops）时，完全无法区分操作者
用 ausearch 查指定用户的 execve 记录
ausearch 是唯一能从内核 audit 日志中提取真实执行行为的工具，前提是 auditd 已启用并配置了 execve 规则。
- 确认服务运行：
sudo systemctl status auditd - 查用户
john最近所有命令：sudo ausearch -u john -m execve --raw | aureport -f -i - 查某次登录会话（比如
tty2）的操作：sudo ausearch -ts recent -m event --session $(loginctl show-user john -p SessionId | cut -d= -f2)（注意 session ID 需实际获取） - 原始日志在
/var/log/audit/audit.log，但别直接cat——字段密集难读，ausearch是唯一实用入口
auditctl 规则必须带 arch 参数才生效
x86_64 系统上只写 -S execve 是无效的，auditd 会静默忽略规则；必须显式指定架构，否则日志里根本不会出现对应事件。
- 正确加载（64 位）：
sudo auditctl -a always,exit -F arch=b64 -S execve - 兼容 32 位程序（如某些容器内命令）需额外加：
sudo auditctl -a always,exit -F arch=b32 -S execve -
-F uid!=0这类过滤建议去掉——auditd对 uid 类型判断严格，容易导致整条规则加载失败而漏记全部事件 - 规则只存在内存中，重启即失效；必须写入
/etc/audit/rules.d/execve.rules并执行sudo augenrules --load
没有 auditd 时的临时补救：syslog + PROMPT_COMMAND
仅适用于 bash/zsh 且你有权限改目标用户配置的场景，比如跳板机上无法启 auditd；但它依赖 shell 启动，可被 unset PROMPT_COMMAND 绕过，也不记录非交互式执行。
- 在用户
~/.bashrc中加：export PROMPT_COMMAND='RETRN_VAL=$?;logger -p local6.info "$(whoami) [$$] $(history 1 | sed "s/^[ ]*[0-9]\+[ ]*//") [$RETRN_VAL]"' - 配置 rsyslog：
echo 'local6.* /var/log/user-commands.log' | sudo tee /etc/rsyslog.d/99-user-cmd.conf，再sudo systemctl restart rsyslog - 日志只含命令行字符串、UID、PID、返回值，不含完整路径、tty 或精确时间戳（依赖 syslog 时间）
真正关键的不是“用户想记什么”，而是“内核记下了什么”；execve 系统调用日志是唯一绕不开内核、无法被用户层屏蔽的证据源。如果 auditd 没开，~/.bash_history 就只是个参考草稿，不是操作记录。
