CloudSSH: a browser SSH client that implements the SSH-2.0 stack itself on Cloudflare Workers

SSH from a browser with no backend to run

CloudSSH is a serverless web SSH terminal that connects to your servers from a browser, built on Cloudflare Workers. The README's key claim is that it uses the Workers TCP Sockets support to parse and forward the SSH protocol at the edge, so there is no self-hosted backend server: it is a pure frontend plus Workers.

The user is someone who wants to reach servers from any browser without installing an SSH client, and who would rather deploy to Cloudflare's edge than run and secure their own relay. The README leans on a cyberpunk UI and a zero-server-cost pitch, but the substance is that the whole SSH path lives in Workers code.

What makes it technically notable is that the SSH implementation is its own. The README states it is a fully self-developed SSH-2.0 protocol stack that depends on no third-party SSH library, with all cryptographic operations built on the Web Crypto API. Writing an SSH stack from scratch on browser and Workers crypto primitives is an unusual and demanding choice, and it is the core of the project. It is Apache-2.0, with Chinese and English READMEs.

A hand-written SSH-2.0 stack and its crypto choices

The README is specific about the cryptography, which is the part that has to be right. Key exchange supports Curve25519-SHA256, preferred, and ECDH-NISTP256, chosen to work with a range of servers including Dropbear. The transport uses AES-256-GCM or CTR with HMAC-SHA2 integrity. RSA authentication defaults to RSA-SHA2-256/512, and the legacy `ssh-rsa` SHA-1 is only allowed under an explicit compatibility setting, which is the correct default in current times.

Authentication is broad: standard password auth, RFC 4256 keyboard-interactive multi-round auth including OTP and multi-field prompts, and OpenSSH-format Ed25519, ECDSA P-256/P-384/P-521 and RSA private keys. Host verification follows trust-on-first-use: the README says the SHA-256 host-key fingerprint is extracted and shown on first connect and cached locally and in the API to detect spoofing on later connections.

The README also describes reliability details that only matter when you write the protocol yourself, such as reading packet state per-packet to handle a server that merges `SSH_MSG_NEWKEYS` and the first encrypted packet into one TCP block. That level of detail is a sign the stack is a real implementation, not a shim, though it also means the security rests on this code being correct rather than on a battle-tested library.

Deploying by binding the repo to Cloudflare

CloudSSH is deployed rather than installed locally, and the README's recommended path needs no local environment. You fork the repository and, in the Cloudflare Dashboard, bind it to GitHub so Cloudflare builds and deploys the Worker and frontend automatically on each push, with an optional setting to auto-sync the upstream version. The technology stack is TypeScript, Vite, Tailwind CSS and xterm.js with the WebGL addon for hardware-accelerated terminal rendering.

Because the deploy target is Cloudflare's platform, the moving parts are configured through environment variables and Cloudflare bindings rather than a shell installer. The README documents optional configuration for Turnstile human verification and GitHub OAuth login with server management, so an operator can gate access and persist saved servers. Saved credentials are stored per-user in SQLite encrypted with AES-256-GCM, and each terminal session is managed by an independent Durable Object, with the active SSH TCP connection keeping the session awake.

For local development the repository is a standard Vite frontend project, but the intended and documented route to a running instance is the Cloudflare GitHub binding, which is what makes the zero-server-cost claim real: the edge platform runs it, and you operate configuration, not infrastructure.

The security surface is a self-written stack you must trust

The honest limitation is the flip side of the headline feature. A from-scratch SSH-2.0 implementation on Web Crypto means the confidentiality and integrity of your sessions depend on this code, not on OpenSSH or a mature library. The README's care, modern KEX, AES-GCM, SHA-2 defaults, TOFU fingerprints, is reassuring, but a hand-written crypto stack is exactly where subtle bugs live, and a security-sensitive user should weigh that before routing production access through it.

The architecture also places a Worker in the middle of every session. The browser-to-Worker hop is HTTPS/WSS and the Worker-to-server hop is full SSH, and the README says credentials are decrypted server-side and passed internally by one-time token so the browser never holds plaintext, with SSRF and DNS-rebinding protections and memory-based rate limiting. That is a thoughtful design, but the Worker still terminates and re-originates the SSH connection, so you are trusting the deployment, and Cloudflare, with that position.

The README is candid about a mobile edge case too: if the mobile OS fully reclaims the page, the current shell still cannot resume seamlessly. That is inherent to a browser-hosted terminal rather than a defect.

Against a native client or a self-hosted web terminal

The alternatives are a native SSH client like OpenSSH, or a self-hosted browser terminal such as one backed by your own relay. A native client is the security baseline: a mature, audited implementation running on your machine with no third party in the path. A self-hosted web terminal gives browser access but requires you to run and secure the backend.

CloudSSH occupies a different point: browser access with no backend to run, at the cost of a Worker in the path and a self-written SSH stack. Its jump-host support (RFC 4254 direct-tcpip chaining up to three levels without needing ssh, nc or socat on remote hosts) and one-time shareable authorizations with hashed, single-use capability tokens are features a native client does not offer out of the box. Choose a native client when you want the audited baseline and do not need browser access. Choose a self-hosted terminal when you want browser access under your own backend. Choose CloudSSH when the zero-backend, edge-deployed model and its sharing and jump-host features matter more than routing through your own or Cloudflare's infrastructure.

Apache-2.0, auto-sync deploys, and what to verify first

CloudSSH is Apache-2.0, so it can be forked, self-deployed and modified commercially with attribution and the patent grant. That fits a tool most people will run as their own Cloudflare deployment, and the documented upstream auto-sync makes keeping current largely automatic once the GitHub binding is set up.

Upgrade cost is therefore low on the deployment side and concentrated on trust: because the SSH and crypto code is the project's own, each update changes the code your session security depends on, so a security-conscious operator should track releases and the changelog the README links rather than blindly auto-syncing production access.

The concrete first step is to stand up a personal deployment and verify the host-key trust flow before relying on it: connect to a known server, confirm the SHA-256 fingerprint shown on first connect matches what you expect, and check that a changed fingerprint is flagged on reconnection. Enable Turnstile and GitHub OAuth if the instance will be reachable by others, since an open web SSH gateway is a high-value target, and confirm saved credentials are the per-user AES-256-GCM encrypted entries the README describes.

Editorial conclusion

Use CloudSSH if you want browser-based SSH with no backend to run and are comfortable deploying to Cloudflare's edge: the pure-TypeScript SSH-2.0 stack, jump-host chaining and one-time shareable authorizations are its real draws. It is the wrong choice for anyone who needs an audited, battle-tested implementation in the path, since the SSH and crypto code is self-written and a Worker terminates every session, or who is unwilling to trust a hosted relay with production access. Before relying on it, deploy your own instance, verify the TOFU host-key fingerprint on first connect and that a changed one is flagged, and enable Turnstile and GitHub OAuth if others can reach it.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. newbietan/CloudSSH on GitHub
4. Project website
5. README