SSH sends sends key exchange packets too early

[crane]

Normaly an SSH connection should go this way:

1. Clients wants to connect
2. Server returns protocol/version
3. Clients sends a request for key exchange
4. Server sends keys (diffie-helman protocol)

Now in Conch SSH the server sends the keys without beeing asked:

1. Clients wants to connect
2. Server returns protocol/version
3. Server sends keys (diffie-helman protocol)
and now it's messed up.

[exarkun]

Thanks. The regular-releases milestone is for release automation.

Also, can you please provide a link to the RFC that outlines the behavior you described? Thanks again.

[crane]

Patch for this Bug

[crane]

I will have a look into the RFC at the weekend... So long I added a patch to the ticket.

I tested it already in my enviroment and it works fine. :)

[z3p]

Thanks for the patch! What's getting messed up by sending the kexInit() early?

[crane]

Replying to exarkun:

Also, can you please provide a link to the RFC that outlines the behavior you described? Thanks again.

 http://www.ietf.org/rfc/rfc4419.txt Have a look onto Part 3 of the RFC

Replying to z3p:

What's getting messed up by sending the kexInit() early?

It's not realy broken but you can determinite with a simple telnet (it's also already included by nmap and metasploit) that you're running a twisted application.

Try it on your own by just telnet'ing your ssh app. You will get after the Version String a complete list of ciphers.

[z3p]

Replying to crane:

Replying to exarkun:

Also, can you please provide a link to the RFC that outlines the behavior you described? Thanks again.

 http://www.ietf.org/rfc/rfc4419.txt Have a look onto Part 3 of the RFC

Part 3 of that RFC specifies that the KEXINIT from the server has already been sent. The transport-layer RFC is  http://tools.ietf.org/html/rfc4253, and I didn't see anything saying that the server needs to wait for the client.

Replying to z3p:

What's getting messed up by sending the kexInit() early?

It's not realy broken but you can determinite with a simple telnet (it's also already included by nmap and metasploit) that you're running a twisted application.

You can also tell because we send 'Twisted' as part of the SSHv2 version string.

[crane]

Hey ho,

I figured it out finally. RFC 4253#section-5 is talking about SSHv1 and SSHv2 and the support for both. If you have a look onto 5.1 (Old Client, New Server) you will find this:

---

[...]When compatibility with old clients is not needed, the server MAY send its initial key exchange data immediately after the identification string.

---

So this is not realy bug. It's a may condition which I did not knew. But it would be nice if Twisted is handling the key exchange like OpenSSH. :)

[exarkun]

Thanks. It sounds like this ticket should be closed, since Conch is an SSHv2 implementation, not an SSHv1 implementation. Alternatively, perhaps there could be a setting in the implementation that can be toggled to enable this particular bit of SSHv1 compatibility - but I think it should be off by default, since it introduces additional latency into the connection setup.

[exarkun]

Okay, we'll go that route. Please feel free to open if any new information or perspectives surface! Thanks again.

[exarkun]

This seems to be a duplicate of #5409.