☰

syslog（auth log）报告错误的时间

tag-icon • tag-icon time syslog ssh timezone
syslog（auth log）报告错误的时间

我注意到我的系统日志报告了一些身份验证条目的错误时间。典型的行为如下：

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 守护进程，其中一个尚未正确配置（即，您更改了夏令时生效的时间，但没有重新启动它）？然后竞争条件会影响哪个守护进程拦截系统调用并写入磁盘。

相关内容