[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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




References:
Question about using libssh as a layer in another libraryCorey Minyard <minyard@xxxxxxx>
Re: Question about using libssh as a layer in another libraryAndreas Schneider <asn@xxxxxxxxxxxxxx>
Archive administrator: postmaster@lists.cynapses.org