Use libified ssh instead fork/exec ssh

[olofhagsand]

Current NETCOF over SSH solution when connecting from controller to devices uses a fork/exec mechanism of the ssh binary. This has several drawbacks, including data in piped stdio,, external handling of keys, etc. The proposal is to change this to libssh or libssh2 to get a proper API and eventually a better key handling interface. It is suspected that this solution is the cause of occasional "fragmented frame" errors when running to many devices.

[olofhagsand]

Cannot get libssh2 to work. pub auth with openssh sshd fails. Will try libssh instead. We preferred libssh2 with its BDS-derived license over the LGPL of libssh, but libssh is easier to get to work.

[NetworkOverload]

Something I've noticed that is kind of nice with using exec ssh is that it honors the .ssh/config file, which means a person can add whatever kex arguments, ports, specific key files to use etc and clixon inherits it. Using a library means that clixon would need to be able to define any special options a remote host would need in the CLI. (Unless the lib can reference the config file, I don't know the answer to that).

[jktjkt]

Hi there, a co-author of netconf-cli here. We used to rely on libnetconf2's built-in libssh support in our NETCONF client, and we migrated to forking ssh(1). The main reason was that libssh had incomplete support for parsing OpenSSH config file ssh_config(5), and that proved to be very frustrating. Also, the API interface was much simpler. On the other hand, our colleagues who maintain the netopeer2 NETCONF server are using libssh (but they do require much more advanced functionality, including server setup and reverse "call-home" connections, etc).

[denniswa]

Just out of curiosity what option(s) are you using with OpenSSH that's not parsed with libssh?

[olofhagsand]

Removed the prio label due to the discussion about pros and cons. Need further investigation of the original problem, maybe we can solve it using the existing solution.

[jktjkt]

Just out of curiosity what option(s) are you using with OpenSSH that's not parsed with libssh?

Maybe @syyyr (the original author of our code) remembers why we ended up calling ssh(1) from netconf-cli instead of working with libssh?

I'm afraid we did that five years ago, so I don't recall all the details. When I re-read this discussion (see that link) now, it seems that the main problem was that the simple use case ("do what ssh(1) would do, including a preference of using a key authentication if configured, talking to an SSH agent, and falling back to password prompts or PAM discussion or whatever") required some non-trivial code (which we were not able to put together in a "reasonably short time"), and we felt like we were duplicating something that "should work out of box". Since we are an interactive client and we did not require any custom configuration, forking to a process was a no-brainer.

Just two examples from the very long discussion we had at that time:

• extra code was required for printing out the filename of a private key file that's being unlocked
• we had to figure out what to do when the server sends a different key type than we already know

[syyyr]

@jktjkt pretty much explained it. We wanted what the openssh cli client does, and didn't want to implement that ourselves. At that time we only tried using libssh2, because that's what libnetconf2 used to use, but there might be libraries, that do what the openssh cli client does, but I don't know any.