Bug 23877 - sshd leaks username information to remote clients
sshd leaks username information to remote clients
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Florence Beta-3
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-12 10:35 EST by Tim Waugh
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-01-18 00:04:47 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 Tim Waugh 2001-01-12 10:35:05 EST
On a beta2 ssh server with users 'fred' and 'root', I see the following behaviour from a beta1 client:

$ ssh fred@server
Enter passphrase for DSA key '/home/twaugh/.ssh/id_dsa':
Password:
Password:
Received disconnect: 2: too many failed userauth_requests

(I don't know the password)

$ ssh madeupname@server
Enter passphrase for DSA key '/home/twaugh/.ssh/id_dsa':
Connection closed by 172.16.10.45

Eek!  Now I know that 'fred' is an allowed user on the server!

It _ought_ to ask me for my password regardless of whether the user exists or not.
Comment 1 Pekka Savola 2001-01-12 15:30:22 EST
Hmm, how exactly did you do this?  Was ssh-agent concerned?

SSH beta2 -> beta2 goes:

* first, generate a DSA key with passphrase, insert it in authorized_keys2.
* root is the real acct

root@install5 .ssh]# ssh root@install5
Enter passphrase for DSA key '/root/.ssh/id_dsa': 
root@install5's password: 
Permission denied, please try again.
root@install5's password: 
Permission denied, please try again.
root@install5's password: 
Unable to find an authentication method

[root@install5 .ssh]# ssh blarg@install5    
Enter passphrase for DSA key '/root/.ssh/id_dsa': 
blarg@install5's password: 
Permission denied, please try again.
blarg@install5's password: 
Permission denied, please try again.
blarg@install5's password: 
Unable to find an authentication method

Or did you try this some other way?
Comment 2 Tim Waugh 2001-01-12 17:41:36 EST
Here's a localhost-only how-to-repeat:

[root@cocobean /root]# ls .ssh
ls: .ssh: No such file or directory
[root@cocobean /root]# finger fred
finger: fred: no such user.
[root@cocobean /root]# rpm --verify openssh-server openssh
[root@cocobean /root]# rpm -q openssh-server openssh
openssh-server-2.3.0p1-9
openssh-2.3.0p1-9
[root@cocobean /root]# service sshd status
sshd (pid 871 453) is running...
[root@cocobean /root]# ssh fred@localhost
Connection closed by 127.0.0.1
[root@cocobean /root]# useradd tim
[root@cocobean /root]# ssh tim@localhost
Password: 

This is reproducible on all machines I've installed beta1/beta2 on now (three of them).
Comment 3 Pekka Savola 2001-01-12 18:32:46 EST
Ok, RH patch openssh-2.3.0p1-auth2-pam.patch is at fault (at least) here.  If you disable KbdInteractiveAuthentication, 
this doesn't happen anymore.



Comment 4 Pekka Savola 2001-01-12 19:03:35 EST
Note: it'd appear that OpenSSH CVS snapshots (http://bass.directhit.com/openssh_snap/) 
have this fixed, probably since Dec 20.
Comment 5 Glen Foster 2001-01-15 16:46:49 EST
This defect is considered MUST-FIX for Florence Beta-3
Comment 6 Nalin Dahyabhai 2001-01-18 02:15:07 EST
Hey, that's a bug in auth2-pam.c.  Fixed in openssh-2.3.0p1-10.

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