fail2ban依赖rsyslog规范输出ssh等认证日志，需确认authpriv设备启用、统一logpath路径、校验文件权限与轮转配置，并可选对接journald实现免路径管理。
Fail2Ban 本身不采集日志，它依赖外部日志系统提供原始记录。要让它稳定、准确地工作，必须先让 rsyslog 把 SSH 等关键认证事件“规整地送过来”——不是靠猜路径，而是明确指定来源、设备、级别和落盘位置。
确认日志源与设备类型
SSH 登录失败默认由 authpriv 设备生成，这是系统级安全事件的专用通道。rsyslog 默认已接收该设备日志，但需验证是否启用：
- 检查 /etc/rsyslog.conf 或 /etc/rsyslog.d/50-default.conf 中是否有类似
authpriv.* /var/log/auth.log的规则（Debian/Ubuntu）或authpriv.* /var/log/secure（CentOS/RHEL） - 若使用自定义配置（如将 SSH 日志单独分离），需确保
sshd进程明确指定了日志设施：在 /etc/ssh/sshd_config 中添加或修改SyslogFacility authpriv - 修改后执行
sudo systemctl restart rsyslog sshd生效
统一日志路径并适配 Fail2Ban
Fail2Ban 的 jail 配置中 logpath 必须严格匹配 rsyslog 实际写入的文件。常见对应关系如下：
- Debian/Ubuntu 系统：
logpath = /var/log/auth.log - CentOS/RHEL 系统：
logpath = /var/log/secure - 若自定义为
/var/log/sshd.log，则 rsyslog 需配置authpriv.* /var/log/sshd.log，且 Fail2Ban 中同步更新logpath
增强日志可靠性：权限与轮转
日志文件权限错误或轮转丢失会导致 Fail2Ban “读不到新内容”，这是高频故障点：
- 确保日志文件属主为
root:adm（Debian系）或root:root（RHEL系），权限为640 - 检查 /etc/logrotate.d/rsyslog（或 /etc/logrotate.d/syslog）中是否包含
create 640 root adm或类似语句，防止轮转后权限重置 - 避免使用
copytruncate模式——它会清空原文件，导致 Fail2Ban 丢失游标位置；推荐用rotate+postrotate发送 HUP 信号
可选进阶：对接 systemd-journald
若系统使用 journald 为主日志后端（如较新 CentOS/RHEL 或 Ubuntu），可跳过文件路径依赖，直接让 Fail2Ban 订阅 journal 流：
- 在 jail 配置中设置
backend = systemd - 指定精准匹配条件：
journalmatch = _SYSTEMD_UNIT=sshd.service - 无需手动管理日志路径或轮转，Fail2Ban 自动处理游标和事件去重
