IntenseWebs/boringproxy
3
0
Fork 0
mirror of https://github.com/boringproxy/boringproxy.git synced 2025-02-25 18:55:29 -06:00
Code Issues Packages Projects Releases Wiki Activity

Remove SirTunnel stuff from readme

Browse Source
This commit is contained in:
Anders Pitman 2020-09-29 15:53:10 -06:00
parent b351a4265d
commit 17b37ab2ed
2 changed files with 2 additions and 82 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

83
README.md
View File

@ -1,86 +1,5 @@
# What is it?
If you have a webserver running on one computer (say your development laptop),
and you want to expose it securely (ie HTTPS) via a public URL, SirTunnel
and you want to expose it securely (ie HTTPS) via a public URL, boringproxy
allows you to easily do that.
# How do you use it?
If you have:
* A SirTunnel [server instance](#running-the-server) listening on port 443 of
`example.com`.
* A copy of the sirtunnel.py script available on the PATH of the server.
* An SSH server running on port 22 of `example.com`.
* A webserver running on port 8080 of your laptop.
And you run the following command on your laptop:
```bash
ssh -tR 9001:localhost:8080 example.com sirtunnel.py sub1.example.com 9001
```
Now any requests to `https://sub.example.com` will be proxied to your local
webserver.
# How does it work?
The command above does 2 things:
1. It starts a standard [remote SSH tunnel][2] from the server port 9001 to
local port 8080.
2. It runs the command `sirtunnel.py sub1.example.com 9001` on the server.
The python script parses `sub1.example.com 9001` and uses the Caddy API to
reverse proxy `sub1.example.com` to port 9001 on the server. Caddy
automatically retrieves an HTTPS cert for `sub1.example.com`.
**Note:** The `-t` is necessary so that doing CTRL-C on your laptop stops the
`sirtunnel.py` command on the server, which allows it to clean up the tunnel
on Caddy. Otherwise it would leave `sirtunnel.py` running and just kill your
SSH tunnel locally.
# How is it different?
There are a lot of solutions to this problem. In fact, I've made something of
a hobby of maintaining [a list][0] of the ones I've found so far.
The main advantages of SirTunnel are:
* Minimal. It leverages [Caddy][1] and whatever SSH server you already have
running on your server. Other than that, it consists of a 50-line Python
script on the server. That's it. Any time you spend learning to customize
and configure it will be time well spent because you're learning Caddy and
your SSH server.
* 0-configuration. There is no configuration on the server side. Not even CLI
arguments.
* Essentially stateless. The only state is the certs (which is handled entirely
by Caddy) and the tunnel mappings, which are ephemeral and controlled by the
clients.
* Automatic HTTPS certificate management. Some other solutions do this as well,
so it's important but not unique.
* No special client is required. You can use any standard SSH client that
supports remote tunnels. Again, this is not a unique feature.
# Running the server
Assuming you already have an ssh server running, getting the SirTunnel server
going consists of simply downloading a copy of Caddy and running it with the
provided config. Take a look at [`install.sh`](./install.sh) and
[`run_server.sh`](./run_server.sh) for details.
**Note:** Caddy needs to bind to port 443, either by running as root (not
recommended), setting the `CAP_NET_BIND_SERVICE` capability on the Caddy binary
(what the `install.sh` script does), or changing `caddy_config.json` to bind
to a different port (say 9000) and using something like iptables to forward
to that port.
[0]: https://github.com/anderspitman/awesome-tunneling
[1]: https://caddyserver.com/
[2]: https://www.ssh.com/ssh/tunneling/example#remote-forwarding

1
todo.md
View File

@ -4,3 +4,4 @@
requests.
* Might want to proxy requests at the HTTP level since it lets us do things
like terminating HTTP/2.
* Implement a custom SSH server in Go and connect the sockets directly?