Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 432642

Summary: When authorized_keys is incorrect, sshd avoids other authentication methods, including password.
Product: Red Hat Enterprise Linux 4 Reporter: Jan Pazdziora (Red Hat) <jpazdziora>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: low    
Version: 4.6   
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2008-0709 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-07-24 19:53:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Server log with broken authorized_keys.
none
Server log with correct authorized_keys.
none
Output with broken authorized_keys.
none
Output with correct authorized_keys. none

Description Jan Pazdziora (Red Hat) 2008-02-13 15:39:47 UTC 
Description of problem:

Have a system with sshd running, log in to that system via password. Then put
some data into authorized_keys. Make sure the data is broken, for example
truncated DSA key. Try to log in to that machine. Your ssh will not log in to
the server using your key, and it won't even allow you to enter the password.

Version-Release number of selected component (if applicable):

# rpm -q openssh-server
openssh-server-3.9p1-8.RHEL4.24

How reproducible:

Deterministic.

Steps to Reproduce:
1. Have a client and a server with sshd on RHEL 4.
2. Try that you are able to log in to root on that machine with your password.
3. Generate DSA key on you client, put it into ~/.ssh/authorized_keys on the
server, chmod that authorized_keys.
4. Make sure you are able to log in to that server using ssh -i
/path/to/that/private/key and that the server does not want a password.
5. Now corrupt the data in authorized_keys. For example, go to the key you've
just enterred and hit Enter somewhere in the middle of the line.
  
Actual results:

You won't be able to log in to the machine with your key, and you won't be
prompted for the password either.

Expected results:

You should still be able to log in with a password.

Additional info:
Comment 1 Jan Pazdziora (Red Hat) 2008-02-13 15:47:49 UTC 
Created attachment 294797 [details]
Server log with broken authorized_keys.

With authorized_keys with DSA broken into two lines, I get the server log in
attachment and the following from ssh -v:

$ ssh -v -i ~/.ssh/test1 root@vmware166
OpenSSH_4.7p1, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /home/adelton/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to vmware166 [10.34.34.166] port 22.
debug1: Connection established.
debug1: identity file /home/adelton/.ssh/test1 type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'vmware166' is known and matches the RSA host key.
debug1: Found key in /home/adelton/.ssh/known_hosts:195
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/adelton/.ssh/test1
Connection closed by 10.34.34.166
$
Comment 2 Jan Pazdziora (Red Hat) 2008-02-13 15:48:56 UTC 
Created attachment 294798 [details]
Server log with correct authorized_keys.

With correct authorized_keys, I get logged in correctly:

$ ssh -v -i ~/.ssh/test1 root@vmware166
OpenSSH_4.7p1, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /home/adelton/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to vmware166 [10.34.34.166] port 22.
debug1: Connection established.
debug1: identity file /home/adelton/.ssh/test1 type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'vmware166' is known and matches the RSA host key.
debug1: Found key in /home/adelton/.ssh/known_hosts:195
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/adelton/.ssh/test1
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Remote: No xauth program; cannot forward with spoofing.
Last login: Wed Feb 13 16:43:15 2008

RHN kickstart on 2008-02-13

Environment:
  USER=root
  LOGNAME=root
  HOME=/root
  PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
  MAIL=/var/mail/root
  SHELL=/bin/bash
  SSH_CLIENT=::ffff:10.34.32.41 40814 22
  SSH_CONNECTION=::ffff:10.34.32.41 40814 ::ffff:10.34.34.166 22
  SSH_TTY=/dev/pts/0
  TERM=xterm
# logout
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to vmware166 closed.
debug1: Transferred: stdin 0, stdout 0, stderr 33 bytes in 8.9 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 3.7
debug1: Exit status 0
$
Comment 3 Jan Pazdziora (Red Hat) 2008-02-13 15:53:05 UTC 
The problem does not seem to be present on RHEL 5 with

# rpm -q openssh-server
openssh-server-4.3p2-24.el5
Comment 4 RHEL Program Management 2008-02-13 15:58:09 UTC 
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.
Comment 5 Tomas Mraz 2008-02-13 16:07:41 UTC 
Ah sorry, the server logs are truncated. Please use /usr/sbin/sshd -D -ddd to
generate them.
Comment 6 Jan Pazdziora (Red Hat) 2008-02-14 07:45:44 UTC 
(In reply to comment #5)
> Ah sorry, the server logs are truncated. Please use /usr/sbin/sshd -D -ddd to
> generate them.

The output is exactly the same. Umm, you mean sshd -e -ddd. Will attach.
Comment 7 Jan Pazdziora (Red Hat) 2008-02-14 07:46:16 UTC 
Created attachment 294897 [details]
Output with broken authorized_keys.
Comment 8 Jan Pazdziora (Red Hat) 2008-02-14 07:46:48 UTC 
Created attachment 294898 [details]
Output with correct authorized_keys.
Comment 13 errata-xmlrpc 2008-07-24 19:53:50 UTC 
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 therefore 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/RHBA-2008-0709.html