LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Noxious

Native SSH and SFTP Support

Status: New

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 operationsNot only does it add an extra layer of complexity to the code but it is also quite inflexibleIncreasing interoperability requirements of present day (and future) computer systems rely heavily on terminal services with a vast percentage of those being SSH basedIn 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 managedAn example of some of the tools could look something like the below image and could come standard or part of the Internet Connectivity Toolkit.

 

2010-06-03_LVIE_SSH.png

37 Comments
TimVargo
Member

A C# library (SSH.NET) was developed and improved over the past few years, and this guy (GregPayne) recently took that .Net library and from it created a limited functionality LabVIEW library that wraps the .Net assemblies.

SSH with LabVIEW


~Tim
Blaze76
Member

I didn't get it working with Putty so now we have rebuilt the SW in C# and Visual basic that have some kind of support.

jbrassard
Member

This comment thread is six years old, and still no native SSH, SCP, or SFTP support!  There's some third party app that costs $500 bucks, and I hate to be cynical, but how much do they kick back to NI on each sale? 

 

SSH is extremely useful for automated testing; not only do we need to control the test equipment, but we need to communicate with and control the DUT, which very often is an embedded system of some sort, and SSH/SCP/SFTP is the only manner of I/O to it.  Please, please implement this!  LabVIEW costs $5k for the professional system, I don't want to have to pay someone else an extra $500 bucks just to use something that I can do on the Mac terminal with one line of input.

RavensFan
Knight of NI

If you need it, then be sure to click the star at the top of the message to give the idea a Kudo.

jbrassard
Member

Oh, I did.  I think the only way this gets done is if a big corporate buyer says they need it, and they won't buy dozens of licenses unless it's included.  

James@Work
Member

And, after all this time....

Not a peep from NI regarding the status of this request; declined, under consideration, in development, etc.  When a third party has developed a tool, inferior at best, and NI doesn't want to ruffle feathers they just ignore the idea/request from users.

 

This SSH/SFTP toolkit should be developed by NI from the ground up to include support for Linux RT targets.

Tech Advisor - Automation
LabVIEW 5.0 - 2020
carlos_camargo
Member

I find it amazing that there is still no native support for SSH/SSL.  I'm about to have to use PLink because there is no other choice.  Even users in large corporations suffer the pain of this absurd gap in what has been evolving steadily to a "real" programming language.  Lacking native SSL support is truly deplorable and provincial.

crossrulz
Knight of NI

The real problem here is that SSH/SSL require encryption algorithms.  To get your encryption code certified is EXPENSIVE.  You expect NI to just eat that cost?  I have heard that NI has no interest in investing in encryption for reasons like this.  The only way I could see a chance of this happening is if they open up the Linux cRIO platform more to use the SSH command line (you can already do a lot with it, just not publicized much) and it somehow leads for more hardware sales.

 

I personally have ideas for making an SSH library using the .NET encryption libraries.  That would only be useful for Windows systems, but that would not hurt my situation.  Now I just need to find some free time to write that library.  My current solution is using the SSH.NET linked to earlier, which is poorly documented and will crash LabVIEW if errors are not handled correctly.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
carlos_camargo
Member

crossrulz:  Yes, I do expect NI to eat the cost of developing their SSL/SSH code.  NI is not some tiny non-profit operation, they are a very profitable company and LabVIEW is their flagship product.  "EXPENSIVE" to you and I is really peanuts to a company like NI, I am honestly very put off by their continuing to ignore developing this incredibly relevant interface code.  So, yeah, they'll have to pay for developing that code, that is part of the cost of wanting to provide a closed-source language.  Not providing it is truly negligent and I've not heard a good reason for them not doing so.

 

Single platform solutions (such as relying on the .NET libraries) are not good answers.

James@Work
Member

Me Too!!  What Carlos said.

 

Yes, I still expect and expect years ago that NI would have invested in and developed a platform independent solution for this issue long ago.  This is a huge gap in the platform that is not currently completely filled by any 3rd party solution.

 

And, after more than 7 years since the original post for the status to still be "new" and absolutely no official response from NI is what's really shameful.  The status should be changed to "declined" since NI has apparently made that decision.  NI should be honest; change the status and provide the details behind the decision.

Tech Advisor - Automation
LabVIEW 5.0 - 2020