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...