Opening an SSH terminal right in the browser is convenient: no client to install, no keys to configure on every computer, and access even from your phone. The natural question is: is it secure? The short answer: it depends entirely on how the platform is built. Here's what happens behind the scenes and what you should demand.
How a web SSH terminal works
Browsers don't speak SSH directly. The typical architecture has three parts:
- Browser: renders the terminal (usually with the xterm.js library) and sends what you type.
- Platform gateway: accepts the connection over a secure WebSocket (WSS) and opens the actual SSH session to the server.
- Your server: receives a regular SSH connection, encrypted like any other.
In other words, the critical piece is the gateway: it holds the credentials and decides who can open each session.
The real risks
- Credential leaks if the platform stores passwords in plain text or sends them to the browser.
- Account takeover: without 2FA, anyone who learns your dashboard password gets access to every server.
- Cross-tenant access on platforms that don't properly isolate each account's data.
- Reusable sessions: connection URLs or tokens that remain valid after they've been used.
- No traceability: not knowing who ran what, and when.
Checklist: 7 controls the platform must have
| # | Control | Why it matters |
|---|---|---|
| 1 | Credentials encrypted at rest | A database leak doesn't expose your passwords and keys. |
| 2 | Credentials never sent to the browser | Malicious extensions or XSS can't capture them. |
| 3 | HTTPS + WSS end to end | Nothing travels in plain text. |
| 4 | Mandatory 2FA | The dashboard password alone isn't enough to break in. |
| 5 | Single-use, short-lived session tickets | A copied or intercepted link can't open another session. |
| 6 | Per-account isolation and per-server permissions | Each user can only reach what they own or what was shared with them. |
| 7 | Command auditing | Traceability for incidents and compliance. |
How EzServer implements each control
- SSH passwords and keys are encrypted and used only on the platform's server.
- To open the terminal, the browser or app receives a single-use ticket, valid for only a few moments, never the credentials.
- Two-factor authentication protects your account.
- Per-server sharing: collaborators use their own accounts and never see the password.
- Commands are recorded in an audit log.
- Connections use keepalives and automatic reconnection; with tmux, the session picks up right where it left off.
Best practices on your server
The platform is one layer; the server itself needs protection too:
# /etc/ssh/sshd_config
PermitRootLogin prohibit-password # root with key only
PasswordAuthentication no # once everyone uses keys
MaxAuthTries 3
ClientAliveInterval 60Add fail2ban to block brute-force attempts and keep the system up to date (apt update && apt upgrade).
Bottom line: a browser terminal is no less secure than local SSH, as long as the credentials never leave the platform's server, the account has 2FA and every session uses a disposable ticket.