Я заметил, что мой системный журнал сообщает неверное время для некоторых записей аутентификации. Типичное поведение выглядит так:
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. Поскольку каждый процесс имеет свою собственную отдельную среду, каждый процесс может иметь различное значение $ TZ и отображать даты из другого часового пояса.
В вашей системе, если $ TZ был изменен в / etc / environment, но процесс sshd с того времени не перезапускался, он будет использовать исходный $ TZ. Поэтому перезапустите все процессы sshd и повторите тест.
У вас не бывает двух запущенных одновременно демонов системного журнала, один из которых не был настроен должным образом (то есть вы изменили время, когда переход на летнее время вступил в силу, и не перезапустили его)? Затем состояние гонки влияет на то, какой демон перехватывает системный вызов и записывает на диск.