OctoTunnel: Reverse Shell Over Tunnel Tool

Sending a signed contract over Gmail is a tradeoff: faster than a courier, slower than a chat message, with a security profile nobody actually likes. WhatsApp is worse — the client's family WhatsApp Web session has the document now too. A self-hosted reverse-SSH channel replaces both: clients run a one-click setup, the operator opens a desktop app, picks the recipient, and drops the file. No email, no messengers, no third-party cloud.

The problem it solves

Solo professionals and small operators routinely send sensitive working documents — contracts, drafts, signed PDFs, working files — to their clients. The default tools weren't built for it. Email systems leak to retention policies and inbox-side breaches: IBM's 2024 report puts the average data-breach cost at $4.88M, and even the cheap end of that range buries a small practice. Messenger apps store everything plus a side-channel: WhatsApp Web sessions stay logged in on laptops the operator doesn't control, and Telegram cloud chats sit on infrastructure outside any jurisdiction the operator has chosen. Cloud-storage links wallpaper over the problem with revocable URLs that still leave a copy on someone else's servers.

The result is a steady, low-grade compliance and trust risk. Lawyers, accountants, consultants, freelance architects, and small studios all carry it. The work happens; the channel for moving the work is the weakest link in the chain. The conventional fix — a hosted file-transfer SaaS — adds a different third party (with its own subpoena exposure and per-seat bill) and doesn't solve the underlying problem: the operator still doesn't own the channel.

Who needs this most

• Solo legal, accounting, and consulting practices moving 3-20 sensitive documents per week to clients on Windows, macOS, and Linux laptops, where one compromised inbox loses both the document and the case-file context attached to it.
• Small studios and freelance architects handling client deliverables — drafts, source files, signed proposals — too large for email gateways and too sensitive to drop on a public file-share, the moment the friction of "send me a Dropbox link" starts costing billable hours.
• In-house IT operators at 10-50-person companies who need a reliable way to push patches, configuration bundles, or audit packages to a fleet of remote employee laptops behind home routers — the Wednesday morning when a customer audit demands an updated NDA on three employee machines in three different timezones.

The moment this hurts: any week the operator has to pick between "send it through a channel I don't trust" and "set up a one-off Dropbox just for this client." That choice repeats weekly for anyone running a client practice.

The solution — in plain terms

Every client runs a one-click installer. The installer makes a persistent outbound connection to a relay server the operator owns — that's it. No inbound ports on the client, no firewall change at the client's home or office, no admin call to the client's IT team. From the relay's perspective, that outbound connection is a reverse tunnel: the operator can now reach back into the client's laptop, but only through the relay, and only with the operator's key.

On the operator side, a desktop app shows every connected client in a single list — live, stale, or offline. Pick a client, drop a file, watch the progress bar, see the green checkmark. Need to open a shell? Click "Remote Access" and a terminal opens to that client's laptop, routed through the relay. Same workflow whether the client is on a Windows ThinkPad in Berlin, a MacBook in Toronto, or an Ubuntu workstation in São Paulo.

The operator owns the relay (a $5/month VPS or a small box on a home network), the keys, the SQLite registry of which client connects on which port, and the logs. No SaaS account is involved at any point. The whole stack hands off to the operator on day one.

Value delivered — what you get

• Stop trafficking client documents through Gmail, WhatsApp, and Dropbox — the channel runs on infrastructure the operator owns, with no third-party copy of any file in flight or at rest.
• Cut the back-and-forth of "can you resend that?" from days to seconds — files land directly in the client's Downloads folder; the operator sees the green checkmark before closing the laptop.
• One workflow for every platform on the client side — Windows, macOS, and Linux clients all register the same way, show up in the same list, and accept transfers through the same interface.
• Replace a $15-50/month client-portal SaaS subscription — runs on a $5/month VPS or a relay sitting on the operator's home network, with no per-seat licensing as the client roster grows.
• Open a shell to any registered client without setting up SSH on their laptop manually — the reverse tunnel handles the routing; the operator types tunnel shell <name> and is in.
• Survive flaky client connections without losing a tunnel — a watchdog with exponential backoff (5s start, 120s cap, resets after 60s of healthy uptime) reconnects without spamming the relay or burning out on a long outage.
• Contain an isolated breach without rebuilding the whole system — each client gets its own system user with no shell, restricted to remote port forwarding only; revoking one client takes a single tunnel kick and that lane closes without touching anyone else.

Where it delivers outsized value

