What is a browser-based SSH client?
A browser-based SSH client lets you open an interactive shell on a remote server from a normal browser tab — no desktop application, no terminal emulator, and nothing to install on the machine you're sitting at.
Instead of your laptop making the SSH connection, a gateway service does. Your browser holds a secure WebSocket to that gateway; the gateway speaks SSH to the target host and streams the terminal back to you. Because the connection is brokered, the private key never has to sit on the device you're typing on.
That single architectural difference is what makes browser SSH interesting for teams rather than just convenient for individuals: keys live in one audited place, access is granted and revoked centrally, and every keystroke session has a record.
How Onshell.cloud opens an SSH session
You register a host once — address, port, username, and environment — then attach a credential from the encrypted vault. Team members with permission on that host can open a session without ever seeing the underlying password or key.
Clicking a host opens a real terminal built on xterm.js: full colour, resizing, copy and paste, scrollback, and the control sequences your tooling expects. vim, htop, tmux, and less all behave the way they do locally.
The same host can be opened as an SFTP file browser for uploads, downloads, and in-place edits, or — for Windows targets — as an RDP desktop through the gateway. One registry of hosts, three ways to reach them.
Why teams move off desktop SSH clients
Desktop clients scale badly across people. Keys get copied to laptops, `~/.ssh/config` drifts between engineers, offboarding means hunting for which machines held which key, and nobody can answer "who ran that command on Tuesday?" without shell history you cannot trust.
Centralising access fixes the whole class of problem at once. Credentials are stored encrypted at rest and injected by the gateway. Permissions are per host and per role, so an auditor can look without touching and a developer reaches staging but not production. Sessions, file transfers, and admin changes are all written to an audit log with retention that matches your plan.
The practical payoff is onboarding in minutes instead of a day, and offboarding that is one revoked membership rather than a key hunt.
Is a browser SSH client secure?
It can be more secure than the desktop status quo, provided the broker is built properly — which means credentials encrypted at rest with a key the browser never sees, TLS on every hop, short-lived session tokens, and an audit trail that the user cannot edit.
Onshell.cloud encrypts vault entries with AES-256-GCM, keeps secrets server-side so they are never serialised into the browser, supports TOTP and email two-factor authentication, and protects public forms with Cloudflare Turnstile. Every privileged action is written to an append-only audit log.
The honest trade-off: you are trusting a gateway with brokered access, so it matters that access to that gateway is itself strongly authenticated. That is why two-factor, role-based permissions, and audit retention are treated as core features rather than upsells.
Browser SSH client vs a desktop SSH client
A desktop client is still the right tool when you are offline or working alone on your own machine. Once more than one person needs the same servers, the calculus changes.
| Capability | Onshell.cloud | Desktop client |
|---|---|---|
| Works from any browser, nothing installed | Yes | No |
| Full xterm terminal (vim, tmux, htop) | Yes | Yes |
| SFTP file manager on the same host | Yes | Partial — needs a separate tool |
| RDP for Windows hosts | Yes | Partial — needs a separate tool |
| Keys stored encrypted, never on your laptop | Yes | No |
| Per-host, per-role team permissions | Yes | No |
| Central audit trail of every session | Yes | No |
| Offboard someone in one action | Yes | No |
| Shared, reviewed command snippets | Yes | No |
| Works offline | No | Yes |
Frequently asked questions
Is Onshell.cloud a free browser SSH client?
Yes — the Free plan is free forever for one person and covers up to three hosts, browser SSH, SFTP, and the encrypted credential vault, with no credit card. Paid Team and Business plans add more seats and hosts, RDP, shared snippets, longer audit retention, and priority support.
Do I need to install anything on my servers?
No. There is no agent and no daemon to deploy. Onshell.cloud connects over standard SSH on the port you specify, so any host you can already reach with a normal SSH client works as-is.
Can I use my existing SSH keys?
Yes. Paste an existing private key into the credential vault, or store a password. It is encrypted at rest with AES-256-GCM and attached to the hosts you choose. Team members connect through it without ever being shown the key material.
Does the terminal support vim, tmux, and colours?
Yes. The terminal is a full xterm implementation, so 256-colour output, alternate screen buffers, mouse reporting, and resizing all work. Interactive tools like vim, htop, tmux, and less behave exactly as they do in a local terminal.
Is this a good PuTTY alternative?
For teams, yes — and for individuals it removes the install entirely. Where PuTTY manages sessions per Windows machine, Onshell.cloud keeps one shared host registry with centrally stored credentials, role-based access, and an audit trail, reachable from any operating system with a browser.
What happens if my browser tab closes mid-session?
The session is brokered by the gateway, not the tab, so closing the tab ends your view of it and the session is closed and recorded in the audit log. For long-running work, run it under tmux or screen on the host, exactly as you would over a normal SSH connection.
Which protocols does Onshell.cloud support?
SSH and SFTP for Linux and Unix hosts, and RDP for Windows desktops. A single registered host can be opened as a terminal, as a file browser, or as a remote desktop, depending on what it supports.
Open your first browser terminal in five minutes
Free forever for one person. No credit card, no agents to deploy.
Start free