Bug 55207 - openssh-2.9p2-8.7 breaks RSA Authentication with previous versions
openssh-2.9p2-8.7 breaks RSA Authentication with previous versions
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Tomas Mraz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-27 01:59 EDT by Need Real Name
Modified: 2007-04-18 12:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-03 04:52:45 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 Need Real Name 2001-10-27 01:59:41 EDT
Description of Problem:
openssh-2.9p2-8.7 breaks RSA/DSA authentication with previous versions of
ssh.  I updated to the above ssh on my workstation, and afterword, the only
authentication that would work when I sshed to the other machines on my
network is password authentication.  None of the other machines have
changed.  Everything had been working fine until I 'upgraded' to Redhat's
latest for 7.1.  None of my authorized_keys, identity, or identity.pub
files had changed.  I tried regenerating my private/public keypairs using
rsa and dsa, and distributing my new public keys to the authorized_keys
files on my other machines.  RSA/DSA authentication still does not work. 
Somehow, you guys made it so that the only authentication other servers
could use with this client, it password authentication.

Version-Release number of selected component (if applicable):
openssh-2.9p2-8.7

How Reproducible:
Everytime

Steps to Reproduce:
From the workstation with openssh-2.9p2-8.7, ssh to a server with
openssh-2.5.2p2-1
1. ssh me@remote.machine
	
Actual Results:
Get a login/password prompt

Expected Results:
Be logged in and presented with a shell prompt without having to enter a
password

Additional Information:
ssh from the remote machine back to my workstation works fine with RSA
authentication.  It's the new ssh client which is screwed up and doesn't
work with other ssh servers w/RSA authentication.

Here is the sshd_config on my *remote* machine. This is what has been
working quite well until I upgraded openssh on my local machine. Note that
if I set "PasswordAuthentication no", I cannot ssh to the machine at all from 
openssh-2.9p2-8.7.  All my other machines work correctly when sshing
amongst them.  It's only this one client with RedHat's latest 7.1 openssh
release that is borked.

Port 22
Protocol 1,2
HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin yes
IgnoreRhosts yes
StrictModes yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
KeepAlive yes
SyslogFacility AUTH
LogLevel INFO

RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords yes
ChallengeResponseAuthentication no

MaxStartups 10:30:60
Banner /etc/issue.net
ReverseMappingCheck yes

Subsystem       sftp    /usr/libexec/openssh/sftp-server

I ran sshd on the remote machine in debug mode.  Here's the output from the
debug session.

