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
