EldoS | Feel safer!

Software components for data protection, secure storage and transfer

TElSimpleSSHClient.Receive returns duplicate command promp

Posted: 12/23/2008 15:22:14
by William Wegerson (Basic support level)
Joined: 12/23/2008
Posts: 3

I recently installed latest version (6.1.150) of SecureBlackBox for SSH/SFTP and am getting a secondary command prompt when I use the TElSimpleSSHClient Recieve/ReceiveText method. Thinking it was in my code I went to the SimpleSSHDemoVS2008 and the demo version exhibits the same result; duplicate command prompts. I then went to putty and the duplicate command prompt does not occur.

What I am seeing is that after an initial result response, a secondary (ghost/mirror) command prompt is given by the software library. Here is a session copied from the SimpleSSHDemoVS2008 demo tool with the secondary prompt in bold:

Last login: Tue Dec 23 13:38:22 2008 from
* You are attempting to login to an XYZ computer. *
* Unauthorized use of this system is prohibited and may result in *
* revocation of access, disciplinary action and/or legal action. The *
* company reserves the right to monitor and review user activity, files *
* and electronic messages. *
* Reminder: Information transmitted to a foreign person on the network *
* may be subject to U.S. Export Control laws. Contact your Export *
* Coordinator for assistance. *

Sun Microsystems Inc. SunOS 5.10 Generic January 2005

[geft] ~ 101> ls -l

total 2
-rw-rw-r-- 1 bwegerso guest 6 Dec 23 13:45 only.txt

[geft] ~ 102> [geft] ~ 102> cd .ssh
[geft] ~/.ssh 103> [geft] ~/.ssh 103> ls -l

total 10

-rw------- 1 bwegerso guest 226 Dec 23 12:59 authorized_keys
-rw------- 1 bwegerso guest 1192 Dec 22 16:07 id-dsa
-rw-r--r-- 1 bwegerso guest 1115 Dec 22 16:07 id-dsa.pub

[geft] ~/.ssh 104> [geft] ~/.ssh 104>

Always after the 1st command a redundant prompt appears. The above shows that it is not a new prompt because the command numbering does not change.

Here are things of Note:

Password or keyfile usage results are the same.
Putty does not exhibit the problem
Using latest version of the ELDOS blackbox library.
Using VS2008 in C#.
The result of the operation is never duplicated, only the command prompt.

Please Advise,

Posted: 12/23/2008 15:36:03
by Mykola Olshevsky (Basic support level)
Joined: 07/07/2005
Posts: 442

Hi. As it is only an issue with command prompt (not the whole text), it seems, that it's just an issue with some escape sequences (which controls text behavior and appearance in terminal). To be sure, please catch binary data which is transferred to you, and take a look over it.
Posted: 12/23/2008 16:27:44
by William Wegerson (Basic support level)
Joined: 12/23/2008
Posts: 3

I modified the code in UnixSSH.cs in the SimpleSSHDemo_VS2008 project for the receive timer tick, which by the way already extracted from a buffer. I added a member variable previous to capture the previous timer tick contents. When a match occured it prints that out to the display as ** Duplicate : xxx ***.

Here is the code:

string previous;
private void timer_Tick(object sender, System.EventArgs e)
byte[] data = new byte[65280];
byte[] dataErr = new byte[65280];
int dataLen, dataErrLen;
string current;

dataLen = data.Length;
dataErrLen = dataErr.Length;
client.ReceiveData(ref data, ref dataLen, ref dataErr, ref dataErrLen);

current = System.Text.Encoding.UTF8.GetString(data, 0, dataLen);

if ( string.IsNullOrEmpty( current ) == false )
if ( previous == current )
tbView.Text += "** Duplicate: " + current + "***";
tbView.Text += current;
previous = current;

The result was this:

[geft] ~ 103> ** Duplicate: [geft] ~ 103> ***ls -l

total 2
-rw-rw-r-- 1 bwegerso guest 6 Dec 23 13:45 only.txt
[geft] ~ 104> ** Duplicate: [geft] ~ 104> ***

Therefore since duplicate was found on a subsequent timer tick, its not the buffer, which sits on the stack, but the call to ReceiveData which is returning the previous result.

Please advise
Posted: 12/24/2008 00:46:56
by Eugene Mayevski (Team)

The problem happens due to the CRLF sequence, sent by you after the command. The remote side interprets CRLF sequence as 2 separate end-of-line charaters. It executes the command followed by first end-of-line charater and shows the first prompt. Then it interprets the second end-of-line charater as an empty command and sends another prompt. This is not a bug. The solution is to know (ask the user or admin of the remote system) the expected EOL notation on the server and send the right character(s) after the command.

Sincerely yours
Eugene Mayevski
Posted: 12/24/2008 09:15:32
by William Wegerson (Basic support level)
Joined: 12/23/2008
Posts: 3

Oh....carriage return and line feed. :-) Ok, I understand the issue now.

I had reused your code in the example to send and it adds the CR LN to the data, hence the two sets of \r\n. So before sending, I strip out those bad boys if they appear and add the appropriate ending:

Data = Regex.Replace( Data, "([\r\n])", string.Empty, RegexOptions.Compiled );
byte[] encoded = System.Text.Encoding.UTF8.GetBytes( Data + "\x0d\x0a" );
_ssh.SendData( encoded, encoded.Length );

Thanks for your help!



Topic viewed 2378 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!