This lets you use a proxy for connecting to the SSH server, which
is useful on networks that block SSH/port 22. For example you can
use the boringproxy tuntls command to create a proxy that will
tunnel the client's SSH connections over TLS to the server.
It's all very meta and forces at least double encryption, but it
could be useful.
LetsEncrypt currently only supports ports 80/443 for ACME, so if
custom ports are used we need to disable automatically getting
certs.
Also changed it to only emit a warning when ports aren't
reachable from the internet, rather than failing.
TakingNames.io now provides bootstrap domains, which simply
creates an A record based off the ip address of the requesting
server, without requiring any authorization. This allows
boringproxy to always use HTTPS, even when getting the admin
domain.
Now checks to make sure a domain isn't already used by a previous
tunnel. This prevents accidental silent modifications to tunnels
and also fixes a bug where multiple entries were being made in
the authorized_keys file.
Was writing both the old content of authorized_keys and the new
tunnel every time a tunnel was created. This essentially made the
file double in size for every new tunnel added.
This is useful for when you want to use boringproxy more like a
normal reverse proxy, ie if boringproxy and your service are on
the same machine, you can just use the port of the service as the
tunnel port and boringproxy will forward directly to it without
using SSH.
This would normally be used with no client set.
Just needed to add an option to allow external connections to the
ports from the server, then set the proper values in the
authorized_keys file and on the client.
Allows tunnels to specify what address the client with connect to
for upstream connections.
Also changed the tunnel-adder UI.
Also fixed a bug where invalid domains would crash. Needed to
properly return an error dialog.
It pretty much only accomplishes what you can already do with a
normal SSH client. The difference is that keys are generated on
the fly by the server and transmitted for the client to use for
the tunnel.
I had been moving in the direction of implementing a custom SSH
server in golang. That would be pretty easy if using a custom
application protocol, but I want to support tcpip-forward which
looks like it would be a lot more work. It also would be nice to
support generic CLI clients like OpenSSH.
The point of using SSH in the first place is that it's known to be a
solid tunneling solution. To that end, I've decided to rely on
OpenSSH for now, since that program may have tunneled more bits than any
other since the dawn of time. This requires a bit of hackery to generate
SSH keys and place them in authorized_keys (as well as shipping the
private key to the client), but I think this will work well for now.
Plus OpenSSH is already installed on pretty much every server
I'd expect to run boringproxy.
