Description of problem: Since the update of openssh to 3.9p1-8.RHEL4.15 (part of U4), I am seeing the following message pattern in /var/log/secure on RHEL4 machines whenever a user logs in via ssh: ==================== Aug 21 22:46:39 host1 sshd[16318]: Postponed publickey for root from ::ffff:a.b.c.d port 35647 ssh2 Aug 21 18:46:39 host1 sshd[16317]: Accepted publickey for root from ::ffff:a.b.c.d port 35647 ssh2 Aug 21 22:46:39 host1 sshd[16318]: Accepted publickey for root from ::ffff:a.b.c.d port 35647 ssh2 Aug 21 19:07:15 host1 sshd[19690]: Accepted password for userbob from ::ffff:a.b.c.d port 43561 ssh2 Aug 21 23:07:15 host1 sshd[19691]: Accepted password for userbob from ::ffff:a.b.c.d port 43561 ssh2 ==================== The 'actual' logins happened at 18:46 and 19:07 above. There is an additional entry for both the regular user and for root, which has a timestamp of +4 hours (GMT? I am in EDT). Also, only for root, there is a second additional entry which reports Postponed login. The ssh login has no issues in itself, but for these unwanted entries. A side-effect of this is that logwatch catches the Postponed authentication messages and reports them also as illegal login attempts. Version-Release number of selected component (if applicable): openssh-3.9p1-8.RHEL4.15 (on both server and client side) How reproducible: Always Steps to Reproduce: 1. Install openssh version 3.9p1-8.RHEL4.15, on both server and client side (with dependencies) 2. ssh from client to server 3. Observe additional entries in /var/log/secure on server Actual results: 2 entries for each successful login (one with +4 hours timestamp) for regular user. 3 entries for root. Expected results: 1 entry for each successful login, with correct timestamp Additional info:
This is a consequence of fixing a real bug in SSHD where it was not logging some failure messages when running in PrivilegeSeparation mode. The 'Postponed publickey' message is one of them. Logwatch should not report this as a login failure, this is a bug in logwatch and should be reported against it. The other two problems - wrong timestamp and duplicate messages are a real bug however low severity ones. The wrong timestamp is caused by /etc/localtime missing in /var/empty/sshd chroot. Workaround: you can copy it there from /etc.
*** Bug 204720 has been marked as a duplicate of this bug. ***
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
*** Bug 205528 has been marked as a duplicate of this bug. ***
I tried placing a copy of /etc/localtime into /var/empty/sshd/ and this did not work. However after looking at another bugzilla 1214 I found the solution to be to copy /etc/localtime to /var/empty/etc/. Here is the other bugzilla http://bugzilla.mindrot.org/show_bug.cgi?id=1214
(In reply to comment #1) > This is a consequence of fixing a real bug in SSHD where it was not logging some > failure messages when running in PrivilegeSeparation mode. The 'Postponed > publickey' message is one of them. Logwatch should not report this as a login > failure, this is a bug in logwatch and should be reported against it. > The 'Postponed publickey' message that I am getting is in response to a valid login not a failed attempt. It is, at best, a misleading message. To me it looks like that in the attempt to fix some other bug, a false negative got introduced into the process. > The other two problems - wrong timestamp and duplicate messages are a real bug > however low severity ones. > > The wrong timestamp is caused by /etc/localtime missing in /var/empty/sshd > chroot. Workaround: you can copy it there from /etc. > The wrong timestamp message is still there, even after copying /etc/localtime in /var/empty/sshd or /var/empty/etc/ (as reported by Charlie Wyse) and restarting sshd. Am I missing something here? -Neel
It should be /var/empty/sshd/etc/
Fixed in openssh-3.9p1-8.RHEL4.18
*** Bug 211821 has been marked as a duplicate of this bug. ***
*** Bug 212132 has been marked as a duplicate of this bug. ***
Please note that this is still an issue on x64 RHEL4.4 with openssh 3.9p1-8.RHEL4.17.1 (Install Date: Thu 16 Nov 2006), but not on i686 (3.9p1-8.RHEL4.17, Install Date: Fri Oct 6 2006) Actual results: Nov 20 13:55:24 host1 sshd[24706]: Accepted password for kindyjd from ::ffff:xxx.xxx.xxx.xxx port 32790 ssh2 Nov 20 08:55:24 host1 sshd[24705]: Accepted password for kindyjd from ::ffff:xxx.xxx.xxx.xxx port 32790 ssh2 Expected results: Nov 20 08:55:24 host1 sshd[24705]: Accepted password for kindyjd from ::ffff:xxx.xxx.xxx.xxx port 32790 ssh2
This bug hit me also. Is there timeframe for the release of openssh-3.9p1-8.RHEL4.18 available?
As of March 1, 2007, this is still release pending. Considering that consistent logs are a legal requirement for some people this isn't a "minor" problem. So, again, when can we expect this updated daemon release? (If the answer is: "you'll have to upgrade to RHEL 5 to get it," I'm sure there will be a lot of angry people out there....) Also, worthy of note, the machines I deal with that have this problem are i686, so it is still a problem there on 8.RHEL4.17.1.
I think the real fix for the problem is found in bug #231326, especially if you are considering the consistent-logs-as-a-potential-requirement issue.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2007-0257.html
cp -p /etc/localtime /var/empty/sshd/etc/ it is ok ?, so need restart sshd ?