-
-
Notifications
You must be signed in to change notification settings - Fork 312
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restrict tunnel subdomains to author SSH fingerprint #313
Comments
This issue can be closed, but FYI, I ended up modifying source code to provide an option to automatically generate URL as a hash of subdomain and fingerprint. |
Given time constraints, this is much simpler and smaller implementation of original Tunnel idea we had in mind. Key highlights: - DigitalOcean VPS running [Sish](https://github.com/antoniomika/sish) via Docker Compose (I took me a while to figure this out). We're on $6 plan a month. We will see how long it lasts. - We use [SSH tunneling](https://www.ssh.com/academy/ssh/tunneling) - We use `*.proxy.rise.tools` subdomain Benefits: - No additional tools required. Just SSH client. - No cloud service involved. Less things to maintain. We will eventually need it (more on it later). How this works: - Project is assigned its unique ID (via `uuid.v4()`) - Project ID is stored in `.rise/projectId` file - Tunnel will be open on each server start automatically, with 5s timeout - Hostname is fixed to be <projectId>.proxy.rise.tools. Known limitations: - URL must be unique, so we use rather ugly projectId.proxy.rise.tools. It's not that big of a deal, since you scan QR Code or copy the deep link - Anyone can start the tunnel knowing your projectId. It means that it's not 100% secure (although brute force guessing your projectId is only theoretically possible). However, if you share your connection with network, it may become more likely. **That's why tunnelling should only be used for development** [All these two limitations can be fixed easily](antoniomika/sish#313) - I opened up an issue in the project we're using. Once this is implemented, we will be able to: - use nicer names for projects, e.g. "fancy-project" - allow users to set custom names **Preview:** <img width="937" alt="Screenshot 2024-07-21 at 02 03 32" src="https://github.com/user-attachments/assets/474d21c5-be9c-413d-84cb-4363dc96b35b"> TBD: - Better UX if tunnel fails and while tunnel is loading (and it's been more than 2s already) - Warn if no `''` model is present. QR Code points to index by default and this fails otherwise. This should be configurable. - Provide default screen for example. When users add it, they will loose default Rise Playground screen with list of available examples. We should print it there instead. - ONE DAY: maybe that default Playground screen can be Rise too! - SSL
Hey there @grabbou, Sorry for the delay, I was traveling for the past few weeks! The current way of limiting domain access is through DNS, so your method works best for "deterministic urls". Happy to accept contributions on adding that ability though! Hope that helps! |
Hey!
Thanks for making Sish, it's been working really great for our Open Source project. For context, we're using it to set up tunnel session from your local development machine, so you can distribute the URL to your friends to preview your work.
We are using stable subdomains (e.g.
xxx.proxy.com
) and right now, anyone knowing thexxx
can set it, if correct flags are specified.I wanted to keep things as stateless. After investigating the source code, I think the best mechanism to utilise is providing custom HTTP service to validate public keys.
Unfortunately, there's no "subdomain" in the body, just the public key, remote address and the user. If there was subdomain and port user is trying to set up tunnel, that would do it!
The text was updated successfully, but these errors were encountered: