Hi folks,
while chasing down a logging-related situation, I happened to notice that when I connect via ssh to my system it makes the following logs:
Nov 15 14:15:39 saturn sshd[29868]: Accepted password for dave from ::ffff:10.0.10.14 port 2833 ssh2 Nov 15 09:15:39 saturn sshd[29867]: Accepted password for dave from ::ffff:10.0.10.14 port 2833 ssh2 Nov 15 09:15:39 saturn sshd(pam_unix)[29869]: session opened for user dave by (uid=0)
That is, sshd appears to log the connection with GMT (or UCT) before the child sshd logs it with local time.
This is messing up one of my reporting processes, since I have syslog-ng configured to produce a new file for every day, and at the end of the day I try to scan the newest file for the day's events. So if I ssh to the system after 7PM local time, the "newest" file is the one from "tomorrow" which has the GMT timestamped entries, not the entries from today.
How do I either tell sshd to always use local time, or tell it not to make the first entry?
On 15/11/06, David Mackintosh David.Mackintosh@xdroop.com wrote:
Hi folks,
while chasing down a logging-related situation, I happened to notice that when I connect via ssh to my system it makes the following logs:
Nov 15 14:15:39 saturn sshd[29868]: Accepted password for dave from ::ffff:10.0.10.14 port 2833 ssh2 Nov 15 09:15:39 saturn sshd[29867]: Accepted password for dave from ::ffff:10.0.10.14 port 2833 ssh2 Nov 15 09:15:39 saturn sshd(pam_unix)[29869]: session opened for user dave by (uid=0)
That is, sshd appears to log the connection with GMT (or UCT) before the child sshd logs it with local time.
What do you have set in /etc/sysconfig/clock for ZONE= and UTC= ? Does changing UTC= change the logging behaviour?
Will.
David Mackintosh wrote:
Hi folks,
while chasing down a logging-related situation, I happened to notice that when I connect via ssh to my system it makes the following logs:
Nov 15 14:15:39 saturn sshd[29868]: Accepted password for dave from ::ffff:10.0.10.14 port 2833 ssh2 Nov 15 09:15:39 saturn sshd[29867]: Accepted password for dave from ::ffff:10.0.10.14 port 2833 ssh2 Nov 15 09:15:39 saturn sshd(pam_unix)[29869]: session opened for user dave by (uid=0)
That is, sshd appears to log the connection with GMT (or UCT) before the child sshd logs it with local time.
How do I either tell sshd to always use local time, or tell it not to make the first entry?
That is a bug. See http://bugs.centos.org/view.php?id=1557 and the RedHat bugzilla entry which is referenced in that bug report.
Cheers,
Ralph
David Mackintosh wrote:
Hi folks,
while chasing down a logging-related situation, I happened to notice that when I connect via ssh to my system it makes the
following logs:
Nov 15 14:15:39 saturn sshd[29868]: Accepted password for
dave from ::ffff:10.0.10.14 port 2833 ssh2
Nov 15 09:15:39 saturn sshd[29867]: Accepted password for
dave from ::ffff:10.0.10.14 port 2833 ssh2
Nov 15 09:15:39 saturn sshd(pam_unix)[29869]: session
opened for user dave by (uid=0)
That is, sshd appears to log the connection with GMT (or UCT) before the child sshd logs it with local time.
How do I either tell sshd to always use local time, or tell
it not to
make the first entry?
That is a bug. See http://bugs.centos.org/view.php?id=1557 and the RedHat bugzilla entry which is referenced in that bug report.
Cheers,
Ralph
A hard link between /var/empty/sshd/etc/localtime to /etc/localtime changes the timestamp, although two messages still get reported. The hard link should solve the issue brought up by some people in the redhat bugzilla discussion for this bug in which a mere copy would not solve the problem if /etc/localtime is actually changed. With the hard link, if /etc/localtime is changed, /var/empty/sshd/etc/localtime will see the change as well. I chose a hard link because I wasn't sure how a symbolic link would work in the chroot configuration (I did not test the symlink).
Thanks for reporting this as I've seen this issue for a few weeks now and didn't know how to solve it. Hopefully, the openssh patch discussed in redhat bugzilla will solve the "duplicate messages" issue.
Michael
-
David Mackintosh -
Michael Velez -
Ralph Angenendt -
Will McDonald