Opening a remote terminal session

Remote terminal gives a technician an interactive shell on an enrolled endpoint directly from the console. It uses the agent's existing outbound connection, so there is no inbound port on the endpoint, no jump host and no VPN requirement.

The authorisation model is worth understanding rather than treating as plumbing. Opening a session requires a short-lived ticket issued by the platform to an authenticated operator. The WebSocket connection is established using that ticket, and the resulting session is bound to the operator identity. The session is recorded in the agent action log.

Three properties follow from that, and each one matters. Sessions cannot be opened anonymously. Sessions cannot be opened by replaying an old connection, because tickets are short-lived. And every session is attributable to a named person, which is what makes the audit trail usable rather than decorative.

In practice, open the endpoint in the console and start a terminal session. You get a shell with the privileges the agent runs under, which on most platforms is elevated. Treat it accordingly — this is a production machine, frequently someone's only machine, and there is no undo.

A few habits make remote sessions safer. Say what you are doing in the ticket before you do it, so that a colleague picking the ticket up later can reconstruct the state. Prefer reading over writing until you have confirmed your theory. And on a user-facing machine during working hours, tell the user — a terminal appearing to act on its own accord is alarming, and the resulting call to your service desk costs more than the courtesy would have.

Because sessions are attributable and logged, the terminal is also the honest answer to "who touched this machine". When something changed and nobody knows why, the action log usually does.