In the current developer release we have bash scripts that launch sshd and the ssh client to provide an encrypted tunnel on which X forwarding then allows an application to be used remotely. Having part of the code run as a bash script with our client interface having no control over this process or even knowing if it performed successfully or not is something we haven't been comfortable with - it just got the job done for now.
Therefore we've been looking at ways to have this functionality within code. Our options :
- use libssh to write our own client and server all linked up with our core client.
- Use the command line sshd and ssh programs but have input,output and errors routed back and handled by our program.
We are still weighing the pros and cons to both the options above. The following mail I wrote to Erle speaks a little on my thoughts on this and I thought I should post them here and maybe others can chime in or at least be aware of what runs in our warped minds ;)
(Yes I'm lazy and that's the real reason of me copy pasting the mail ;) )
Mail to Erle
Sat, Feb 26, 2011 at 1:24 AM
subject SSH server and client
Hey,
I've been thinking that one option instead of writing our own ssh client and/or server is that we use the existing executables similar to what we are doing with scripts but now without scripts from within our code and we reroute the stdin,stdout and stderr for these executables with the pipe and dup2 methods. We then parse the results and handle conditions accordingly.
This will solve our current deficiency with scripts that the calling program has no idea of whether the child has performed successfully or not.
Advantages:
- We're sticking with proven code. Our own code increases chances of bugs/vulnerabilities.
- We'll be able to get all of this out the door quicker. Any code we do write will first have to reach a point wherein it supports most existing features in sshd/ssh. It will need to support tunneling,etc. Since I don't think we're really adding new functionality to the core and all we are interested in is actually control over these processes, this method may suffice.
- Most users would already have sshd and ssh on their systems so we can reuse existing code already on their systems. Even if the users need to install this as a dependency I'm not sure it will cause more gripes than running the olsrd daemon.
Disadvantages:
- A child process would have some degree of extra overhead in terms of memory,stack,etc. How much and if it should be a concern can easily be measured.
- We are restricted to current features supported by the sshd and/or ssh programs. We need to understand if our current set of requirements and most future requirements can be met with sshd and/or ssh.
Let me know your thoughts.
Bye for now