Telnet through SSH port

[RLD]

The knowledge base paper on using SSH TCP says that port forwarding with PuTTY can be used to enable a Telnet application to communicate through the SSH port.  I can configure PuTTY to communicate with our Linux based UUT, but I'm having trouble modifying our LabVIEW Telnet app to automatically communicate through the UUT's SSH port.

Using the LabVIEW Internet Toolkit "Telenet Line Client.vi" as an example, what are the modifications and configurations needed to make the app use the SSH port (#22) instead of the usual Telnet port (#23)?  I've tried using both PuTTY and plink (invoked using System Exec.vi), but have not yet found the magic words to make either work.

The test station computer has a dedicated NIC which connects directly to the UUT's Ethernet connector, so security within the test station computer is not an issue.  Using the -l and -pw plink switches to pass in the loginname and password would be a great if I could make it work.

[Chris_Cilino]

RLD,

According to Using SSH TCP Communications Protocol With NI Software you can simply use TCP to transimitt your information to a port that PuTTY is listening on. You specify whith port to write to by using the "TCP Open Connection.vi" and specifying the port of interest ing the "Remote Port" input.

To use Telnet, simply change the "Remote Port" parameter on the "Telnet Open Connection.vi" to match the port PuTTY is listening on.

Let us know if you'd like further clarificaiton.

Chris C

[RLD]

Chris,

I've read the referenced document many times (along with other resources readily avialable on the web).  Have you actually tried using PuTTY with a LabVIEW app???

Rich

[Chris_Cilino]

RLD,

Actually I never have tried this, but would still like to try and help out. I understand that you can pass PuTTY data through the command line and so I would recommend using the DOS prompt initially to test out your syntax and commands. Once you verify the syntax, then use the system exec.vi in LabVIEW to programmatically pass the commands to PuTTY.

So I guess my question is, have you been able to successfully pass PuTTY command line arguments? Post to let us know.

Chris C

[RLD]

I've been using plink the command line function to set up the PuTTY session:

plink -pw mypswd -L 4200:192.168.0.1:22 root@192.168.0.1

meaning all traffic on the test station computer's 4200 port (can be any big port number you'd prefer) is forwarded to port 22 (the SSH port) on the server/host/uut, and visa versa.  The password is included for convenience and since this is all within the test environment, security is not an issue.

Now the here's the problem, when I setup the Telnet client, (configured with address "localhost", port 4200) all that happens is the SSH server sends back the string "SSH-2 0-dropbear_0.47" and there are no further transactions.  BTW, dropbear is the particular SSH server that the UUT is using.  I get the same response whether I use the Internet Toolkit Telnet Client VI or the LabVIEW example TCP client.  I've tried to configure a terminal app to communicate on the forwarded port, but so far haven't gotten that to work either.

[Janne-_-]

Hello,


It's over year since last post to this thread but, has anyone figured this one out yet? I am havin this same problem atm, I am not able to send any ssh commands using TCP Communicator - Active. I tried to send ping command so i would visually see ETH led blinking after sending the command but it only blinked once, (when i send the same command using Putty i t keeps blinking until i ^C). And only response i get to LV is SSH-2.0-dropbear_0.48.

I have searched the forums without any conclusion to this problem.

Even from NI support i only recived link to this page: http://digital.ni.com/public.nsf/websearch/C49602A79827DDBE86256CE9005757D5?OpenDocument 

My goal is to send SSH commands to server which is running on device under test, and get the response to LV.



-Janne

[RLD]

Janne,

The SSH/LabVIEW problem that I've had has not been resolved.  The work around has been to use the Telnet server.  In our application PuTTY works fine when manually sending commands via the SSH server, we just cannot automate the process with LabVIEW.

The only clue that I've picked up is that there might be some conflict between the dropbear SSH server and and the LabVIEW/PuTTY combination that doesn't show up with other SSH servers.  If you can get assistance from the developers of the UUT software maybe they can help dechipher the dropbear server response to the LabVIEW strings to find out what is missing.

Rich

[Janne-_-]

Rich,

TY for answer.

I don't think it's about conflict between the dropbear SSH server and and the LabVIEW/PuTTY combination because,
I have also tried communicate between two laptops running Win XP. This time i only recived mgs "SSH-2.0-OpenSSH_3.8.1p1"



-Janne

[RLD]

Janne,

If you Google "SSH-2.0-OpenSSH_3.8.1p1" there are thousands of hits, with various suggestions as to what that response means.  It sounds like a client configuration issue to me.

I'm guessing that the LabVIEW Telnet with PuTTY redirection to the SSH port failure also is a client side configuration issue, but I've never able to figure it out.

Rich

[minnellac]

It looks like I am in exactly the same boat. I am trying to control a test machine running linux through ssh and LabVIEW. I've set up a tunnel using plink (or putty) and I tried talking directly with that device through the tunnel using both the TCP functions and Telnet. It's pretty much the same as what you have described. Through TCP, I can establish a connection, and read a string "SSH-2.0-OpenSSH_4.3p2 Debian-9" indicating the SSH server. I can try to send anything, and I will get a response of "Protocol mismatch". I think it disconnects me at that point, because I can't read any more from the connection.

If anyone has any thoughts on this, I'm willing to fool around with it for a few more hours. After that, I'll just switch to telnet.

Chris