This is a small fix for the following bug: If SSH client and server negotiate 'none' as the key-exchange algorithm, that also implies no encryption and no authentication following key-exchange. Then when either side receives a channel open request, it will be rejected because the internal SSH connection service was not activated. Normally the connection service does not get activated until successful authentication, because in a secure session no channels are allowed to be opened until then.
The MultiChannelStream always disables key-exchange; it is able to connect because internally it explicitly activates the connection service. This bug deals with use of SshSession classes with 'nonekey-exchange algorithm _without_MultiChannelStream`. In that case there was no way to explicitly activate the connection service because it isn't public.
This is a small fix for the following bug: If SSH client and server negotiate 'none' as the key-exchange algorithm, that also implies no encryption and no authentication following key-exchange. Then when either side receives a channel open request, it will be rejected because the internal SSH connection service was not activated. Normally the connection service does not get activated until successful authentication, because in a secure session no channels are allowed to be opened until then.
The
MultiChannelStreamalways disables key-exchange; it is able to connect because internally it explicitly activates the connection service. This bug deals with use ofSshSessionclasses with 'nonekey-exchange algorithm _without_MultiChannelStream`. In that case there was no way to explicitly activate the connection service because it isn't public.