Re: Question about using libssh as a layer in another library

[Andreas Schneider <asn@xxxxxxxxxxxxxx>]

On Tuesday, 4 December 2018 03:41:28 CET Corey Minyard wrote:
> I'm the author of ser2net, a proxy for making network connections to
> serial ports.

Hi Corey,

> I have been working on providing encrypted access and password access to
> ser2net, and I am not going to send passwords unencrypted over the net. 
> Well, I suppose it's happening if people log in to something over the
> serial port, and I want it to stop.
> 
> I have rewritten it to have a stream oriented library sitting under
> ser2net with a bunch of different stream types (telnet, serial port,
> SSL/TLS, IPMI serial over LAN, TCP, UDP, ....). Ser2net is now a
> converter from any of these types as an input to an output.
> 
> I would like to make it easy for users to make encrypted connections,
> and ssh is the obvious candidate for that. Unfortunately, no ssh
> libraries that I have found are really suitable.  libssh appears to be
> the closest to what I need, but lacks at least the following things:
> 
>   * I need something where I can provide the lower layer I/O myself, to
>     make it a layer in a stack.

I think Cockpit integrated libssh in a glib event loop. However I don't know 
the details.

>   * I need to provide my own poll implementation.  Other libraries I use
>     have their own interfaces for this, so I have to provide a generic
>     one that fits them all, and the libssh one is not sufficient to
>     provide the services I need.  Plus it has no capability to use
>     epoll, which I really need for scalability.
>   *  From what I can tell, libssh doesn't take data pushed from the
>     lower layer, it wants to poll for data when it wants it.  Since I'm
>     going to need to support many sessions simultaneously, I can't
>     really do a poll kind of thing, it has to be push-oriented.

I'm not 100% sure I understand what you're saying but we also need to poll to 
get data back from the server and this doesn't come in order.

> There are other issues I know of that are more fundamental to ssh
> itself, but I think I can handle those.  I'd have to figure those out
> for any implementation.

I would suggest to open bugs for those.

>  From what I can tell, modifying libssh to have an abstract I/O layer
> should be fairly easy.

I'm not 100% sure about that, but you can try. However I suggest we discuss 
this early.

> libssh's poll implementation is not a clean layer, so that issue is
> tougher.  It's wrapped around the session/socket/event code pretty
> tightly.  That doesn't look insurmountable, though.

If I could start again I would base libssh on talloc and tevent. That would 
make our life a lot easier :-)

> The last issue seems the hardest.  I'm not sure what it would take to
> make  libssh push oriented.

libssh is not only a client but can also be a server. So changing the internal 
is probably harder than you think :-)

Also maintaining and implementing a ssh library is quite some work, I think 
I'm doing it for 10 years now and we still don't have the same feature set as 
OpenSSH.


Cheers,


	Andreas