some devices do not permit connection sharing

Nobody has claimed this yet.

Ex: Cisco NCS 5500 64bit

Some devices we use Robot with do not permit connection sharing as replicated via OpenSSH client https://unix.stackexchange.com/questions/33557/using-an-already-established-ssh-channel

As SSHLibrary makes use by sub-channeling the already established ssh connection via the `Execute Command` directive in an effort to improve speed, on the NCS 5500 (which i suspect this is actually a bug Cisco needs to address, as this works flawlessly on all other Cisco devices), the end result is we are able to open the second channel and run our command but on exit it causes the primary channel to also close.

While support for SSH Channeling is outlined by rfc4254 5.x and loosely supported by the NCS 5500 64bit, the handling of the Channel closure causes the session to close prior to the initial channel closing is in direct conflict with rfc4254 5.3

I am creating this issue to handle the following: to determine if there is any interest in having a mechanism for disabling the use of multiple channels, and to make all aware of this odd issue.

`Write` and `Read Until` functions are possible up until a `Execute Command` is ran which returns the CLI output as well as an EOF error. All future SSH operations will fail.

Start by locating the SSHLibrary implementation of the `Execute Command` directive and its multiple-channel handling, then reproduce the failure described for Cisco NCS 5500 64bit. Done means determining whether disabling connection sharing is feasible and documenting or implementing a mechanism that preserves the primary channel after command execution.

Written by the indexing model from the issue text.