我注意到，我的系统日志报告一些身份validation条目不正确的时间。 典型的行为如下所示：
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。
请注意，一个进程29537总是发送比进程29538晚一小时标记的消息。系统日志协议指定客户端发送以文本MMM DD HH：MM：SS格式加时间戳的消息，而不是明智之举。
在UNIX / Linux上，有一个系统时间（自1970年以来的秒数），但是系统上的每个进程都可以把它解释为它被放置在不同的时区。 这是如何处理的，每个想要将秒数转换为实际的HH：MM：SS文本的进程首先读取$ TZ环境variables。 由于每个进程都有自己独立的环境，因此每个进程可以具有不同的$ TZ值，并显示不同时区的date。
在你的系统上，如果/ etc / environment中的$ TZ已被修改，但是sshd进程从那时起还没有被重启，它将使用原来的$ TZ。 所以请重新启动所有的sshd进程并重复你的testing。
你不会碰巧有两个syslog守护进程同时运行，其中一个还没有正确configuration（即你改变了夏令时生效的时间，并没有重新启动）？ 然后竞争条件影响哪个守护进程拦截系统调用并写入磁盘。