Linux系统安全日志（auth/authpriv）不能靠全局开关调低级别，必须在rsyslog配置文件中显式指定如auth.warning等规则，否则默认记录info及以上全部消息，易淹没关键事件；其规则独立于*.info，需单独配置并注意顺序。
直接说结论：Linux系统安全日志（主要是 auth 和 authpriv 设施）的记录等级不能靠全局开关“一键调低”，必须在 /etc/rsyslog.conf 或 /etc/rsyslog.d/ 下的规则中显式指定级别，否则默认会记录所有 info 及以上消息——包括大量 info 级别的 SSH 登录成功、sudo 命令执行等，极易淹没真正关键的 err 或 crit 事件。
auth/authpriv 日志规则必须单独写，不能依赖 *.info
很多人误以为改了 *.info 就能控制安全日志，但实际 auth.* 和 authpriv.* 是独立规则，常被写在配置文件靠后位置，优先级高于通配规则。它们默认是 auth.* 或 authpriv.*，意味着所有 info 及以上都会落盘。
- 查当前规则：
grep -E "^(auth|authpriv)\." /etc/rsyslog.conf /etc/rsyslog.d/*.conf - 典型危险写法：
auth.* /var/log/auth.log—— 这会记录每次 SSH 登录成功（info）、密码错误（warning）、密钥拒绝（notice）等，日志量爆炸 - 合理写法应明确限定级别，例如只记录 warning 及以上：
auth.warning /var/log/auth.log - 若需保留登录成功但过滤掉失败尝试，可用
auth.info;auth.!warning /var/log/auth.log（注意语法：分号分隔，!表示排除）
sshd 和 sudo 的日志来源不等于 auth 设施
sshd 默认走 auth 设施，但部分发行版（如 RHEL/CentOS 8+）或启用了 UsePAM 的配置，会把失败登录打到 authpriv；而 sudo 默认走 auth，但它的详细命令日志可能受 syslog 模块配置影响，不一定全在 /var/log/auth.log 中。
- 确认 sshd 实际设施：
sshd -T | grep -i syslog，看输出是否含syslog_facility AUTH或AUTHPRIV - sudo 日志位置取决于
/etc/sudoers中的Defaults syslog设置，常见值为auth或local2，不是固定写死的 - 不要只盯
/var/log/auth.log，用journalctl -t sshd -p warning或journalctl _COMM=sudo -p err直接按程序和级别过滤更可靠
rsyslog 动态过滤比静态规则更准，但要防顺序陷阱
用 $syslogseverity 字段做条件判断（比如只收 severity ≤ 4 即 warning 及以上），比改 auth.warning 更细粒度，但规则顺序决定成败——它必须放在通用规则（如 *.*）之前，否则日志早被前面规则吃掉了。
- 正确顺序示例（写入
/etc/rsyslog.d/30-security-filter.conf）：if $syslogfacility-text == 'auth' and $syslogseverity <= 4 then /var/log/auth-critical.log<br>& stop
-
& stop不可省：阻止后续规则重复写入，否则既写进auth-critical.log又写进默认auth.log - 验证 severity 数值：
emerg=0,alert=1,crit=2,err=3,warning=4,notice=5,info=6,debug=7 - 测试规则是否生效：
logger -p auth.warning "test warning"+logger -p auth.info "test info"，然后检查目标文件是否只含前者
真正难的不是写哪一行配置，而是搞清某条日志到底从哪个程序发出、经由哪个 facility、被哪个 rsyslog 规则捕获、又是否被 & stop 截断——漏掉任意一环，auth 日志该刷屏还是刷屏。
