Re: SSH poll functions not exposed to libssh.so

[Torsten Kuehnel <tdkuehnel@xxxxxxxxxxxxxxxxxxxxx>]

On Sat, 21 Dec 2019 08:52:09 +0100
Andreas Schneider <asn@xxxxxxxxxxxxxx> wrote:

> On Friday, 20 December 2019 18:01:13 CET Torsten Kuehnel wrote:
> > On Fri, 20 Dec 2019 09:07:45 +0100
> 
> > Thanks for the answer, this cleares things up for me.
> > 
> > Beside the api not beeing stable yet, are the ssh_poll_* functions itself
> > considered tested and stable to be useful ? I am considering giving it a
> > try and change my select/list-driven approach to a poll/callback scheme.
> 
> For the client?

It is to connect nodes in a secure peer-to-peer network. The one who
initiates the connection is the client, the one who listens and
receives acts as the server (in terms of ssh speaking). After that
point, the nodes use the established secure connection(s) to
communicate in both directions.

Up until trying to use libssh as the "layer" to provide secure
communication, i used GnuTLS direcly, but had problems to make that
solution act like ssh establishes its connections - the way
fingerprints of keys are displayed, known_hosts files and keeping 
certificates out of the way etc.

Now after some days diving into the depths of libssh, i think i
finally got the "spirit" of it. I have adapted the provided example
server and client code, got the pubkey authentication finally working
(puh) and transmit some bytes over an established channel. The
connection establishment is now exactly what i want and managing the
keys the way i want looks possible.

As the peer-to-peer communication itself is packet based, i think of
extending the ssh protocol extension itself.

I have similar packet handling like i found in libssh, so i have to
decide how stable and mature libssh code is compared to what i develop
for the peer-to-peer app myself.

Ideal solution: Extend the ssh protocol extension with the packet
types currently used in the peer-to-peer approach, and let libssh call
the appropriate callbacks in the peer-to-peer code. 

This would of course require patching libssh, and extending the ssh rfc 
instead of writing a complete new one for the peer-to-peer approach.

Anyway, thanks for the fine libssh library and heads up - good work !
 
> We have a ssh_connector. See the ssh_client.c example.
> 
> 

This looks promising. Throwing something at a filedescriptor end it 
appears at the other end of the secure connection (tunneling fd).

-- 
Torsten Kuehnel <tdkuehnel@xxxxxxxxxxxxxxxxxxxxx>