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
& 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 日志该刷屏还是刷屏。
