Reach hosts behind Cloudflare Access
Connect to a host published as a Cloudflare Access application. Nothing listens on the public internet — the tunnel runs to Cloudflare's edge, which decides whether you are allowed through.
Access controls reachability, not login
This is the important distinction, and it shapes how the app behaves. Cloudflare Access decides whether you may reach a host. It does not log you in. The SSH server behind it still authenticates you normally.
So unlike the AWS and Google Cloud modes, hosts using Access keep their own password or key — including a hardware-backed key or a YubiKey, which combine well with it. Access answers "should this person reach the host", the key answers "who are they".
Service tokens, not browser login
The app authenticates with an Access service token — a client ID and secret you create in the Zero Trust dashboard. The interactive browser flow that cloudflared defaults to caches a per-device JWT and expects a browser to be sitting there, which is the wrong shape for reconnecting on a phone.
The token must be attached to a policy on each application you want to reach. A token with no matching policy is refused in exactly the same way as an invalid one, which is a common and confusing first-run problem — so the app says so when it happens.
What you need
- A Cloudflare Zero Trust account. The free tier is generous and covers this.
- A self-hosted Access application in front of your SSH host.
- A service token with a policy allowing it on that application.
In testing. Built against cloudflared's documented behaviour but not yet confirmed against a live Access application in our own testing. Pro feature.