Native SSH and SFTP Support

[Noxious]

LabVIEW needs native SSH and SFTP connection support. 

In the past, LabVIEW users have had to rely on third party applications like PuTTY or ExtraPuTTY to do very basic Linux/Unix secure shell operations.  Not only does it add an extra layer of complexity to the code but it is also quite inflexible.  Increasing interoperability requirements of present day (and future) computer systems rely heavily on terminal services with a vast percentage of those being SSH based.  In the past 5 years I have needed to use SSH type connections more and more inside of LabVIEW, I do not see it ending anytime soon and I know I am not alone.

An SSH connection could be managed in much the same manor as the current VISA and TelNet connection are managed.  An example of some of the tools could look something like the below image and could come standard or part of the Internet Connectivity Toolkit.

[BeanFest]

Kudo, we use linux as our product OS but must provide test automation on windows.  Having to use plink and winscp is very limiting.

[gotalia]

The problem with using command line ssh is that it lacks the interactive capabilities that LabVIEW has as its strengths.

I would be willing to put up with a cobbled together mess if it meant that I could do my job. 

As it is, I don't have the ability to SSH and it costs me in both time and money.

We definitely need an interactive SSH capability.

[rolfk]

While SSH could be nice to have I think it's safe to say that SSH alone would be of little use to most. What really would be required is support for SSL in the network streams itself. Phillip Brooks says that correctly eventhough I think he confuses the terms a bit. SSH is a specific shell protocol with security included, while the session support he mentions is in fact usually called SSL.

And it should not only be supported in VISA but also for the TCP network refunums. UDP support would be fantastic but has lots of difficulties not the least being that even SSL implementations like OpenSSL have still several issues with that too.

I'm not sure if SSL support would help automatically with the implementation of SSH since I'm under the impression that SSH predates SSL and incorporates the security aspect into the SSH protocol on top of the network socket not as an intermediate encryption layer between the socket and the shell protocol. But it's probably safe to say that SSL support is in our modern world more demanded than SSH.

---

---

[sdrochek3]

Has this gone anywhere? Currently using ExtraPuTTY but would love to have native LabVIEW code instead.

[crossrulz]

I just ran into an application where SFTP could possibly be a requirement.  I'm trying to dance around that requirement right now.  This feature would be quite beneficial.

[David_L]

Anyone interested in this idea should check out the LabVIEW Tools Network product labSSH by Labwerx.  It supports SSH, SCP and SFTP.

[blu_rot]

RE:"Anyone interested in this idea should check out the LabVIEW Tools Network product labSSH by Labwerx.  It supports SSH, SCP and SFTP." 

They only support 32 bit LabVIEW.  We are moving our code from LabVIEW 2011 in 32 and 64 to 2013 64-bit only.  We have an application that requires 64-bit to be used and only want to develop in one development environment.  I have been waiting for LabVIEW to add SSH for over 5 years now.  I have been able to use Putty, plink pscp, and pagent with an app written in C# to get everything to work.  Security requirements are becoming more prevalent each year.  I am tired of kluging different applications together that are not designed to integrate well.  SSH is so common and has been done in ALL the major development codes on the market except LabVIEW.

[RGreg]

"SSH is so common and has been done in ALL the major development codes on the market except LabVIEW."

Amen.  Even if I was running 32 bit Labview, I would still blanche at paying several hundred dollars for functionality that should already be in LV.  I find it hard to justify telling my manager that:

1. I paid thousands of dollars for a development copy of Labview
2. This development copy is the top-of-the-line version of Labview
3. SSH is a standard, widely used protocol
4. The systems I need to interact with use Linux
5. My top-of-the-line, several thousand dollar copy of Labview cannot talk with our systems unless I pay yet more money to a third party for extra functionality that NI doesn't include in their top-of-the-line software.
6. Meanwhile, our in-house Linux developers are rolling their eyes.

Do you see the problem with this?  I now have to either a) switch to 32-bit LV and suck it up to buy the LabSSH software or b) write a bunch of extra code to kludge something together for this. 

And NI wonders why some people still don't consider Labview a real software language....

[jph_p]

Hi alll,

I have also an issue by using Labview2014 by connecting  a gateway ( BlackBox LES7084E) Ethernet/RS232 .

This connection allows us to have access to the whole debug menus implemented on our board, using remote front plane connexion (rs232).

By digging telnet/ssh connection with Labview (on web ), I tried the 'system exec.vi' using plink command (note : plink applcation are not supported !!)

I perform a lot of tests w/o any success 😞  . Not having working connection  jeopardize our test bench development!

My vi is able to send commands to our board BUT any results come back(!!) , except if I kill the plink task (taskkill /f /im plink.exe) then the data are  flushed (?)

=> it is not possible to do an automatic measurement  (our goal is 7 days test, measurement each 10'')

I opened a ticket to our local NI FAE , and hope to have, quickly, a workaround!

It is very strange for me not supporting  native telnet/ssh protocol !

By looking around us , more and more applications/hw/developments are done thru ethernet , so not taking it, as native, is a real gap in the Labview toolkit !! 

[PhillipBrooks]

Five years after the original post and still no solution. Maybe the issue has always been that NI views this as the responsibility of the OS.

Found this M$ blog entry that might give us hope; but it will probably take NI another year to roll in support.

http://blogs.msdn.com/b/powershell/archive/2015/06/03/looking-forward-microsoft-support-for-secure-s...

 ( Hope M$ doesn't require Windows 10 to support this or it will be another 5 years before we get a solution )