I have a Raspberry Pi 4 running Raspbian with several services managed through Docker Compose. One container is already reachable through a Cloudflare tunnel, and I would like to access the host remotely using the browser-based SSH terminal. However, I want WAN access to SSH to be enabled only when I explicitly need it and disabled the rest of the time.
I can use curl on the host to read a remote on/off switch, so I was considering a cron job that checks the switch every few minutes and enables or disables access. I first thought about changing Docker networking so the cloudflared container could reach the host, but I am not sure how to do that safely. Another idea was to run an SSH server in a temporary container, connect to that through the tunnel, and then SSH from the container to the host, although running SSH in a container may not be ideal.
I would prefer not to modify the host SSH configuration in a way that could lock me out over the local network. The Raspberry Pi has limited resources, and I want to use a browser-based solution because installing a client such as cloudflared or a VPN is not possible on the work computer. What would be a secure and practical way to implement on-demand remote SSH access?
4 Answers
You probably do not need an SSH container. Since the connection is going through a Cloudflare tunnel, put the SSH application behind an Access policy and make that policy the on/off control. You can require strong identity authentication and, if available, an additional approval or short-lived access rule. This avoids exposing a new port and avoids giving a container unnecessary privileges on the host.
What you are describing resembles port knocking: a hidden trigger temporarily adds a firewall rule that permits SSH. However, a custom curl endpoint and five-minute cron polling are more complicated and easier to get wrong. If you use this approach, use a signed or authenticated trigger, a short timeout, firewall rules limited to the tunnel source, and key-only SSH authentication. Do not rely on simply moving SSH to a different port.
Port knocking is less relevant if the service is only reachable through a Cloudflare tunnel, because there may be no public SSH port available to knock on. Controlling the tunnel route or its access policy is a better fit here.
A VPN overlay such as WireGuard or Tailscale is usually the simplest secure design. Connect the remote device to the private network, then use the host's normal SSH service. You can keep SSH restricted to the VPN interface and avoid publishing it through the tunnel. Tailscale is especially easy to set up, while WireGuard gives you more direct control and has very little overhead on a Raspberry Pi.
The browser requirement makes a VPN less useful if the work computer cannot install software, but it is still a good option for devices you control.
You can leave SSH running and focus on reducing its attack surface rather than repeatedly starting and stopping it. Disable password authentication, use public-key authentication only, restrict login to a specific user, disable root login, and apply firewall rules so SSH is reachable only from the private network or tunnel. If you still want time-based access, change the firewall rule rather than modifying Docker networks or running a second SSH server.
Keeping local-network SSH unchanged while controlling only the external route is a sensible compromise. That way an accidental failure in the automation does not lock you out over LAN.
That is cleaner than a cron job, especially because there may not be any directly exposed port for traditional port knocking to reach. The tunnel and access policy can handle the WAN exposure without changing the host's SSH daemon.