Bug 102221 - openssh erroneously reports authentication failures
Summary: openssh erroneously reports authentication failures
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: openssh
Version: 9
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-08-12 18:39 UTC by patrick charles
Modified: 2014-01-21 22:48 UTC (History)
5 users (show)

Fixed In Version: 3.5p1-11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-10-21 16:58:43 UTC
Embargoed:


Attachments (Terms of Use)

Description patrick charles 2003-08-12 18:39:07 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

Description of problem:

When a user successfully logs in via sshd using password authentication, sshd
reports an authentication failure in syslog.

For example:

hostname% tail -2 /var/log/messages
Aug 12 12:21:05 hostname sshd(pam_unix)[15433]: authentication failure; logname=
uid=0 euid=0 tty=NODEVssh ruser= rhost=fission.creek.foo  user=username
Aug 12 12:21:14 hostname sshd(pam_unix)[15435]: session opened for user username
by (uid=500)



Version-Release number of selected component (if applicable):
openssh-3.5p1-6.9

How reproducible:
Always

Steps to Reproduce:
1. ssh to a system running the opensshd patched for errata RHSA-2003-222
2. login successfully
3. on the target system, tail /var/log/messages
4. note that sshd/pam reported to syslog 'authentication failure'
    

Actual Results:  /var/log/messages contains an authentication failure log entry
despite the fact that the sshd authentication was successful.


Expected Results:  /var/log/messages should only contain a success entry from
sshd of the form 'sshd(pam_unix)[00000]: session opened for user username by
(uid=000)'

Additional info:

This bug is reproduceable on any version of Red Hat Linux which was patched for
this errata, including openssh for RedHat 7.1, Red Hat 7.2, Red Hat 7.3, Red Hat
8.0, Red Hat 9.0

This bug is not a duplicate of 101662 or 101157.

Those bugs are similar but took issue with login time which is arguably not a 'bug'.

This bug addresses the authentication failure log entry emmanating form sshd/pam
which is clearly not valid when sshd password authentication was successful.

This problem, and the resulting alerts triggered by programs like logwatch which
scan for authentication failures, is causing many customers to revert to
previous versions of the openssh product.

Comment 1 Mircea Damian 2003-08-17 13:28:05 UTC
Anyone found a fix for that? Why is so silence around this important issue?

My logwatcher is flooding me with false errors since that it became useless 
regarding ssh authentication errors.



Comment 2 Jenny Aquilino 2003-09-04 23:47:22 UTC
I too am very interested to see this problem fixed.  I am wondering if it is
actually an issue with PAM though.  I've included several key files for PAM in
the hope that maybe I just have something misconfigured. I am running Redhat 8.0
 using openssh-3.4p1-4.  I did not have this problem when I was running
openssh-3.4p1-2.  I am also trying to figure out why successful logins are not
recorderd even though my /etc/syslog.conf file logs auth.info and authpriv.info.
 Thanks in advance for any information on this. -Jenny =)

Here is my /etc/pam.d/sshd file:
#%PAM-1.0
auth       required     /lib/security/pam_stack.so service=system-auth
auth       required     /lib/security/pam_nologin.so
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_limits.so
session    optional     /lib/security/pam_console.so

Here is my /etc/pam.d/system-auth file:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/pam_env.so
auth        sufficient    /lib/security/pam_unix.so likeauth nullok
auth        required      /lib/security/pam_deny.so

account     required      /lib/security/pam_unix.so

password    required      /lib/security/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/pam_unix.so nullok use_authtok shadow nis
password    required      /lib/security/pam_deny.so

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so


Comment 3 patrick charles 2003-10-21 16:58:43 UTC
This bug is fixed in 3.5p1-11 on RH9 and 3.1p1-14 on RH7.2 
 
 

Comment 4 Mace Moneta 2003-10-21 17:47:33 UTC
I don't think so:

# cat /etc/redhat-release 
Red Hat Linux release 9 (Shrike)

# rpm -q openssh
openssh-3.5p1-11

# service sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]

[start ssh session to system, password login, no error]

==> /var/log/linksys.log <==
Oct 21 13:42:03 systemname sshd(pam_unix)[16598]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=buggsb.moneta.optonline.net 
user=mmoneta




Comment 5 Damian Menscher 2003-10-21 17:53:49 UTC
It's fixed for the SSH2 protocol.  It is not fixed for the SSH1 protocol.  But 
if you're still using SSH1, you have other problems anyway....

Comment 6 Mace Moneta 2003-10-21 18:14:07 UTC
It doesn't appear fixed to me at all.

System "buggsb force SSH2, just in case":
$ ssh -2 mmoneta@mmouse

System "mmouse":
==> /var/log/messages <==
Oct 21 14:10:00 mmouse sshd(pam_unix)[20223]: authentication failure; logname= u
id=0 euid=0 tty=NODEVssh ruser= rhost=buggsb.moneta.optonline.net  user=mmoneta



Comment 7 patrick charles 2003-10-21 18:52:56 UTC
 
I have Red Hat 7.2, Red Hat 8.0, and Red Hat 9 machines subscribed to RHN. 
 
Since the advisory RHSA-2003:279-17 and applying the OpenSSH errata released 
September 17th, 2003, the 'authentication failure' behavior has disappeared. 
 
I have tested successfully on Red Hat 7.2 (openssh-3.1p1-14), Red Hat 8.0 
(openssh-3.4p1-7), and Red Hat 9 (openssh-3.5p1-11). 
 
I am ONLY using SSH2 protocol. 
 
If it is still broken for SSH1, we could reopen this bug, or post a new one. 
 
This bug remained in 'NEW' Status for almost two months and wasn't acknowledged.  
 
 


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