Initialisation sequence blocking until idle timeout if no KexInit from client


I'm encountering the same problem with two ssh clients, cygwin and putty, where the first time they connect to the NSsh server it works ok but the second time the initialisation sequence only gets as far as VersionsExchangedState.Process.
What it looks like to my untrained eye is that the client can treat the KexInit packet as optional and if it has previously connected will assume the same settings are going to be used and skip straight to the KexDHInit packet. If that happens the VersionsExchangedState.KexInitPacket method never gets called, the TransportLayerManager.Parameters never gets initialised and the intialisation will block in VersionsExchangedState.Process until an idle timeout occurs.
I'm guessing the NSsh server should have some default values for the ecnryption, mac and compression algorithms that get used if no KexInit is received from the client?

file attachments

Closed Oct 15, 2009 at 11:41 PM by aaronc
Fixed by changing the ReadLine mechanism in TransportLayerManager.


aaronc wrote Sep 22, 2009 at 2:28 AM

The attached VersionsExchangedState.cs gets me past the KexInit phase and as far as NewKeys at which point my putty client pops up an error stating "Server's host key did not match the signature provided". That could be a consequence of the change I made in VersionsExchangedState.cs.

wrote Sep 22, 2009 at 2:28 AM

aaronc wrote Sep 22, 2009 at 2:32 AM

Actually looks like the server host key error is because NSsh is using a different public key on each startup which is undoubtedly becuase I don't have it configured correctly. If I start a new putty session the server host key error goes away. I can also restart the session and get to the login prompt which means the cludge I made to VersionsExchangesState.cs is working :).

tmyroadctfig wrote Oct 6, 2009 at 11:34 AM

I've added in your changes.

wrote Oct 15, 2009 at 11:41 PM

wrote Feb 13, 2013 at 10:01 PM

wrote May 16, 2013 at 3:43 AM