SSH in the Browser: When a Web Terminal Beats a Native Client

There are days when you cannot install a terminal client: a locked-down corporate laptop, a borrowed machine, an iPad at 2 a.m. when the database falls over. A browser-based SSH client solves availability — the client is a tab, the credentials live server-side, and every session is logged in one place. Used with discipline, it is a legitimate operations tool rather than a workaround.

Where the web terminal wins

• No client installation: useful on managed Windows machines without admin rights, and for letting a teammate run one command without onboarding them to key management.
• Consistent access from anywhere: hotel networks and restrictive firewalls that block outbound port 22 still pass HTTPS to your own web host.
• Central audit trail: a native terminal leaves logs scattered across every laptop that ever connected. A web-based client records connection time, source IP, target server and user in one database — the trail you wish you had when something went wrong at 03:14.
• Credential isolation: passwords and keys are stored encrypted and never touch the client machine, which removes the “key copied to a personal device” class of incident.

Keeping it secure

The browser client relocates trust to the web application, so secure it like any privileged web service:

1. Run it only over HTTPS with a valid certificate; credentials and terminal bytes both traverse the connection.
2. Gate access behind authentication and, where possible, a permission flag — not every account holder needs shell access to every stored server.
3. Prefer key-based authentication to the target servers over passwords, and scope each stored credential to one host.
4. Treat stored secrets seriously: encryption at rest (AES-256-GCM or similar), and delete server entries the moment a server is decommissioned.
5. Enable the connection log and actually read it. Reviewing who connected where, when, from which IP weekly is cheap; reconstructing it after an incident is not.
6. Give each user the narrowest target list that works. A web terminal with forty stored servers and shared credentials turns one compromised account into a fleet-wide incident; one that holds the two servers a person actually maintains contains the blast radius.

Where it does not win

Heavy workflows — tmux-driven multi-session work, port forwarding, SCP of gigabyte files, agent forwarding — remain native-client territory. The browser terminal is for intervention and maintenance, not for full-day development. Knowing which tool fits which moment is the whole skill: keep the native key workflow for deep work, keep the web terminal as the always-available fallback and as the audited path for ad-hoc access by multiple people.

The browser SSH terminal on WhoDNS implements exactly this model: stored servers with encrypted secrets, a full xterm-style terminal in the tab, and a connection log visible to administrators — access to your servers from any machine with a modern browser, without installing a single binary.