SSH needed

[Cat]

The Grand Poobahs of Information Assurance have decreed that telnet is too much of a security risk to be allowed anymore and must be removed from our systems.  SSH is marginally acceptable, so I searched around on LabVIEW and SSH and came up with lots of people saying how wonderful it would be if it was available, and that's about it.

NI has this article that recommends using PuTTY: "The PuTTY software package also has a command-line interface to the PuTTY back ends named Plink that can be easily used by LabVIEW." But everything I've read over on the Dark Side says this is anything but easy and no one has been able to get it to work automatically from LabVIEW.  Everyone just gives up and uses telnet.
 

There is a product out there called labSSH that I ordered, downloaded, attempted to install with no luck.  After several back-and-forth emails with the (very nice) tech support person, I was told that labSSH won't work with the 64-bit versions of LV.  Sigh.  (They are updating their website...)
 

Does anyone know of any other LV/SSH implementations out there?  All I need to do is remotely log onto a Linux machine from a Windoze machine and send it a few command lines and get back responses.  Nothing fancy. 

 

[ShaunR]

What's the issue with putty? I can connect to my VPS and execute commands with LabVIEW without any problems. (Maybe they are hesitant that you don't see anything in the DOS prompt as it is redirected to the Shell Execute)

 

An important point, however......

 

The examples tend to send the username and password in plain text. Do not do this! Instead you need to create a private and public key key pair (not very easy for point and clicky people, best to get the linux bods to do it for you and give you the private key-make sure they give you one that doesn't require a password) and tell the SSH server on the remote machine (again, linux bods) to only accept that key (or a couple of them if you have multiple users). Then putty will do a secure authenticated login using the keys.

 

This is the command line you will need to execute (note the ppk key file). The -P parameter is the port number which should be non-default for good measure, but you can leave it out while you are getting it to work on the default port.

 

C:tempputtyplink.exe myserver.com -P 32998 -ssh  -i C:Tempputtyputty_key_noPassword.ppk  -m C:Tempputtyscriptfile.txt

Note: all my files including putty are in a c:tempputty directory

Edited July 22, 2013 by ShaunR

[Cat]

What's the issue with putty? I can connect to my VPS and execute commands with LabVIEW without any problems. (Maybe they are hesitant that you don't see anything in the DOS prompt as it is redirected to the Shell Execute)

I looked up Plink, and what documentation I found says several times "Plink is probably not what you want if you want to run an interactive session in a console window."  I don't want to run an interactive session in a console window, but I do want to run a sorta interactive session from LabVIEW. 

 

It looks like what you've sent me is just how to run a one-time script.  Is that correct? I need to maintain a connection thru several command/response cycles where the next command may be dependent on the response received (all automated -- there is no user intervention other than selecting the box to talk to). I do this with telnet now -- it's just finding some way to do the session connect/maintain part with ssh versus telnet that I'm stuck on.

 

(Since you're being helpful, I'm ignoring the slam on us "point and clicky people"  )

[ShaunR]

I looked up Plink, and what documentation I found says several times "Plink is probably not what you want if you want to run an interactive session in a console window."  I don't want to run an interactive session in a console window, but I do want to run a sorta interactive session from LabVIEW. 

It looks like what you've sent me is just how to run a one-time script.  Is that correct?

 

Yes.

 

I need to maintain a connection thru several command/response cycles where the next command may be dependent on the response received (all automated -- there is no user intervention other than selecting the box to talk to). I do this with telnet now -- it's just finding some way to do the session connect/maintain part with ssh versus telnet that I'm stuck on.

 

 

This isn't easy in LabVIEW as the only interface you have is the on-shot Shell Command. MJE did put together an interactive CMD session that could be used for this purpose (not sure where it is though). However. You do not necessarily need to need to keep the link open to be able to achieve a pseudo interactive session but there is probably a simpler way and it's what putty was really designed for.

By far the easiest solution for you would be to tunnel your telnet through SSH (you can tunnel anything through SSH ). Create a local proxy" that your telnet client connects to on your local machine (127.0.0.1) and it will be completely transparent, to your telnet client, but secure. You wouldn't even have to write any code

 

As a slight tangent. I also looked at that software package you mentioned earlier a while back. It looked great but relies on a DLL and is just a thin wrapper around that (not cross platform, so no good to me). You could get them to compile the DLL for 64 bit so that you could use it (or you could use LV 32 bit).

 

