Hi- Apologies in advance if this is off-topic, but I've been unable to find any coding or usage examples on how to open a SSH client to a remote server. I'll happily RTFM if I can just find the FM (!). The client environment is x86 Linux 2.6.x, the remote SSH servers will be on proprietary embedded devices. My current application uses a socket interface and select() to communicate with local serial ports and/or remote TCP/telnet ports. I need to extend this C++ program to also support communication to remote servers over SSH. I would prefer to not 'hook into' other commandline applications. Is this a practical exercise? Thank-you for any suggestions. ron
Hi Ron-- On May 23, ron.flory at adtran.com said: > I need to extend this C++ program to also support communication to > remote servers over SSH. I would prefer to not 'hook into' other > commandline applications. Is this a practical exercise? I believe the current feeling is that you should, in fact, hook into the other commandline applications. Interacting with the openssh tools as separate processes (using fork/exec, sockets, stdio, etc) is preferred to trying to link libssh.a (or other chunks of openssh) into your application directly. For example: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=114721160324354&w=2 The folks on this list will probably be better able to give you advice if you follow that general strategy. It will also helps you with future maintenance: you can keep your openssh installation up to date without worrying about tweaking your own code to match a potentially-shifting API. The command-line interface tends to be stabler than the library calls. --dkg
On Tue, 23 May 2006, ron flory wrote:> Hi- > > Apologies in advance if this is off-topic, but I've been > unable to find any coding or usage examples on how to open a > SSH client to a remote server. I'll happily RTFM if I can just > find the FM (!). The client environment is x86 Linux 2.6.x, > the remote SSH servers will be on proprietary embedded devices.It would be nice to offer a SSH client API, but we don't have one yet. libssh.a certainly isn't a client API, just an internal thing for functions shared between the various tools. The only way at present is to open the ssh client as a subprocess. This is what scp and sftp do, and it works very well. I suggest that you have a look at the sftp.c:connect_to_server() function to see how it is done there - it is very straightforward. -d
On May 24, 2006 9:02:39 PM +0200 Peter Stuge <stuge-openssh-unix-dev at cdy.org> wrote:> Getting off-topic now, but yet another SSH client implementation is > PuTTY, which is portable, self-contained and public domain.PuTTY is most certainly not public domain. -frank
On Wed, May 24, 2006 at 02:07:34PM -0700, Frank Cusack wrote:> > Getting off-topic now, but yet another SSH client implementation > > is PuTTY, which is portable, self-contained and public domain. > > PuTTY is most certainly not public domain.Certainly not! Thank you for correcting me! For the record: "The PuTTY executables and source code are distributed under the MIT licence, which is similar in effect to the BSD licence." Thanks again, sorry about the noise, I think I need vacation to stop making mistakes like this. //Peter