From Dropbox to Daily Driver Part 1: Scoping the Rebuild and the Threat Model

A few weeks ago, Part 5 of Five Minutes and an Empty Port turned a spare Raspberry Pi 4 into a working call-home dropbox: a persistent reverse SSH tunnel over autossh, reached through a Cloudflare Tunnel to a relay VM, proven end to end with a real reboot-recovery test. It did exactly what it was built to do. Once the post was finished, the Cloudflare Tunnel came down, the relay VM was deleted, and the Pi itself was shut off.

It’s the same physical Pi 4 starting this series. Rather than just reflashing it and moving on, this felt worth turning into its own build: Part 5 was honest about being scoped narrowly, proving a mechanism worked rather than showing what a properly built device looks like end to end, and there’s a genuine opportunity here that most “secure your Raspberry Pi” guides don’t have. This series gets to build the legitimate version of almost the exact same primitive, on the exact same hardware, and be explicit about what changes and why.

Same mechanism, different job

Strip away the framing and Part 5’s dropbox and this series’ end goal share real DNA: a Raspberry Pi reachable through a Cloudflare Tunnel, offering SSH access without a router port forward. The difference was never really the tooling. It was authorization, visibility, and what sits around that core mechanism.

Part 5’s dropbox was designed to be planted and forgotten: minimal footprint, no monitoring watching it, nothing checking whether the person connecting in was actually supposed to. That’s correct design for what it was, a five-minute physical-access exercise, not a criticism of it. A device an owner actually depends on for remote access needs the opposite instincts applied to the same mechanism: authentication that assumes the key alone isn’t enough, an access layer that can say no to a connection attempt before it ever reaches SSH, and logging that would actually tell you if something unexpected showed up. Parts 3 through 7 of this series build exactly that layer, on top of the same tunnel technology Part 5 already proved works.

What “secure” needs to mean here

It’s worth being specific about the threat model rather than reaching for a generic checklist, because a generic checklist tends to either over-build for a home device or under-build for one that’s genuinely internet-reachable.

This Pi will have a real, if narrow, exposure surface: a Cloudflare Tunnel hostname that anyone on the internet can attempt to resolve and connect to, gated by whatever sits in front of it. The realistic adversaries here are opportunistic ones, not targeted ones: automated scanners that stumble onto the hostname, credential-stuffing attempts against whatever auth layer is exposed, and the ordinary risk of a leaked or stolen SSH key rather than a nation-state actor with a reason to specifically target a home lab. That framing matters for what counts as proportionate. Key-only SSH is table stakes and not treated as the finish line here, because a leaked key is exactly the failure mode a second factor is meant to catch. A Zero Trust Access policy in front of the tunnel, rather than the tunnel terminating straight at SSH, is proportionate to “opportunistic scanner finds the hostname,” which is the realistic case. Full intrusion-detection tooling and continuous configuration auditing, covered later in this series, is proportionate to “I want to actually know if any of this ever gets tested for real,” not to a threat this device doesn’t face.

What’s explicitly out of scope: defending against physical seizure of the device, and anything requiring a state-level adversary’s resourcing. This is a home lab box on a home network, not a bastion host for anything that would draw that kind of attention, and pretending otherwise would make the hardening choices harder to justify rather than easier.

Choosing the OS

Raspberry Pi OS moved to Trixie, based on Debian 13, as the current release on October 2, 2025. Bookworm (Debian 12) remains supported for security-relevant kernel updates for roughly two years past that point, but Raspberry Pi’s own guidance is clear that it isn’t receiving new package updates going forward, and that in-place upgrades from Bookworm to Trixie carry a real risk of failure. For a clean rebuild happening the better part of a year after Trixie’s release, there’s no reason to start this device out on the outgoing release. This build starts from a fresh Trixie image — specifically the Raspberry Pi OS Lite (64-bit) build dated 2026-06-18, the current respin at the time of flashing.

Specifically, Raspberry Pi OS Lite (64-bit): no desktop environment, since this device is administered entirely over SSH and a GUI would be pure attack surface with no corresponding benefit. Trixie’s move from 32-bit to 64-bit time values is a genuinely useful detail for a device meant to stay in service for years, since it sidesteps the Year 2038 problem outright rather than needing a later fix.

Storage: a 128GB microSD card, and the trade-off that comes with it

This build runs from a 128GB microSD card, not a USB SSD. Worth being direct about that rather than hedging: SD cards are the single most common point of failure in Raspberry Pi deployments that run continuously, and a device that’s about to accumulate real write volume, journald logging, TOTP state, an eventual monitoring agent shipping events off-box, is exactly the profile that wears a card out fastest. That’s a real limitation of this build, not a detail to gloss over.

The mitigation here isn’t more expensive hardware, it’s Part 8: making the entire build reproducible with an Ansible playbook rather than relying on a disk image or the card itself surviving indefinitely. If the card fails, the honest answer is “reflash and re-run the playbook,” not “hope it doesn’t.” That’s arguably a more useful lesson for a homelab build than “just buy an SSD” would have been, since it’s the same posture this series already takes toward the Pi itself: don’t just plan for the device working, plan for what happens when it doesn’t.

What’s ahead

Nine parts, covering the full rebuild:

1. Scoping the rebuild and the threat model (this post)
2. Flashing the card and a genuinely headless first boot
3. Locking down the base OS: accounts, SSH fundamentals, the firewall, and unattended security updates
4. Adding two-factor authentication on top of key-based SSH
5. Remote access, revisited: Cloudflare Tunnel with a Zero Trust Access policy in front of it, and how that compares to Tailscale and WireGuard
6. Standing up a monitoring platform to actually watch this device
7. Wiring the Pi into it: log shipping, login alerting, and continuous configuration auditing
8. Making the entire build reproducible with an Ansible playbook instead of a disk image
9. A closing checklist, and the full-circle comparison back to Part 5

Part 2 starts where every Pi build actually starts: with the Imager, a blank card, and the first boot log.

Sources: Trixie — the new version of Raspberry Pi OS, Raspberry Pi OS downloads