Dear developers, first: Thanks for the software which now runs really stable for > 240 connected users.
There are 2 questions I have, which I put ahead, before I will describe my OpenSource project. 1) When will there be a maven release for the current snapshot status? 2) Does anybody have the time to check my code at GitHub for obvious „Oh my god“ hints - I guess I use SSHD pretty unconventional… My project: The AFAIK most widespread opensource free smarthome management software in Germany is FHEM. (https://www.fhem.de). It is a small Perl-written core plus lots of modules & more, supporting „nearly all“ smart home devices in a vendor independent way. It has some ten-thousand of users. For about 2 years, there has been support for Amazons Alexa, but rather „the hard way“: You had to register as developer, to „develop“ on your own skill, had to „somehow“ open your incoming port to the local raspberry etc. to the internet, install some software there … A nightmare for pretty many people. I wanted to improve this situation and was thrilled by the cool idea of „serveo.net“. It is worth a visit: https://serveo.net/ So: Opening your incoming port to the internet by „ssh -R … <public server>“. So, what I wrote was based on Apache SSHD a „public reverse proxy“, which - unlike the service of serveo.net, does *not* provide an open port to the internet. Instead, there is some „magic“ with OAuth: SSHD accepts *any* certificate, then you (the local software) sends a request like ssh <server> register keyhash=<sha256 of a local password> This will save the public key in a Redis-DB including the password hash and generate a user id based on the public key. After that, the local software sets up the reverse tunnel ssh -R 123:localhost:<local port> <server> But in fact, on the Apache-SSHD side, no real TCP server socket is opened, it is just „registered“ that the client with public key xy is now available for incoming TCP connections. The clients then go through public skill registration at Amazon, which forwards them to a small website (/register/ in the project). There, they enter there credentials, the password is verified with the stored hash, and by the means of OAuth Amazon gets the userid as part of the bearer token for HTTPS requests to the user. Once there is an incoming HTTP request from Amazon, the software takes the bearer token, checks if there is an existing SSH tunnel for that userid, and if there is, the request from Amazon is routed into the correct SSH reverse tunnel. The whole way it works is decribed (in German) here: https://wiki.fhem.de/wiki/FHEM_Connector We „launched“ the skill about 2-3 weeks ago, and now there are 240 users for now. My problem: Actually: None. It works. But I started building my software based on Apache-SSHD snapshot. And now I am unable to publish my software in a way that „just simply builds“. If you check https://github.com/gvzdus/sshd-oauthmux you already see the big warning: „It will not build“. Because I used some features of the Snapshot. In sshd.setForwarderFactory(new ServletClientForwarder.Factory()); you can track the way how I tried to integrate the logic of having a „virtual“ end of the reverse tunnel. in AlexaCommandServlet.java, there is the code that uses the „virtual end“: Receiving a external HTTP request, extracting the routing information, and pumping that request (as poor HTTP/1.0 non-keepalive) into the reverse tunnel. So, on the one side I am a bit reluctant to „back port“ my code to the 2.1 release (if it is possible at all). So, what to use instead of ClientChannelPendingMessagesQueue. If there are plans to pretty soon release 2.2, than the easiest thing would be to wait. On the other hand: I guess I read all documentation about Apache-SSHD for developers, and it is pretty handy, not to say: short. When you designed Apache-SSHD, I guess you did not have the usecase of „abusing a reverse tunnel“ in mind. Is there any hint you could give me: „Georg, I would suggest to have rather a look at XY if you want a cleaner way to acchieve you goal?“ Best regards, Georg
