大量 sudo pam_unix session 日志的 rsyslog / journald rate-limit 配置

直接压制方法是配置rsyslog的$systemlogratelimitinterval 60和$systemlogratelimitburst 10，并置于/etc/rsyslog.conf顶部；journald限流对pam_unix无效；禁用debug参数、前置session过滤规则；不可用$msg过滤替代限速。

rsyslog 中 pam_unix session 日志暴增的直接压制方法

默认 rsyslog 不限制 pam_unix 的 session 类日志（如 session opened for user、session closed for user），ssh 频繁重连、systemd-tmpfiles 或 cron 触发的 PAM session 会瞬间刷屏，撑爆磁盘或拖慢 rsyslogd。

关键不是过滤掉，而是限速——用 $SystemLogRateLimitInterval 和 $SystemLogRateLimitBurst 控制单位时间内的最大条数：

• $SystemLogRateLimitInterval 60：每 60 秒为一个窗口
• $SystemLogRateLimitBurst 10：该窗口内最多记录 10 条，超出丢弃（不写磁盘，也不排队）
• 这两行必须放在 /etc/rsyslog.conf 顶部（在任何 $IncludeConfig 之前），否则不生效
• 改完后 sudo systemctl restart rsyslog，立刻生效，无需 reload

journald 对 pam_unix 的 rate-limit 实际无效？

journald 确实有 RateLimitIntervalSec 和 RateLimitBurst，但它们只对同一 SYSLOG_IDENTifIER + 同一 PRIORITY + 同一消息内容（完全匹配）生效。而 pam_unix 的 session 日志每次用户、PID、时间戳都不同，几乎不会触发去重限流。

所以别指望 /etc/systemd/journald.conf 里的 rate-limit 能压住它。真正有效的做法是：

• 确认 pam_unix.so 没开 debug 或 verbose —— 检查 /etc/pam.d/sshd、/etc/pam.d/system-auth 等文件中是否有 debug 参数
• 禁用非必要 session 记录：在 /etc/pam.d/common-session（debian/ubuntu）或 /etc/pam.d/postlogin（RHEL/centos）里，把 session [default=ignore success=ok] pam_succeed_if.so service in crond:cron:atd quiet 这类兜底规则前置，避免所有服务都走 pam_unix.so 写 session
• 如果用的是 systemd-logind，它本身已做 session 合并，但 SSH 直连绕过 logind，所以仍需从 PAM 层控制

为什么不能简单用 rsyslog 的 if $msg 匹配过滤？

有人想用 if $msg contains 'session opened' then stop 直接丢弃，这看似省事，实则危险：

• 会同时干掉合法的登录审计线索，比如安全团队依赖这些日志做异常登录检测
• $msg 是原始字符串，含空格和时区，正则易误伤（例如匹配到 session opened by UID 0 却漏掉 session opened for user root）
• 过滤发生在 rate-limit 之后，意味着“先写再删”，磁盘 I/O 和 CPU 开销照旧，只是没落盘——对高负载机器毫无缓解作用
• 真正要的是“不产生”而非“产生了再扔”，所以必须用 rate-limit 在源头掐住生成节奏

验证 rate-limit 是否起效的三步检查法

改完配置别信重启就 OK，得看真实行为：

• 用 sudo journalctl -u rsyslog --no-pager -n 20 查最近 rsyslog 自身日志，找 rate limit hit 或 discarded 字样（注意：rsyslog 8.20+ 才输出这类提示）
• 模拟压力：用 for i in {1..50}; do ssh -o ConnectTimeout=2 -o BatchMode=yes localhost 'true' 2>/dev/NULL; done 快速触发 50 次 session，然后 sudo journalctl -t pam_unix --no-pager -n 30 看是否真被压到 10 条左右
• 检查 /var/log/auth.log（或对应文件）末尾时间戳是否密集连续——如果仍是秒级连写，说明 rate-limit 没加载或位置错了

最常被忽略的是配置顺序和单位：interval 必须是整数秒，burst 必须是整数，且二者必须成对出现，缺一不可。错一个数字，整个限流逻辑就失效。