sudo 高频触发 pam_unix(session opened) 日志是正常行为，源于 PAM 模块默认记录 session 开启事件；主因是自动化工具频繁调用 sudo -n 探测权限，推荐通过 rsyslog ratelimit 按 authpriv 和消息内容限流，同时排查并修复调用源头。
为什么 sudo 会高频触发 pam_unix(session opened) 日志
这不是异常，而是 pam_unix 模块在每次成功执行 sudo 命令时的默认行为——它会调用 pam_syslog() 记录 session 开启事件。当有自动化脚本、监控工具（如 Zabbix、Prometheus node_exporter）、或定时任务频繁调用 sudo -n 做权限探测时，日志就刷屏了。
关键点在于：这些日志级别是 LOG_INFO，且由 PAM 子系统生成，rsyslog 或 journalctl 本身无法在接收前过滤（因为 PAM 在用户空间写入 /dev/log，早于 rsyslog 规则匹配）。
- 不建议直接关闭
pam_unix.so的 session 模块（影响 audit 和登录审计） -
sudoers中的NOLOG标签只抑制sudo自身日志，对 PAM session 日志无效 - 修改
/etc/pam.d/sudo注释掉session [default=ignore]行会导致loginuid丢失，影响auditd追踪
在 rsyslog 中按模块+消息内容限流（推荐）
rsyslog v8.33+ 支持 ratelimit 模块，可针对特定 facility+priority+msg 正则做速率控制。PAM 日志通常走 authpriv.*，消息体含 "pam_unix\(session opened"。
在 /etc/rsyslog.d/10-pam-limit.conf 中添加：
module(load="imuxsock" ratelimit.interval="60" ratelimit.burst="5")
if $syslogfacility-text == 'authpriv' and $msg contains 'pam_unix(session opened' then {
action(type="omfile" file="/var/log/auth.log" ratelimit.interval="60" ratelimit.burst="5")
stop
}
-
ratelimit.interval="60"表示每 60 秒窗口 -
ratelimit.burst="5"表示最多放行 5 条匹配日志，超出丢弃 - 必须加
stop，否则日志仍会落入默认auth.log流程 - 注意：该规则需放在默认日志规则（如
*.* /var/log/syslog）之前才生效
用 systemd-journald 的 rate-limit 配置全局压制
如果用 journald 为主日志后端（如 Ubuntu 20.04+/RHEL 8+），可在 /etc/systemd/journald.conf 中启用内建限流：
审查 Remix v2 代码中的 v1 形态 meta 导出（v2 中为破坏性变更），cookie 安全漏洞（httpOnly、secure、密钥轮换），认证门位于错误层级，以及其他
RateLimitIntervalSec=30s RateLimitBurst=10
但这会影响所有 journal 日志源，不够精准。更稳妥的做法是结合 journalctl 过滤 + 外部限流：
- 用
journalctl -o json --no-tail -u systemd-journald | jq -r 'select(.SYSLOG_IDENTIFIER=="sudo" and .MESSAGE | contains("session opened"))'抽取原始事件 - 用
awk或ccze做时间窗口计数并丢弃超量条目（适合调试，不建议生产常驻） - 真正要压住量，还是得回到 rsyslog 的模块级限流，它发生在日志写入磁盘前，开销最低
排查源头比压制日志更重要
日志刷屏本质是上游行为异常。先确认谁在高频调用 sudo：
- 运行
sudo journalctl -o short-iso _COMM=sudo --since "1 hour ago" | wc -l看总量 - 查调用者：
sudo journalctl -o json _COMM=sudo --since "10 minutes ago" | jq -r '.SYSLOG_IDENTIFIER + " " + ._CMDLINE' - 常见元凶：
check_mk的check_sudo插件、zabbix-agent的system.run[sudo ...]、或自定义 health-check 脚本里没加sleep - 修复建议：改用
getent group sudo | grep -q $USER替代sudo -n true探测权限；或把探测周期从 10s 拉长到 5m
限流只是兜底手段。一旦 sudo 调用量突增，往往意味着某个服务配置错、脚本死循环，或权限模型被绕过——这时候盯着日志数量，比调 ratelimit.burst 更有用。