Professional-services practices handling client documents under regulatory scrutiny — legal, accounting, advisory, healthcare administration — are the cleanest fit. The operator can answer "where does the document live in flight?" in one sentence: on infrastructure I own, on a relay I run, in a session keyed to that one client. Cross-jurisdictional client work is the second strong fit: where the operator and the client sit in different regulatory regimes and the document channel can't reasonably touch US tech platforms, the relay can live in any VPS region the operator picks. Third, small consultancies that distribute client-side tooling — patches, config bundles, signed binaries to customer laptops on home networks — use the reverse tunnel to solve the inbound-firewall problem without asking the customer's IT to open anything.

Distinctive features — why this over the alternatives

• One-click client installers for all three desktop OSes — Linux/macOS bash + Windows PowerShell setup scripts, each self-elevating, self-registering, and configuring a watchdog under systemd, launchd, or Task Scheduler respectively. The client doesn't need to know what SSH is.
• Cross-platform watchdog with exponential backoff — starts retry at 5 seconds, doubles on quick failures, caps at 120 seconds, and resets the moment a connection holds for 60 seconds. A client coming back from a long outage doesn't hammer the relay; a flaky link doesn't pin the watchdog at fast retry forever.
• Per-client isolation at the OS level — every registered client gets a unique system user (client_<id>), no shell, no password auth, and an sshd Match Group block restricting them to remote port forwarding on localhost only. Compromise of one client's key cannot open a shell, browse the relay, or reach another client's lane.
• Automatic IP tracking — a cron job on the relay parses sshd auth logs every minute, picks the latest accepted source IP for each tunnel user, and updates the SQLite registry. The operator always sees where each client actually connected from, even when the client's home IP rotates.
• Tauri desktop app and a parallel CLI — the desktop app fronts the daily workflow (list, transfer, terminal, aliases), and a tunnel shell CLI mirrors every operation for scripting, automation, and headless administration. Either side stays usable if the other breaks.
• Reversible everywhere — every setup script ships with a matching cleanup script. Relay, admin machine, and every client OS can be cleanly uninstalled. Operators are not locked into a half-removed system if they decide to move to a different relay or shut the whole thing down.

Under the hood — built to last

The desktop app is built on Tauri 2 — a Rust backend talking to a React 19 / TypeScript / Tailwind frontend in the system webview, not an embedded Chromium. SSH and SFTP run on russh 0.46, a pure-Rust async SSH library, so the operator's binary has no OpenSSH runtime dependency. The client registry is a single SQLite file on the relay, queried over SSH with sqlite3 -json — boring, durable, replicable. Tunnel persistence on the client side leans on the OS-native supervisor — systemd, launchd, or Task Scheduler — so no custom daemon ships to a customer laptop. The whole stack self-hosts; nothing on the critical path depends on a SaaS account or a vendor API.

Current maturity

SSH Over Tunnel is in working development. The relay setup, all three client installers (Linux, macOS, Windows), the Tauri desktop app, and the parallel tunnel CLI are functional and exercised end-to-end against a local-network relay (a ZimaBoard) and a working client roster across Linux, macOS, and Windows. The codebase is roughly 7,900 lines spanning Rust (Tauri backend, SSH and SFTP modules), TypeScript and React (desktop UI — 7 components, 4 hooks), and a fleet of Bash plus PowerShell setup, cleanup, and operations scripts. First commit February 2026; last activity 2026-03-08. The remaining gap to a publicly-deployed setup is the move from the local ZimaBoard relay to a public VPS — vps_migration.md walks through the cutover step-by-step.

Roadmap — what's next

The next milestone is the public-VPS cutover: the relay moves from a local ZimaBoard to a public cloud VPS, opening the platform to clients who don't share a LAN with the operator. After that, the work splits into two threads. One is hardening for multi-tenant operation — a single relay supporting multiple admin operators, each with their own isolated client roster, which is the prerequisite for any hosted-relay or partner-operator offering. The other is application-layer polish: native installer bundles for the desktop app, push notifications for transfer completion, and an operator-facing audit log so a practice can answer compliance questions without grepping sshd logs by hand.

Working with the architect

Three engagement modes apply to this project. A practice or studio can commission a custom build modeled on this architecture, branded and configured for the operator's own client roster — turnkey delivery, not a self-serve install. A company already running its own operator console or fleet-management stack can engage on extension — adding the reverse-tunnel file-transfer capability into the existing surface, integrated against the company's own identity and audit systems. And operators evaluating whether to build their own equivalent can engage on strategic advisory — a review of architecture, security model, and operational tradeoffs against an internal proposal. Reach out via sintegrium.io or LinkedIn for a 30-minute scoping call.

---

Built by Yurii Staryk · Solution Ecosystem Architect