The long and the short of it is that there is no native SSH library  support on windows (in any language, that I know of-maybe Rolf has something) and the only people that really care about it are linux bods since it is only really of any use to connect to linux boxes. Most windows users avoid linux like the plague and get by, when they need it, by tunneling with PuTTy. Windows users use VNC or Remote desktop rather than SSH to talk to remote computers.

 

 

(Since you're being helpful, I'm ignoring the slam on us "point and clicky people"  )

I count myself in this category too and it annoys the hell out of linux bods when I say to them that all flavours of desktop Linux are themed windows 95 with an encrypted DOS Prompt

If you want to really annoy them. When they rattle off a command line (because every Linux user has an Eidetic memory and therefore anyone that doesn't is an amoeba to be treated with scorn), just say to them "you lost me when you said 'type in' "

[jzoller]

I've been down this road, too.  Windows has a number of third party SSH tools (cygwin, TeraTerm, etc), but all of them are encapsulated in their own little universe and don't interact with other code well.

 

Tunnelling sounds like a good solution.  Because I'm not that smart , I ended up bridging LV with Python, and using the paramiko package to handle the ssh connection.

[Cat]

If you want to really annoy them. When they rattle off a command line (because every Linux user has an Eidetic memory and therefore anyone that doesn't is an amoeba to be treated with scorn), just say to them "you lost me when you said 'type in' "

We have a solaris/c programmer who we're dragging kicking and screaming into the linux&windows worlds. If she is looking for a file on a windoze box, she will still open up a command window and start typing in a few hundred characters of directory path. I've given up pointing out she could do the same thing with a few clicks of her mouse. I have to admit, she's a great typist, tho.

 

As a slight tangent. I also looked at that software package you mentioned earlier a while back. It looked great but relies on a DLL and is just a thin wrapper around that (not cross platform, so no good to me). You could get them to compile the DLL for 64 bit so that you could use it (or you could use LV 32 bit).

I asked the guy at Labwerx about making a 64-bit version and there was a bit of whinging about how much time it would take, how much testing there would be, etc. Maybe I should volunteer to be a beta tester. But you never really know if there's a real company behind products like that or it's just some guy in his basement doing this in his spare time.

 

 

By far the easiest solution for you would be to tunnel your telnet through SSH (you can tunnel anything through SSH ).

Unfortunately I can't just not use telnet -- telnet has to be removed from the system. But that may not be a problem... (see part B)

A) current problem

 

If I understand you (and the putty doc) correctly, if I want to talk to 192.168.3.24:5678 on a remote machine, I can run something like the following:

  c:tempputtyplink.exe -ssh -L 127.0.0.1:1234:192.168.3.24:5678 -i c:tempputtyputty_key_noPassword.ppk

then just set up my telnet session to talk to 127.0.0.1:1234, and putty takes cares of getting the messages to/from the linux box via ssh. Yes?

Last but not least, I assume I'm issuing the above command with "System Execute.vi"?

 

B) just semantics?

I just wandered thru the LV telnet commands and want to know if I'm missing something...

It looks like all they are doing is setting up and monitoring a TCP connection to port 23. So in regular usage the connection is actually to some remote box that has a telnet server listening to port 23.

But now instead of a telnet server, I will be talking to putty. So, in essence, I'm not running telnet on my machine, I'm just using the telnet mechanism to open a plain ole tcp connection on my own machine to putty and format writes/reads between my code and the remote machine.

Am I off base here, or if I do all of the above (and it works!) am I actually *not* using telnet?

[ShaunR]

I asked the guy at Labwerx about making a 64-bit version and there was a bit of whinging about how much time it would take, how much testing there would be, etc. Maybe I should volunteer to be a beta tester. But you never really know if there's a real company behind products like that or it's just some guy in his basement doing this in his spare time.

Nothing wrong with a guy in his basement offering software Difficult for defence companies however, that have preferred suppliers and require dedicated support channels. The way I usually get round this sort of thing is to offer a short term contract, that way it guarantees the contractor a wage for their work (some people ask for stuff then say naah, don't need it now) and it is an acceptable business interaction from the companies point of view.

 

Unfortunately I can't just not use telnet -- telnet has to be removed from the system. But that may not be a problem... (see part B)

A) current problem

 

If I understand you (and the putty doc) correctly, if I want to talk to 192.168.3.24:5678 on a remote machine, I can run something like the following:

  c:tempputtyplink.exe -ssh -L 127.0.0.1:1234:192.168.3.24:5678 -i c:tempputtyputty_key_noPassword.ppk

