diffie-hellman ssh keyxchange

I've set out to make a primitive SSH client in C#; you might remember me from posts such as primitive ssh connection (lowlevel) hehe.

Anyway, things are great up until the time when I initiate a DH key exchange. I've compared the traffic when I establish a ssh connection (from openssh client to openssh server), to the traffic when my client connects to the same openssh server.

OpenSSH client -> OpenSSH server (S for server, C for client): S: SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2\r (saying hello) C: SSH-2.0-OpenSSH_5.2\r (introducing myself) C: Key Exchange Init (0x14 = 20) S: Key开发者_如何学运维 Exchange Init C: Diffie-Hellman GEX Request (0x22 = 34) (with DH GEX min, number of bits and max) S: Diffie-Hellman Key Exchange Reply (with P, G, etc.) C: Diffie-Hellman GEX Init S: Diffie-Hellman GEX Reply

My client -> OpenSSH server: S: SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2\r (saying hello) C: SSH-2.0-Some_Name\r (introducing myself) C: Key Exchange Init (0x14 = 20) S: Key Exchange Init C: Diffie-Hellman GEX Request (0x22 = 34) (with DH GEX min, number of bits and max)

and then a bogus TCP packet as reply (probably the server connection has been terminated after/upon GEX Request.

I have yet to use AES128 (which I think is the encryption chosen, but I'm not sure how to verify this...), and I'm still sending in a non-compressed format, looking to get the P, G etc. values to make the DH calculations.

So where I'm stranded is: RFC 4419 page 3 http://www.ietf.org/rfc/rfc4419.txt I've send SSH_MSG_KEY_DH_GEX_REQUEST, but the server does not respond SSH_MSG_KEX_DH_GEX_GROUP.

Can anyone give me a little advice on what I'm not understanding here? Does the server not understand my GEX request (due to it expecting encryption, or?)?

Any help is very much appreciated, thanks :)

I'm pretty sure the problem is that after the key exchange init, the keys aren't being taking into (correct) use.

My best guess would be that the key exchange are mutually exclusive, i.e. the openssh server does not have the algorithm that the client is looking for or the client does not have the algorithm to exchange with the openssh server. You could verify it by running wireshark on the putty to openssh server and monitor the exchanges and compare it with your own client.

I would gauge a guess that is how putty works, if the exchange fails, fall back to another algorithm after 'querying the openssh server' for the algorithm it uses... since putty is open source, it might be worth your while to look at the code to see how putty accomplishes it.