For most small operations teams, server access means three things stacked on top of each other: a VPN, a bastion host, and whatever terminal each engineer prefers. The stack survives because it works. It also eats more maintenance time than anyone budgets for, and most of that time is invisible until you write it down.

Where the time actually goes

Start with onboarding. A new engineer or a short-term contractor needs a VPN profile, a client install that fights with whatever endpoint security their laptop runs, an SSH keypair, and that key copied into authorized_keys on every host they will touch. On a good day this is an afternoon. With a contractor on a personal laptop it can stretch across a week of back and forth.

Offboarding is worse because it fails silently. The day someone leaves, their laptop still holds working private keys. Unless you rotate every key on every host they touched, revoking the VPN account is the only thing standing between that laptop and production. Most teams rotate eventually. Few rotate the same day.

Then there is the bastion itself. It needs patching, monitoring, and an answer for the day it goes down. It concentrates risk in one box while producing a thin audit trail: auth.log records who connected and when, but not what happened inside the session. If someone copies a database dump through the bastion with scp, the log line looks much like a routine deploy.

What a browser gateway changes

The browser model moves the SSH endpoint off the laptop. A gateway, self-hosted or a service, holds the credentials and terminates the session; the browser renders a terminal over an encrypted WebSocket. The gateway reaches hosts over your private network or through an outbound-only connector, so you can stop exposing port 22 to the internet.

Three consequences follow from that shift.

Private keys stop living on laptops. The gateway holds them, or issues short-lived certificates, so a stolen or departed laptop holds nothing that opens a server. Offboarding collapses into disabling one account in your identity provider.

Access starts from a URL. A new engineer signs in with SSO, sees the hosts they are allowed to see, and opens a session. The afternoon of client setup disappears, and so does the fight with endpoint security, because there is nothing to install.

Sessions become records. Because every session passes through one place, recording and per-session audit logs are a property of the architecture instead of a bolt-on. When a compliance review asks who ran what on the billing server in March, you scrub through the session instead of grepping shell history and hoping nobody used a shared root login.

What to test before you commit

None of this is free, and the failure modes are different from the VPN stack’s. Before moving the team, test these against your own environment rather than the vendor’s demo:

  • Typing feel on a bad network. The gateway adds a hop. From the office it will feel native; test from the worst hotel Wi-Fi someone on your team regularly works from.
  • Large pastes and noisy output. Paste 500 lines into vim, then tail a busy log for ten minutes. Some browser terminals buffer badly under load.
  • tmux and screen. Browser shortcuts and terminal multiplexers fight over the same key combinations. Find out which ones you lose before your team does.
  • File transfer. If there is no SFTP or file browser story, engineers will route around the audit trail to move files, which defeats the point of having one.
  • The break-glass path. When the gateway is down and production is on fire, how do you get in? If the answer is a legacy key in a safe, write that procedure down before you need it.
  • Where recordings live. Session recordings are sensitive by definition. Know where they are stored, who can watch them, and how long they are kept.

The tradeoff, stated plainly

You are trading a set of distributed problems - keys on laptops, bastion patching, silent offboarding gaps - for one concentrated dependency. The gateway sees session plaintext and holds the credentials, so you are trusting its operator, its access controls, and its uptime. For a team of five running forty hosts, we think that trade is clearly worth it. The distributed problems are exactly the ones small teams never get around to, and the concentrated one is at least visible. Past a few hundred hosts and several teams you still want the same model, just with more governance wrapped around it.

What tipped it for us was offboarding. Every other cost on the VPN side is annoying but bounded. The stale-key problem is unbounded and quiet, and it is the one an auditor will find.

Where LynxTrac fits

We build LynxTrac, which includes browser sessions for SSH, RDP, and VNC with per-session audit logs and recording, no VPN or jump host required. It is free for two servers, which is enough to run every test above against your own network before deciding anything. The details are on the LynxTrac product page.