![syslog(auth log)报告错误的时间](https://linux22.com/image/506093/syslog%EF%BC%88auth%20log%EF%BC%89%E6%8A%A5%E5%91%8A%E9%94%99%E8%AF%AF%E7%9A%84%E6%97%B6%E9%97%B4.png)
我注意到我的系统日志报告了一些身份验证条目的错误时间。典型的行为如下:
Feb 16 13:32:20 dev sshd[29537]: Invalid user oracle from 110.188.0.123
Feb 16 12:32:20 dev sshd[29538]: input_userauth_request: invalid user oracle
Feb 16 13:32:20 dev sshd[29537]: pam_unix(sshd:auth): check pass; user unknown
Feb 16 13:32:20 dev sshd[29537]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=110.188.0.123
Feb 16 13:32:20 dev sshd[29537]: pam_succeed_if(sshd:auth): error retrieving information about user oracle
Feb 16 13:32:22 dev sshd[29537]: Failed password for invalid user oracle from 110.188.0.123 port 64368 ssh2
Feb 16 12:32:23 dev sshd[29538]: Received disconnect from 110.188.0.123: 11: Bye Bye
注意小时是如何来回切换的。有人见过类似的行为吗?是什么原因造成的?这似乎是有系统的,每次连接尝试都会报告相同的条目,但报告的时间比实际时间早一个小时。系统时钟为 GMT。时区为 GMT+1。
答案1
请注意,进程 29537 发送的消息总是比进程 29538 晚一小时。Syslog 协议规定客户端发送的消息带有文本 MMM DD HH:MM:SS 格式的时间戳,这根本不是一个明智的做法。
在 UNIX/Linux 上,有一个系统时间(自 1970 年以来的秒数),但系统上的每个进程都可以将其解释为位于不同的时区。如何处理这个问题,每个想要将秒数转换为实际 HH:MM:SS 文本的进程首先读取 $TZ 环境变量。由于每个进程都有自己独立的环境,因此每个进程可以具有不同的 $TZ 值并显示来自不同时区的日期。
在您的系统上,如果 /etc/environment 中的 $TZ 已更改,但此后 sshd 进程尚未重新启动,它将使用原始 $TZ。因此,请重新启动所有 sshd 进程并重复测试。
答案2
您不会碰巧同时运行两个 syslog 守护进程,其中一个尚未正确配置(即,您更改了夏令时生效的时间,但没有重新启动它)?然后竞争条件会影响哪个守护进程拦截系统调用并写入磁盘。