mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Georg v. Zezschwitz" <...@garnix.de.INVALID>
Subject Building a reverse proxy based on SSHDa
Date Wed, 23 Jan 2019 08:57:49 GMT
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




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message