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

[Corey Minyard <minyard@xxxxxxx>]

On 12/14/18 1:04 AM, Andreas Schneider wrote:
> 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.
That is your design, there is no need to do this in the actual data 
handling.  I'll comment a bit later.


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

Well, before doing that, I'd like to know how feasible this is.


> >   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 :-)

Indeed, hindsight is usually pretty good :-).


> > 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 :-)

Actually, it has nothing to do with being a client or a server. And I 
said I think this would be hard :-).

The OpenSSL library is push oriented (though it is, IMHO, unnecessarily 
complicated).  In a model like that, your protocol handling is a layer 
where you write data into the top of the layer, the layer does it works, 
then it makes the processed data available at the bottom of the layer.  
And vice versa, data comes in and gets written into the bottom of the 
layer, the layer handles it, then it makes available to the top of the 
layer.

Then you have another piece of software that talks to the socket and 
pulls data off of it and does the write into the bottom of the layer, 
and gets data from the bottom of the layer and writes it to the socket.

That way it's easy to replace what is underneath the layer with 
something different.

And I'm assuming that would be hard, though I would be happy to be wrong.


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

I understand.  I support a couple of large software projects myself.

Thanks,

-corey


> Cheers,
>
>
> 	Andreas