Some users have experienced problems when reading data from a session after executing a command or starting a shell. The data output from stdout and stderr are merged into a single InputStream.

The Maverick API receives data and designates this to the stdout channel. If however stderr data exists the Maverick API should send this as extended data and call ChannelAdaptor::extendedDataReceived(SshChannel channel, byte[] buf, int off, int len, int type)if event based session has been implemented, or placed it into the stream returned by getStderrInputStream.

It seems the problem with stderr being received as stdout is caused by the server. From investigation connecting to a Linux server running version 3.9 of OpenSSH all stderr is received as stdout both when executing individual commands or when running the user's shell. On the same machine using the ssh.com Tectia server 4.0.2 the same behaviour is seen.

Ssh.com tectia server on Windows implementation works as expected with stderr data being received as extended data but using OpenSSH 3.9 within a Cygwin environment on Windows however does not work.

The problem lies with allocating a PseudoTerminal to the active session. This results in a different shell environment and places the process into an interactive shell which seems most likely to be the cause of the streams being merged. This can easily be resolved by not associating a PseudoTerminal with the session when executing commands.

This should allow the streams to come down separately.

NOTE: Many of the examples found on the Knowledge Base as well as part of the packaged examples associated with Maverick utilise PseudoTerminal but this is not always required in all situations.