SSH · By · 5 min read

Is browser-based SSH secure?

A walk through the actual threat model of browser-based SSH, what it trades away, and what it gains. The answer isn't a one-liner, but it's close.

This is the question that comes up first on almost every security review, and it deserves a real answer rather than a marketing one. So here it is.

Browser-based SSH can be as secure as traditional SSH, and in several specific dimensions it’s more secure. It also moves some of the attack surface to different places, and those new places need different controls than the old ones. If you read all the way through and still think traditional SSH is better for your situation, that’s a legitimate conclusion.

The checkpoints a session passes through. Every one of them logs; none of them depend on a key sitting on a laptop.

The three properties that matter

Security for remote-shell access comes down to three things:

  1. Authentication: only authorized operators can open sessions.
  2. Confidentiality: session content isn’t observable by anyone except the operator and the host.
  3. Audit: you can reconstruct who did what, when.

A browser-based SSH platform can be built to satisfy all three. A traditional SSH setup can too, of course. The interesting comparison is where each is easier or harder to get right.

Authentication

Traditional SSH authenticates with private keys on operator laptops. The cryptography is strong. The operational reality is that keys spread: they get copied to new machines, end up in backup archives, sit in forgotten .ssh directories. Rotating keys across a team is painful enough that most teams don’t do it as often as they should.

In our model, authentication moves up a layer. The operator authenticates to the control plane with SSO (which is where you already enforce MFA, device posture, and conditional access). The control plane mints a short-lived, scoped session token. The browser never holds a long-lived private key.

The trade-off is that you’re now trusting the control plane as your access gate. We mitigate that with mutual TLS between control plane and agents, signed binaries, per-agent enrollment keys, and a policy that the control plane cannot mint sessions without a valid IdP-authenticated operator. It’s a real dependency, but it’s a dependency you’re already making for your IdP.

Confidentiality

TLS 1.3 from browser to relay. The SSH protocol itself from relay to agent. The plaintext of your commands exists only in RAM on three machines: your laptop, the relay (briefly), and the target host. None of those machines persist it.

We also don’t log keystroke content in the session recording (we log keystroke events and paint events, enough to reconstruct a session visually but not to extract passwords typed into prompts). That distinction matters for auditors who are nervous about what’s in the audit log.

Audit

This is where browser-based SSH is unambiguously better than traditional SSH. Every session has a unique ID. Every session is tied to an SSO identity. Every session can be replayed, filtered, and searched from one place.

With traditional SSH, you either rely on the host’s auth.log (which is thin and easy to tamper with) or you deploy an agent-based session recorder on every host (which is expensive to maintain). With a browser-based model, this comes for free as a property of the architecture.

Where the attack surface moves

Three places to watch:

The browser. Malicious extensions and phishing pages can attack your session inside the tab. The mitigations are boring but important: a strict Content-Security-Policy on the control-plane domain, short session TTLs so a compromised token has a short window, and IdP-enforced device posture so you can’t log in from a random machine.

The control plane. If we’re compromised, attackers can mint sessions. We reduce the blast radius with per-agent enrollment keys (an attacker who gets our control-plane database still can’t talk to agents without the per-tenant keys, which live in an HSM). We publish audit events to customer-controlled stores so a compromise can’t silently rewrite history.

The relay. The relay sees encrypted session traffic and metadata. We don’t log session content at the relay, relay keys rotate hourly, and relays run in an isolated network with no access to the control-plane database.

Where it’s better, where it’s not

Better: audit, key management, revocation, contractor access, compliance reporting, onboarding.

Roughly equal: confidentiality (both are fine if configured correctly), protocol security (same underlying SSH).

Worse: offline access (can’t open a session with no internet), ability to debug our infrastructure when our infrastructure is down (you’d need a break-glass path), and the mental model adjustment for senior operators who’ve spent 15 years in ~/.ssh/config.

What the answer comes down to

For a regulated team with auditors, contractors, or anyone operating at scale, browser-based SSH has materially better security properties even if the raw cryptography is identical. For an individual developer with a laptop and hardware key, traditional SSH is perfectly fine.

This isn’t a religious argument, and the answer isn’t the same for everyone.

More on how this works in practice: the features overview, or email [email protected] with questions.

Related posts