then just set up my telnet session to talk to 127.0.0.1:1234, and putty takes cares of getting the messages to/from the linux box via ssh. Yes?

Last but not least, I assume I'm issuing the above command with "System Execute.vi"?

 

Yes. But it is even easier than that. Just set everything up as a profile in PuTTY (being a point a clicky person I find a GUI is much better) then, when you need it, just run putty.exe -load myprofile (with system exec).

 

B) just semantics?

I just wandered thru the LV telnet commands and want to know if I'm missing something...

It looks like all they are doing is setting up and monitoring a TCP connection to port 23. So in regular usage the connection is actually to some remote box that has a telnet server listening to port 23.

But now instead of a telnet server, I will be talking to putty. So, in essence, I'm not running telnet on my machine, I'm just using the telnet mechanism to open a plain ole tcp connection on my own machine to putty and format writes/reads between my code and the remote machine.

Am I off base here, or if I do all of the above (and it works!) am I actually *not* using telnet?

Well. Telnet is a protocol but it is also used to refer to the client. Windows 7 doesn't come with a telnet client installed as default any more (which is called "telnet" and has to be installed with add/remove programs) but the term is used interchangeably.I don't find it very useful to get into semantic arguments with IT people who tend to be very anal, no sense of humour and completely unreasonable when it comes the their network. Just because you re not running the windows telnet client and are using labview, it still means you are running a telnet client, if they want to be difficult. I would speak to the person that issued the diktat and ask if it's acceptable to use the telnet protocol over SSH as LabVIEW has no native support for the SSH protocol and no 3rd parties have an acceptable solution.

 

If they are only referring to removing the telnet client, then this is fine and would work. Be careful though. If they also say you need to remove the telnet server from the nix box, you will be stuffed.

 

