SSH over HTTPS
Your servers, from any network
that blocks port 22.
A real SSH terminal in your browser, tunnelled over HTTPS on port 443. Hotel Wi-Fi, corporate firewalls, locked-down guest networks — if a web page loads, you can reach your server.
Nothing to install on your server. No agent, no VPN, no browser extension.
The problem
Port 22 is blocked
Guest Wi-Fi, school networks, and corporate firewalls routinely allow only ports 80 and 443. Your SSH client sits there timing out while every website loads fine.
You are not on your own machine
A borrowed laptop, a locked-down work desktop, a tablet. No terminal, no keys, no permission to install one — and a server that needs attention now.
The usual fixes are heavy
A VPN, a jump host, or an agent installed on every box. All of them are real infrastructure to run, secure, and remember the password for.
How it works
The SSH protocol itself runs inside a Cloudflare Worker. Your browser speaks WebSocket over ordinary HTTPS; the Worker speaks SSH to your server. The firewall only ever sees port 443.
Your browser Your server
┌──────────────┐ ┌──────────────┐
│ xterm.js │ │ sshd │
└──────┬───────┘ └──────▲───────┘
│ WebSocket over HTTPS :443 │ SSH :22
│ (the only port you need) │
▼ │
┌─────────────────────────────────────────────┴───────┐
│ Cloudflare Worker + Durable Object │
│ verifies your session, decrypts your credential, │
│ runs the SSH transport, bridges the two sides │
└──────────────────────────────────────────────────────┘- Create an account. Email and password. Your account password also derives the key that encrypts everything you save.
- Add a server. Host, port, username, and either a password or an ed25519 private key. It is encrypted before it is stored.
- Confirm the host key. On the first connection you are shown the server’s fingerprint. Check it, accept it, and it is pinned — any future change is refused.
- Connect. A full interactive shell, with a pty, colours, and resizing. It works on a phone.
How your credentials are handled
Encrypted before storage
Every saved credential is encrypted with a key belonging to your account alone. That key is itself wrapped by your password, so the database holds nothing usable on its own.
Only readable while you are here
Your encryption key lives in a cookie the page’s own scripts cannot read, and is never stored on the server. A credential can be decrypted only during a request you made.
Host keys are pinned
A server’s identity is fixed on first use, after you confirm it. If it ever changes, the connection stops before your password is sent.
What this does not protect against
Encryption at rest defends against a stolen database copy. It cannot defend against whoever runs the deployment: an operator who compromises the Worker can read the credentials of anyone who signs in afterwards. That is true of every hosted terminal, and it is worth knowing before you paste a root password anywhere. If that matters to you, the source is open — run your own copy, and use per-user accounts on your servers rather than shared root credentials.
What it supports
- Key exchange
- curve25519-sha256
- Host keys
- ssh-ed25519
- Cipher
- aes256-gcm@openssh.com
- Authentication
- password, or unencrypted ed25519 key
One option per layer, on purpose — every one is a modern default that OpenSSH has shipped since 6.5, and the short list keeps the crypto small enough to run inside a Worker.
Passphrase-protected private keys are not supported: unlocking them needs a key-derivation function the runtime cannot provide. Use a password, or an unencrypted key generated for this purpose.
Reach your servers from anywhere
Takes about a minute to set up. Add a server, confirm its fingerprint, and you have a terminal.