Linux 系统安全日志（auth/authpriv）无法通过全局开关直接降低记录级别，必须在 rsyslog 配置文件中显式指定如 auth.warning 这类规则；否则默认会记录 info 及以上的全部消息，极易淹没真正重要的安全事件。同时，这类规则独立于 *.info，必须单独配置，并特别注意规则顺序。
先说结论：在 Linux 中配置系统安全日志等级时，尤其是 auth 与 authpriv 两类日志，不能依赖一个“全局日志级别”就统一调低。想要精准控制日志记录范围，必须到 /etc/rsyslog.conf 或 /etc/rsyslog.d/ 下的 rsyslog 规则中明确指定级别；否则系统通常会按默认行为，将所有 info 及以上级别的消息全部写入日志。这样会带来什么问题？大量 info 级别的 SSH 登录成功、sudo 执行记录等安全日志会持续增长，很容易把真正需要重点关注的 err 或 crit 事件淹没掉，导致关键安全告警不够醒目。
auth/authpriv 日志规则必须单独写，不能依赖 *.info
很多管理员误以为修改 *.info 就能顺带控制 Linux 安全日志，但实际上 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 facility，但在部分发行版环境中，例如 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 往往更精细、更灵活。但要注意，rsyslog 规则顺序会直接影响结果——这类过滤必须放在通用规则（如 *.*）之前，否则日志早已被前面的规则捕获并写入。
- 正确顺序示例（写入
/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"，然后检查目标文件中是否只保留前者
实际配置 Linux 安全日志等级时，最难的往往不是写出哪一行 rsyslog 配置，而是弄清楚某条日志究竟由哪个程序发出、使用了哪个 facility、被哪条 rsyslog 规则匹配，以及是否又被 & stop 提前截断——只要其中任何一个环节判断错误，auth 日志该刷屏还是会刷屏，日志优化也就难以真正生效。
