SSH 日志管理与安全分析：配置、解读与暴力破解告警

SSH 日志（SSH Log）是由 SSH 守护进程 sshd 生成的安全审计记录，涵盖登录成功/失败、认证方式、来源 IP、会话断开等远程访问事件，但并非完整的会话命令审计，是发现暴力破解与未授权访问的核心数据源。 凡是有公网 IP 的服务器，SSH 日志里从不缺少"访客"——区别在于你是否在看。

核心要点速览

• 日志位置：Debian/Ubuntu 在 /var/log/auth.log，RHEL/CentOS 在 /var/log/secure，systemd 系统用 journalctl -u ssh；
• 生产可评估 LogLevel VERBOSE 获取更详细的认证记录；密钥指纹并非所有版本都只在 VERBOSE 下记录；
• 单机分析三板斧：grep 过滤失败记录、awk 统计 TOP 来源 IP、journalctl 按时间/级别过滤；
• 持续安全监控的正确姿势：DataKit 采集 → Pipeline 结构化 → 观测云监控器对"失败次数突增、root 登录成功"实时告警。

SSH 日志存在哪里？

这些是常见路径，是否存在取决于 syslog/journal 路由；服务单元也可能叫 sshd。拿不准时先查服务启动参数，再用对应配置的 sshd -T 检查有效设置；只 grep 主文件会遗漏 Include 等配置。

典型日志条目解读

成功登录（密码/密钥）：

Jul 17 15:45:23 web sshd[5678]: Accepted password for devuser from 10.0.2.15 port 49812 ssh2
Jul 17 15:49:45 web sshd[5680]: Accepted publickey for jenkins from 10.0.2.20 port 52413 ssh2: RSA SHA256:LmNo...

失败尝试（重点监控对象）：

Jul 17 15:47:10 web sshd[5679]: Failed password for invalid user admin from 192.0.2.82 port 38654 ssh2

invalid user 表示对方尝试了一个系统上不存在的用户名——扫描探测的典型特征。

会话断开：

Jul 17 16:02:33 web sshd[5678]: Disconnected from user devuser 10.0.2.15 port 49812

上面的示例包含五要素：时间、主机、进程（sshd[PID]）、事件、来源（用户/IP/端口/协议）。

日志详细程度怎么调？

编辑 /etc/ssh/sshd_config：

LogLevel VERBOSE
SyslogFacility AUTHPRIV

• LogLevel 可选 QUIET/FATAL/ERROR/INFO/VERBOSE/DEBUG(1-3)。生产可评估 VERBOSE 以增加认证细节；用实际版本生成的日志核对密钥指纹，指纹可关联所用密钥，但不能单独证明操作者身份。DEBUG 仅排障时临时开启；
• SyslogFacility 决定日志归入哪个 syslog 设施，AUTHPRIV 适合认证类敏感日志，但设施名称本身不设置文件权限；限制访问仍取决于日志服务配置、文件权限和 journal 授权。

改完先用实际启动配置执行 sudo sshd -t 检查语法，保留当前管理会话；确认服务单元为 ssh 或 sshd、且支持 reload 后重新加载，并用另一会话验证登录。

单机分析：常用命令组合

# 密码认证失败记录；不涵盖全部认证失败类型
grep "Failed password" /var/log/auth.log

# 按来源 IP 统计失败次数，降序排列——暴力破解来源一目了然
grep "Failed password" /var/log/auth.log | awk '{for (i=1; i<NF; i++) if ($i == "from") {print $(i+1); break}}' | sort | uniq -c | sort -nr | head

# journalctl 进阶过滤
journalctl -u ssh --since "1 hour ago"    # 最近一小时
journalctl -u ssh -p err                  # 仅 err 及更严重级别；可能遗漏 INFO 级认证失败
journalctl -u ssh -f                      # 实时跟踪

排障速查

• 用户报无法登录：先 grep "authentication failure" auth.log；
• 权限问题：grep "bad ownership or modes"——SSH 对 ~/.ssh（700）与 authorized_keys（600）权限极敏感；
• 密钥被拒绝：grep "key_read" 相关记录。

集中监控：从"定期抽查"到"实时告警"

单机命令适合临时排查，但安全监控必须是 7×24 的。观测云落地：

1. 采集与结构化：DataKit 磁盘文件采集 auth.log/secure，Pipeline grok 切割出 username、src_ip、auth_method 等字段，含 Failed 的行标记 status = "error"、Accepted 标记为 info [1][2]；
2. 实时检索与聚类：日志查看器中按 src_ip 分组看攻击来源排行，聚类分析自动归并扫描器刷出的海量同类记录，可辅助发现异常模式（如罕见用户名），不能保证自动识别所有新型攻击 [3]；
3. 监控器告警（监控 > 监控器 > 日志检测）[4]：
   • root 登录成功：在设定检测窗口内出现 ≥1 条时触发；通知时延取决于采集、检测频率和通知配置；
   • 暴力破解：同一 src_ip 5 分钟内失败 > 20 次触发；
   • 异常维度：密码认证成功（应全走密钥）、非白名单 IP/用户登录成功；
   • 告警策略绑定钉钉/企业微信/飞书通知对象，事件中心统一跟进；
4. 配合加固：禁 root 直连、禁密码登录、可用改端口减少部分扫描噪声（不能替代认证加固）、Fail2Ban 封禁、MFA——监控发现规律，加固堵住入口，两者缺一不可。

总结

SSH 日志安全运营的要义：VERBOSE 可补充认证证据，集中化需核对主机采集覆盖，监控器需验证检测与通知链路。命令行回答"刚才发生了什么"，观测云回答"此刻全网每台机器正在发生什么"。

常见问题（FAQ）

Q：auth.log 里全是陌生 IP 的失败记录，服务器被入侵了吗？
失败记录本身不代表入侵——公网服务器被扫描是常态。需要警惕的信号是：出现 Accepted 的可疑成功登录、针对真实用户名的高频尝试、来自可信 IP 段的异常失败（可能内鬼或跳板失陷）。

Q：LogLevel DEBUG 能长期开吗？
不建议。DEBUG（尤其 DEBUG3）会记录大量会话细节，日志体积暴涨且可能含敏感信息。排障时临时开启，问题解决后调回 VERBOSE。

Q：如何区分自己的登录和攻击者的登录？
三点辅助核对：来源 IP 是否在你的常用网络/跳板机白名单内、认证方式是否为密钥、登录时间是否符合你的工作时段；这些均不能单独证明身份，还需核对密钥归属、堡垒机或身份系统记录。这正是要把成功登录也纳入告警并记录密钥指纹的原因。

Q：观测云里能直接看到"谁在扫我"的统计吗？
可以。日志查看器中按 src_ip 对 status: error 的 SSH 日志做分组计数即可得到 TOP 失败记录来源列表（IP 不等于攻击者身份），该视图可导出到仪表板长期跟踪。

---

系列阅读：Linux 认证日志监控实战 ｜ 日志监控是什么

[1]: 观测云文档《DataKit 日志采集综述》https://docs.guance.com/integrations/logging/
[2]: 观测云文档《日志采集》https://docs.guance.com/logs/collection/
[3]: 观测云文档《日志查看器》https://docs.guance.com/logs/explorer/
[4]: 观测云文档《监控》https://docs.guance.com/monitoring/