debug1: Seeding random number generator
debug1: sshd version OpenSSH_2.5.2p2
debug1: load_private_key_autodetect: type 0 RSA1
debug1: load_private_key_autodetect: type 0 RSA1
debug1: read SSH2 private key done: name dsa w/o comment success 1
debug1: load_private_key_autodetect: type 2 DSA
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging mode.
Connection from 192.168.1.25 port 38313
debug1: Client protocol version 2.0; client software version OpenSSH_2.9p2
debug1: match: OpenSSH_2.9p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_2.5.2p2
debug1: Rhosts Authentication disabled, originating port not trusted.
debug1: list_hostkey_types: ssh-dss
debug1: send KEXINIT
debug1: done
debug1: wait KEXINIT
debug1: got kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug1: got kexinit: ssh-rsa,ssh-dss
debug1: got kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se
debug1: got kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se
debug1: got kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug1: got kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug1: got kexinit: none
debug1: got kexinit: none
debug1: got kexinit: 
debug1: got kexinit: 
debug1: first kex follow: 0 
debug1: reserved: 0 
debug1: done
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST.
debug1: Sending SSH2_MSG_KEX_DH_GEX_GROUP.
debug1: dh_gen_key: priv key bits set: 126/256
debug1: bits set: 1035/2049
debug1: Wait SSH2_MSG_KEX_DH_GEX_INIT.
debug1: bits set: 1015/2049
debug1: sig size 20 20
debug1: send SSH2_MSG_NEWKEYS.
debug1: done: send SSH2_MSG_NEWKEYS.
debug1: Wait SSH2_MSG_NEWKEYS.
debug1: GOT SSH2_MSG_NEWKEYS.
debug1: done: KEX2.
debug1: userauth-request for user me2v service ssh-connection method none
debug1: attempt 0 failures 0
debug2: input_userauth_request: setting up authctxt for me2v
debug1: Starting up PAM with username "me2v"
debug1: Trying to reverse map address 192.168.1.25.
debug1: PAM setting rhost to "reliant.home.pri"
debug2: input_userauth_request: try method none
debug1: userauth_banner: sent
debug1: PAM Password authentication for "me2v" failed[7]: Authentication
failure
Failed none for me2v from 192.168.1.25 port 38313 ssh2
debug1: userauth-request for user me2v service ssh-connection method password
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method password
debug1: PAM Password authentication for "me2v" failed[7]: Authentication
failure
Failed password for me2v from 192.168.1.25 port 38313 ssh2
debug1: userauth-request for user me2v service ssh-connection method password
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method password
debug1: PAM Password authentication accepted for user "me2v"
Accepted password for me2v from 192.168.1.25 port 38313 ssh2
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 32768 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug2: callback start
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 channel 0 request pty-req reply 0
debug1: session_pty_req: session 0 alloc /dev/pts/2
debug2: callback done
debug2: callback start
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 channel 0 request x11-req reply 0
debug1: Received request for X11 forwarding with auth spoofing.
debug1: bind port 6010: Address already in use
debug1: fd 8 setting O_NONBLOCK
debug1: fd 8 IS O_NONBLOCK
debug1: channel 1: new [X11 inet listener]
debug2: callback done
debug2: callback start
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 channel 0 request shell reply 0
debug1: PAM setting tty to "/dev/pts/2"
debug1: PAM establishing creds
debug1: channel 0: rfd 7 isatty
debug1: fd 7 setting O_NONBLOCK
debug1: fd 3 IS O_NONBLOCK
debug2: callback done
debug1: Setting controlling tty using TIOCSCTTY.
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 10484
debug1: session_exit_message: session 0 channel 0 pid 10484
debug1: session_exit_message: release channel 0
debug1: channel 0: write failed
debug1: channel 0: output open -> closed
debug1: channel 0: close_write
debug1: session_pty_cleanup: session 0 release /dev/pts/2
debug1: session_free: session 0 pid 10484
debug1: channel 0: read<=0 rfd 7 len -1
debug1: channel 0: read failed
debug1: channel 0: input open -> drain
debug1: channel 0: close_read
debug1: channel 0: input: no drain shortcut
debug1: channel 0: ibuf empty
debug1: channel 0: input drain -> closed
debug1: channel 0: send eof
debug1: channel 0: send close
debug2: channel 0: no data after CLOSE
debug2: channel 0: no data after CLOSE
debug1: channel 0: rcvd close
debug2: channel 0: no data after CLOSE
debug1: channel 0: is dead
debug1: channel_free: channel 0: status: The following connections are open:
  #0 server-session (t4 r0 i8/0 o128/0 fd -1/-1)

Connection closed by remote host.
debug1: Calling cleanup 0x80562f0(0x8085120)
debug1: xauthfile_cleanup_proc called
debug1: Calling cleanup 0x805cf30(0x0)
debug1: channel_free: channel 1: status: The following connections are open:

debug1: Calling cleanup 0x80517a0(0x0)
debug1: Calling cleanup 0x8063a08(0x0)
Comment 1 Need Real Name 2001-10-27 12:19:27 EDT
It appears that the new ssh client automatically requires ssh2 authentication
methods (e.g., DSA, etc), and tells the remote server to use ssh2 key pairs, and
will not fall back to ssh key pairs (even if those are the only available key
pairs).  What should happen is, if I only have identity/identity.pub (ssh v1) in
my local ~/.ssh, and in remote I have ~/.ssh/authorized_keys with my
identity.pub key in it, the ssh client should be telling the server to use the
identity key.  This does not appear to be happening, because the server drops
down to password authentitcation.
Comment 2 Tomas Mraz 2005-02-03 04:52:45 EST
You should use the -1 option. And openssh-2.9 isn't anymore supported
for a long time anyway.

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