SSH-2.2.0 (for Windows) and OpenSSH-2.1.1p1

[Daniel Prevett]

Hi Jim,

The IETF documents that describe SSH2 have changed in regard to Public Key
Authentication.  I believe that they also made minor modifications to
disconnect messages but I am not sure.  SSH Communications 2.2.0 servers &
clients are using the new specifications for PKA.  I beleive that they
have a backwards compatibility mode for their own older servers, but it
doesn't surprise me that it doesn't work with OpenSSH.

The relevant documents (for anyone who's interested) are at:

http://www.ietf.org/html.charters/secsh-charter.html

The internet drafts are available from that page.

-Daniel 


On Wed, 28 Jun 2000, Jim Phillips wrote:

> I just upgraded my Windows SSH client from the 2.1.x version (whatever it
> was) to 2.2.0 and am now experiencing difficulties connecting to my
> OpenSSH-2.1.1p1 Linux servers.
> 
> I'm not as up-to-speed as I should be on the inner workings of the
> handshakes that go on, but from the debug logs and from trying different
> connection methods, it seems to be isolated to using publickeys.  This
> wouldn't surprise me.  I had to re-generate new keys after upgrading because
> 2.2.0 couldn't read my old 2.1.x public or private keys (that seems to have
> been that 2.2.x now uses Unix linefeeds instead of DOS linefeeds - it's the
> only difference between the two files that I can see).
> 
> So I re-generated the keypair, uploaded the public to my OpenSSH server via
> FTP.. Logged into the OpenSSH server from another Linux box with OpenSSH,
> ran ssh-keygen -x -f mynewkey.pub, appended the output to authorized_keys2,
> and tried to log in.  No such luck.
> 
> Below is the closest thing I could get to debug output out of the Windows
> client (unless someone knows a command line switch to get a debug log),
> followed by the log from my server..  Note that even though the reported
> client hostname is linux2.matrasystems.com, it's not really.. Just an
> IPmasqueraded connection.  Also, I get the same results no matter what
> cypher or algorithm I select from the client.  It does work using password
> authentication if I set the server to allow that..
> 
> This did work with SSH 2.1.x.  Anybody have any suggestions?
> 
> Client Troubleshooting Report
> =========================================================================
> SSH Windows Secure Shell Troubleshooting Report
> Generated on Wed Jun 28 2000 22:27:39
> 
> SSH Client version:
> 2.2.0 (Build 123)
> 
> License:
> Name: Jim Phillips
> Company: 
> Email: jphillips at ergonet-ent.com
> License Type: academic
> Number of Licenses: 1
> License Issued on: 2000-05-01
> License Expires on: <Non-Expiring>
> License Signature: C0CC 9864 9798 ABD6 CB38
> 
> Operating system:
> Microsoft Windows 2000 version 5.0  (Build 2195)
> 
> Remote host version:
> SSH-1.99-OpenSSH_2.1.1
> 
> Negotiated Algorithms:
> 
> 
> Connection Settings:
> Encryption Algorithm: <Default>
> MAC Algorithm: <Default>
> Compression: zlib
> Port Number: 4040
> Connect Through Firewall: No
> Firewall: (Empty)
> Firewall Port: 1080
> 
> Last 5 Messages displayed:
> Message 1:
> Server responded "too many failed userauth_requests".
> 
> A protocol error was detected.  This usually indicates a bug in the SSH
> application (either client or server).
> If you can repeatedly reproduce this problem, please send a detailed bug
> report (including version number and instructions for reproducing the
> problem) to ssh-bugs at ssh.fi.
> 
> Message 2:
> Authentication failed. Most likely the password you supplied was incorrect.
> The user name might also be wrong, or the account might be disabled.
> Please check your password and try again a few times.
> If this does not help, please contact the system administrator of the remote
> machine.
> 
> ========================================================
> Server Debug Log
> ========================================================
> debug: sshd version OpenSSH_2.1.1
> debug: Seeding random number generator
> debug: read DSA private key done
> debug: Seeding random number generator
> debug: Bind to port 4040 on 0.0.0.0.
> Server listening on 0.0.0.0 port 4040.
> Generating 768 bit RSA key.
> debug: Seeding random number generator
> debug: Seeding random number generator
> RSA key generation complete.
> debug: Server will not fork when running in debugging mode.
> Connection from 209.186.189.140 port 63337
> debug: Client protocol version 1.99; client software version 2.2.0 SSH
> Secure Shell for Windows
> datafellows: 2.2.0 SSH Secure Shell for Windows
> Enabling compatibility mode for protocol 2.0
> debug: Local version string SSH-1.99-OpenSSH_2.1.1
> debug: send KEXINIT
> debug: done
> debug: wait KEXINIT
> debug: got kexinit: diffie-hellman-group1-sha1
> debug: got kexinit: ssh-dss
> debug: got kexinit: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour
> debug: got kexinit: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour
> debug: got kexinit: hmac-md5,hmac-sha1
> debug: got kexinit: hmac-md5,hmac-sha1
> debug: got kexinit: zlib
> debug: got kexinit: zlib
> debug: got kexinit: 
> debug: got kexinit: 
> debug: first kex follow: 1 
> debug: reserved: 0 
> debug: done
> debug: kex: client->server 3des-cbc hmac-md5 zlib
> debug: kex: server->client 3des-cbc hmac-md5 zlib
> debug: Wait SSH2_MSG_KEXDH_INIT.
> debug: bits set: 518/1024
> debug: bits set: 495/1024
> debug: sig size 20 20
> debug: send SSH2_MSG_NEWKEYS.
> debug: Enabling compression at level 6.
> debug: done: send SSH2_MSG_NEWKEYS.
> debug: Wait SSH2_MSG_NEWKEYS.
> debug: GOT SSH2_MSG_NEWKEYS.
> debug: done: KEX2.
> debug: userauth-request for user jphillips service ssh-connection method
> none
> debug: Starting up PAM with username "jphillips"
> Failed none for jphillips from 209.186.189.140 port 63337 ssh2
> debug: userauth-request for user jphillips service ssh-connection method
> publickey
> debug: keytype ssh-dss
> debug: test key...
> debug: keytype ssh-dss
> debug: keytype ssh-dss
> debug: matching key found: file /home/jphillips/.ssh/authorized_keys2, line
> 2
> debug: PAM setting rhost to "linux2.matrasystems.com"
> Postponed publickey for jphillips from 209.186.189.140 port 63337 ssh2
> debug: userauth-request for user jphillips service ssh-connection method
> publickey
> debug: keytype ssh-dss
> debug: keytype ssh-dss
> debug: keytype ssh-dss
> debug: matching key found: file /home/jphillips/.ssh/authorized_keys2, line
> 2
> debug: len 55 datafellows 20
> debug: dsa_verify: signature incorrect
> Failed publickey for jphillips from 209.186.189.140 port 63337 ssh2
> debug: userauth-request for user jphillips service ssh-connection method
> password
> Failed password for jphillips from 209.186.189.140 port 63337 ssh2
> debug: userauth-request for user jphillips service ssh-connection method
> publickey
> debug: keytype ssh-dss
> debug: test key...
> debug: keytype ssh-dss
> debug: keytype ssh-dss
> debug: matching key found: file /home/jphillips/.ssh/authorized_keys2, line
> 2
> debug: PAM setting rhost to "linux2.matrasystems.com"
> Postponed publickey for jphillips from 209.186.189.140 port 63337 ssh2
> debug: compress outgoing: raw data 1033, compressed 559, factor 0.54
> debug: compress incoming: raw data 2200, compressed 665, factor 0.30
> Disconnecting: too many failed userauth_requests
> debug: Calling cleanup 0x804f260(0x0)
> debug: Calling cleanup 0x805f340(0x0)
> 
> 
> 
> 
> 
> Jim Phillips - Facilities Manager
> MATRA Systems, Inc.
> Phone: +1 (770) 931-0038 FAX: +1 (770) 931-3444 
> URL: http://www.matrasystems.com/ E-Mail: jphillips at matrasystems.com 
> We can fix this, but you're gonna need a butter knife, a roll of duct tape,
> and a car battery...