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
BeanFest
Member

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
Member

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.

GOTALIA means LabVIEW


rolfk
Knight of NI

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.




Rolf Kalbermatter
Averna BV
sdrochek3
Member

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

crossrulz
Knight of NI

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.


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
David_L
Active Participant

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

blu_rot
Member

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
Member

"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....

-------------------
Greg
Certifed LabVIEW Developer
jph_p
Member

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
Active Participant

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 )


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness