Two Servers That Talk Without Shared SSH Keys

I run two servers that talk to each other without sharing SSH keys. Here's how.

It's not about being paranoid—it's about being practical when you're a solo operator who values uptime over fire drills. Tacavar's infrastructure runs on a tiny fleet: a primary droplet and a secondary dispatcher. They need to exchange commands, serve media, and trigger deploys—all without giving either one the keys to the kingdom. The solution hinges on three principles: least privilege, verbose logging, and path-level boundaries.

The Nightmare of Sharing SSH Keys

Every founder who's ever managed two machines knows the default path: generate a key pair, paste the public key into authorized_keys, and call it a day. It works until it doesn't. If that shared key is ever compromised, an attacker has free rein. Worse, when you're wearing the SRE hat at 2 AM, you forget which key goes where. SSH key security is not just about encryption strength—it's about blast radius. A shared root key is a single point of failure. For devops for solo operators, the right approach isn't more keys; it's fewer capabilities per key.

Tacavar's architecture uses a dedicated deploy key on the secondary server—but that key can only run a single script. No shell, no arbitrary commands. That's the difference between a castle with one gate and a fortress with controlled access points.

Caddy Can't Serve From My Home Directory — Until a Bind Mount

Here's the problem that kickstarted this whole approach. Caddy (Tacavar's web server) runs as uid 995 and needs to serve files from /home/tacavar/Desktop/. That directory is chmod 750—Caddy can't even traverse the parent home directory. Symlinks don't help because Caddy walks the full path and fails on permissions. The obvious solutions are all bad: chmod the home dir (hello, security hole), run Caddy as root (please no), or copy files (waste of I/O).

The real answer is a bind mount. One line in /etc/fstab maps /home/tacavar/Desktop to /var/www/videos. Both paths point to the exact same inodes. Files Hermes (Tacavar's workflow bot) writes to the home directory appear instantly at hub.tacavar.com/videos/ with zero copy and no permission changes. Caddy reads from a path it trusts; the home directory remains private. This is a four-line trick that enforces path-level least privilege without breaking the filesystem or duplicating data.

Cross-Droplet Dispatcher: Whitelisting Command Names

The secondary droplet—call it Bailian—needs to dispatch jobs to the primary: trigger deploys, post Instagram reels, write video briefs. Sharing root SSH keys was the obvious (and terrifying) answer. Instead, we built deploy_gate.sh—a whitelist-based dispatcher on the primary. Bailian connects with a dedicated deploy key and sends a command name (not raw bash). The gate script matches the name against an explicit whitelist, runs the corresponding script under sudo, and logs everything. New commands get added intentionally: instagram_post was added after a content sprint, domain_pending for a DNS check. Each addition is a deliberate act.

This is cross-server RPC without the R. No remote shell, no arbitrary commands. If someone compromises Bailian, they can only run the whitelisted actions. The blast radius is a few curated operations, not the entire machine. The audit log becomes the source of truth.

The Audit Log That Became Documentation

Every call to deploy_gate.sh is logged with timestamps, caller IP, command name, and exit code. After a few months, that log became Tacavar's runbook. Want to know how to trigger a deploy? Check the log. Need to verify what commands are available? The whitelist is self-documenting. The deploy key cannot do anything else—no SSH key security gaps. This is devops for solo operators at its finest: build systems that double as documentation.

What This Architecture Has Survived

Tacavar has been running this setup through: a redeploy during an all-nighter, a failed droplet on DigitalOcean (spun up a new one with the same fstab and gate script in 20 minutes), and a content delivery pipeline that writes video briefs from Hermes to the bind-mounted directory. Zero unauthorized access attempts succeeded because there's no open path. The bind mount survived multiple reboots. The deploy gate hasn't changed since it was written—just new commands added.

When Not to Do This

This approach isn't for every scenario. If you need true bidirectional real-time communication and can't afford a single round-trip, a message queue or gRPC might serve you better. If your threat model includes an attacker who already has root on one box, no amount of whitelisting helps—but then shared keys are even worse. And if you have a large team, you'll want centralized authentication. For the solo operator running two to five servers, this is a sweet spot: powerful enough to automate everything, constrained enough to sleep at night.

Tacavar runs on this exact infrastructure — no root keys, just bind mounts and whitelists. Learn more at tacavar.com/infrastructure.