So far. I think the best of the evils (if puTTY doesn't do it) is the python approach since jzoller knows of a python SSH library. If you have plenty of C coders that need to justify their existence you could get them to port OpenSSH to windows (and compile it for 64 bit labVIEW). LabVIEW sucks at anything that has encryption/compression in it.

Edited July 24, 2013 by ShaunR

[Yair]

We have a solaris/c programmer who we're dragging kicking and screaming into the linux&windows worlds. If she is looking for a file on a windoze box, she will still open up a command window and start typing in a few hundred characters of directory path. I've given up pointing out she could do the same thing with a few clicks of her mouse. I have to admit, she's a great typist, tho.

 

Completely off topic, but I also sometimes go oldskool, and it can be much faster than using the UI, if you know some tricks.

 

Tell her that if you use Tab (and Shift+Tab), the command prompt will iterate through the folders and files in the current folder (so if you're in C:, you could type "CD pr" and then tab and it should auto-complete to "Program Files" and keep iterating through the rest). That can be a great time saver when using the command prompt.

 

She could also create batch files and place them in a folder which is listed in the path environment variable to have immediate access for common operations. For example, I have a 1.bat file somewhere that simply calls "explorer .", so if I type 1 and Enter, it immediately opens an Explorer window in that folder.

[ShaunR]

The examples tend to send the username and password in plain text. 

 

This is not correct. SSH does encrypt the passwords etc, but it is still a much better idea to use public key authentication and turn off password access as it is impossible to brute force.

[ShaunR]

Well. Some good news and some not so good news. But the "not so good news" is only a little bit not so good

 

First the good news.

I couldn't find MJEs interactive DOS thingy, but I found Rolfs pipes library (I don't think it ever got out of alpha, but it works).

 

You can use this to run Plink.exe interactively instead of sending a command file (just remove the -m switch). I've just used it on my VPS and it was fine apart from some dodgy control characters that would need to be filtered, but I started an interactive session and was listing directories and sending commands and reading output..

 

Now for the not so good news:

Rolf wrapped the windows pipes in a DLL that is 32 bit. So flash a bit of leg and maybe post  some funny cat images and he might compile a 64 bit version for you

 

If Rolf does give you a 64 bit DLL, then I'll post an usage example to help you on your way.

[mje]

I couldn't find MJEs interactive DOS thingy..

 

I think you're referring to http://lavag.org/topic/13486-printing-to-the-standard-output/#entry80999. I don't think it would be of help here, it just creates a console which can be used to print to...probably read from too, never tried that though. I've only ever used it for quick and dirty, "I need to dump a bunch of text to screen regularly and am too lazy to create a user interface" type of scenarios.

[Rob Calhoun]

I too have used LabSSH and concur that its developer is super nice and quick to respond to emails. However in the end we did not use it because of how it handled timeouts and because of the licensing, which was per-machine rather than per-developer. (We have separate boxes for development, test, build etc and that was just not going to work.)

 

We ended up installing cygwin and shelling out to it using the LabView System Exec function. It's kind of a brute-force solution but it is free and it works great. That gives you access to all of the usual ssh functionality, such as using RSA keypairs instead of passwords. Note that ssh is not included in the "standard" cygwin install but it is easy to add.

 

-Rob

[Cat]

Completely off topic, but I also sometimes go oldskool, and it can be much faster than using the UI, if you know some tricks.

She knows all the tricks -- she's been programming in C longer than I've been programming in LV.   You'd still have a hard time convincing me it's faster!  But the next generation will probably be drilling down telepathically and wondering why Old Lady Cat is still pointing and clicking with a mouse.

[Cat]

Nothing wrong with a guy in his basement offering software Difficult for defence companies however, that have preferred suppliers and require dedicated support channels.

I agree, like I said the tech support guy was very helpful. I just don't get the sense they have a team of programmers who can hop right on recompiling their code. And yes, the whole issue of whether or not I can even officially use labSSH is another tangle.

 

Yes. But it is even easier than that. Just set everything up as a profile in PuTTY (being a point a clicky person I find a GUI is much better) then, when you need it, just run putty.exe -load myprofile (with system exec).

That's what I thought I'd do at first. But I will have multiple destination ips depending on the ever-changing system setup. So programatically building a command line just seemed easier.

 

Well. Telnet is a protocol but it is also used to refer to the client. Windows 7 doesn't come with a telnet client installed as default any more (which is called "telnet" and has to be installed with add/remove programs) but the term is used interchangeably.

Our installation of putty doesn't include the telnet utility... Yes, I guess what I'm saying is that from my (admittedly biased viewpoint) I'm using the telenet protocol but not telnet server.

 

 

I don't find it very useful to get into semantic arguments with IT people who tend to be very anal, no sense of humour and completely unreasonable when it comes the their network.

We are actually extremely lucky to be working with some folks who understand our environment -- a submarine is considered a closed secret container, and is guarded by big burly guys with guns at all times.  I think they will be reasonable.

Of course we had to go outside of our own organization's IA/IT people, who think that how recently the fire extinguishers have been checked is just as important as how recently a virus scan has been done on the computers in the system. Definitely no sense of humor there.

[Sean Donner]

What about this .Net 4.0 library? http://sshnet.codeplex.com/

[TimVargo]

I realize that this thread is nearly two years old, but there is a new development about this.  This guy (GregPayne) recently took the above mentioned .Net library and from it created a limited functionality LabVIEW library that wraps the .net assemblies.

<SSH with LabVIEW>

[Phillip Brooks]

I did something similar, but no LVOOP

 

http://forums.ni.com/t5/LabVIEW/Plink-PuTTY-works-30-of-the-time-using-System-Exec-vi/m-p/3006795#M860452

[Shaun Hayward]

What about this .Net 4.0 library? http://sshnet.codeplex.com/

 

I use that library very successfully with our embedded devices, for both SSH console access and also for SCP-ing files. The only issue I had (at the time) was needing to recompile it for the correct CLR to match our version of LabVIEW.

[Cat]

I realize that this thread is nearly two years old, but there is a new development about this.  This guy (GregPayne) recently took the above mentioned .Net library and from it created a limited functionality LabVIEW library that wraps the .net assemblies.

<SSH with LabVIEW>

 

Thanks to ShaunR and a lot of RTFM-ing, I pretty much ended up with something that looks like the first example in the article.  Not ideal for my purpose, but better than nothing.

 

I'll take a look at the LV wrapper.  Thanks for posting about it.

I did something similar, but no LVOOP

 

http://forums.ni.com/t5/LabVIEW/Plink-PuTTY-works-30-of-the-time-using-System-Exec-vi/m-p/3006795#M860452

 

Considering I'm still oop-allergic, I'll check this out.  Thanks, Phillip!

TimVargo's post reminded me I needed to send out my yearly query to Labwerx regarding the timeframe (if ever) of a 64-bit version of their LabSSH software.  Here was the reply:

 

"I really want to get it done by the end of the year, as that's the only thing we really get requests for from our customers."

 

So there's hope...