Bug 101252 - update of openssh shows authentication failure in the message log
update of openssh shows authentication failure in the message log
Status: CLOSED DUPLICATE of bug 101157
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-07-30 10:07 EDT by Javier Rojas Balderrama
Modified: 2014-01-21 17:48 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-04 10:40:18 EST
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 Javier Rojas Balderrama 2003-07-30 10:07:36 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030708

Description of problem:
When you update the ssh components (client, askpass et. al.) through up2date
tool next time you try to login a message appears in the /var/log/messages:

 sshd(pam_unix)[20347]: authentication failure; logname= uid=0 euid=0
tty=NODEVssh ruser= rhost=xxxx  user=root

And then the process of login is normal. It means you can login and logut
succesfully.

This problem occurs with all the users.

Version-Release number of selected component (if applicable):
openssh-3.1p1-8

How reproducible:
Always

Steps to Reproduce:
1.up2date -u 
2.The package openssh is updated
3.ssh -l root mydomain.com
4

Actual Results:  A message "authentication failure" appears in /var/log/messages
but the connection to the system works.

Expected Results:  Connection to the system without that message like the
previous version of ssh.

Additional info:

kernel: 2.4.20-13.7bigmem
default configuration of pam and xinetd
Comment 1 Todd Allen 2003-07-30 13:35:42 EDT
I began seeing this same behavior on a RedHat 7.2 system, after installing
openssh-3.1p1-8.  The ssh connection and login is successful, and produces this
output in /var/log/messages:

Jul 30 13:12:48 themachine sshd(pam_unix)[1856]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=somewhere  user=someone
Jul 30 13:12:52 themachine sshd(pam_unix)[1856]: session opened for user someone
by (uid=0)
Jul 30 13:12:52 themachine sshd(pam_unix)[1856]: session closed for user someone

This is with kernel 2.4.20-19.7.

The /etc/ssh/sshd_config file had been changed as follows:
      X11Forwarding yes
      PasswordAuthentication yes
      ChallengeResponseAuthentication no
      PAMAuthenticationViaKbdInt no

This is a problem, because the /var/log/messages file has tons of false alarms,
and they will obscure any real failed login attempts.
Comment 2 Jordan Russell 2003-08-03 20:53:12 EDT
FYI, this was already reported in Bug #101157.
Comment 3 Ashley M. Kirchner 2003-08-05 06:06:24 EDT
I'm experiencing the same problem under both RH 7.3 as well as 8.0 after
updating all openssh packages to 3.1p1-8.
Comment 4 Bret Hughes 2003-08-07 23:48:52 EDT
FWIW I built openssh-3.6.1p2-1 from the src rpm from openssh.org and do not
experience the delay in a valid login or bogus auth. failed messages.  The delay
is bad enough for us since we uss ssh to run all sorts of commands remotely on a
growing likst of machines and 2 seconds adds up. but bogus error messages
regarding something as werious as authentication is absolutely unacceptable
IMNSHO.  

Natlin - please do not close this with NOTABUG as you did 101157.  There is
something seriouly wrong with the back port unless I am serioulsy missing
something which is entirely possible.  Red Hat may do something that is
difficult to incorporate but this need fixing or you will have a lot of users
backing this out.

Bret
Comment 5 Rajiv Manglani 2003-08-08 00:00:53 EDT
there is a link to a patch and more info at:
<http://bugs.gentoo.org/show_bug.cgi?id=20404>
Comment 6 Tomas Mraz 2005-02-04 10:40:18 EST

*** This bug has been marked as a duplicate of 101157 ***

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