Bug 189158 - sshd logs 3 messages to /var/log/secure for every login
sshd logs 3 messages to /var/log/secure for every login
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
5
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-17 13:34 EDT by Jordan Russell
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-18 08:55:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jordan Russell 2006-04-17 13:34:46 EDT
Description of problem:
sshd logs 3 messages to /var/log/secure for every successful (publickey) login.

Version-Release number of selected component (if applicable):
openssh-4.3p2-4


How reproducible:
$ sshd root@somehost
[root@somehost ~]# tail /var/log/secure


Actual results:
Three log messages. Note that the first and third are in the wrong time zone
(GMT); the time on the second one is correct.

Apr 17 16:57:20 somehost sshd[13581]: Postponed publickey for root from
12.34.56.78 port 51395 ssh2
Apr 17 11:57:20 somehost sshd[13578]: Accepted publickey for root from
12.34.56.78 port 51395 ssh2
Apr 17 16:57:20 somehost sshd[13581]: Accepted publickey for root from
12.34.56.78 port 51395 ssh2


Expected results:
Just one log message, as in FC4 and prior versions:

Apr 17 11:57:20 somehost sshd[13578]: Accepted publickey for root from
12.34.56.78 port 51395 ssh2
Comment 1 Tomas Mraz 2006-04-18 08:55:56 EDT
The duplicate 'Accepted publickey' message will be hopefully resolved after
upgrade to a new upstream version as soon as it is released.

The 'Postponed publickey' message should be in logs so this is not a bug.

The wrong timezone problem is hard to solve because teh sshd process is running
in chroot where the /etc/localtime file is not accessible and simply copying it
into the chroot wouldn't be correct either as it would get out of sync whenever
the original one is changed.
Comment 2 Stuart 2006-05-08 07:20:25 EDT
Given the impact of timestamp problem (logs with inconsistent times are of 
questionable use, and that there still isn't an upstream release which 
addresses this), it is a reasonable short-term workaround to 
copy /etc/localtime to /var/empty/sshd/etc/localtime.

Note You need to log in before you can comment on or make changes to this bug.