syslog (log de autenticação) relata tempo incorreto

Question

Tenho notado que meu syslog relata tempo incorreto para algumas entradas de autenticação. O comportamento típico é assim:

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

Observe como a hora troca e para trás. Alguém viu um comportamento semelhante? O que pode causar isso? Parece sistemático e são as mesmas entradas para cada tentativa de conexão que são relatadas uma hora antes do que deveriam ser. O relógio do sistema é GMT. Fuso Horário GMT + 1.

    

Answer 1

Observe que um processo 29537 sempre envia mensagens marcadas uma hora depois do processo 29538. O protocolo Syslog especifica que os clientes enviam mensagens com registro de data e hora em um formato textual MMM DD HH: MM: SS, nada sensato.

No UNIX / Linux, existe uma hora do sistema (número de segundos desde 1970), mas cada processo em um sistema pode interpretá-lo como se fosse colocado em um fuso horário diferente. Como isso é tratado, cada processo que deseja converter número de segundos para o texto HH: MM: SS real lê primeiro a variável de ambiente $ TZ. Como cada processo tem seu próprio ambiente separado, cada processo pode ter um valor diferente de $ TZ e exibir datas de um fuso horário diferente.

No seu sistema, se $ TZ foi alterado em / etc / environment, mas o processo sshd não foi reiniciado desde então, ele usará o $ TZ original. Então por favor reinicie todos os processos do sshd e repita o seu teste.

    

Answer 2

Você não tem dois syslog daemon em execução ao mesmo tempo, um dos quais não foi configurado corretamente (ou seja, você alterou a hora em que o horário de verão entrou em vigor e não o reiniciou)? Em seguida, uma condição de corrida afeta qual daemon intercepta o syscall e grava no disco.