Sessions, File Transfer & Supervision

Everything that happens when someone actually reaches a host: the browser terminal, SFTP file transfer, what gets recorded, and what an administrator can do about a session that is already running.

The browser terminal

A session starts from Hosts (or the terminal icon inside Zabbix). SeyalRun resolves which credential you're entitled to use for that host, opens the SSH connection from terminal-service, and streams it to an xterm.js terminal over a WebSocket. The credential is unwrapped by the service — it is never sent to the browser.

Sessions are held open only while you're connected; they expire on the same two clocks as your login (SESSION_IDLE_MINUTES, SESSION_ABSOLUTE_HOURS — see Security Model).

Zones and jump hosts

If the target host sits in a zone with a gateway, SeyalRun builds the ProxyJump chain for you: the root ancestor zone's gateway connects first, and the target's own zone gateway is the last hop before the host. Nested zones are allowed; cycles are rejected when the zone is saved, not at connect time.

Command filtering

Commands are extracted as you submit them and matched against the command filters that apply to your user/host scope. Each filter has a command group (a set of regex patterns), a priority, and an action:

Action	Effect
allow	Explicitly permit — useful as a high-priority exception above a broad deny
deny	Block the command; it never reaches the host
confirm	Pause and ask the operator to confirm before the command runs
default_deny	A block-all marker for that scope: anything not explicitly allowed is denied

Every matched command is written to the session's command log and the audit log with the filter that matched and the action taken — including the ones that were denied, which are the interesting ones.

Filters are configured in Admin → Security (command groups first, then filters). They're fetched when the session opens and refreshed periodically, so tightening a filter affects sessions already running, not just new ones.

SFTP file transfer

Every SSH session carries a file browser: list, download, upload, rename, mkdir, and delete on the remote host, over the same authenticated session and the same authorization. Uploads support drag-and-drop.

Transfers are capped at 1 GiB per file and streamed in chunks, so a large file doesn't mean a large memory footprint. Both directions check the limit — an oversized download is refused before it starts, and an upload that grows past the limit mid-stream is cut off — and both refusals are audited with the path and size. edge-proxy allows 1 GiB + 1 MiB of body so the app's own limit is what you hit, and you get its message rather than a raw nginx 413.

Recording and playback

Sessions are recorded frame-by-frame and replayable from Sessions. Playback is a terminal replay, not a video file — you can read and copy text out of it.

Recordings can be tiered to S3: recording-service runs an hourly task that moves local recordings older than RECORDING_TIER_AFTER_DAYS to the configured bucket, and purges past retention. This only happens when an admin has routed the recording category to S3 in Admin → Log Backend — it is off until you ask for it.

Live supervision

An administrator (or the session's own owner) can join a session that is currently running. Three distinct capabilities, deliberately separated because they are different levels of intrusion:

Capability	What it does
Join	Watch the session's output live, read-only. Anything a watcher types is dropped server-side and never reaches the SSH connection.
Takeover	Send input into the session. One controller at a time — and the operator is told, in their own terminal.
Terminate	End the session from inside the joined view.

Takeover announces itself on purpose. A PAM that let an administrator silently drive someone else's shell would write audit rows naming the wrong person for every command typed.

Joining is audited too. A supervision feature that leaves no trace of the supervisor fails at the one question it exists to answer — who was watching?

Sessions can also be killed outright (DELETE) from the session list, and all of a user's sessions can be terminated at once when their access is revoked.

Who can do what

Action	Who
Open a session on a host	Anyone with an authorization granting ssh on that host
Transfer files	Same authorization, sftp action
Watch / take over / terminate someone else's session	admin, superadmin — or the session's owner

Being able to terminate any session is a strictly higher privilege than being able to merely watch one, which is why watching reuses the same gate rather than adding a separate grant.

For agents

AI agents do not get an interactive shell — there is no "run this command" MCP tool. An agent that must change a host does it through run_automation against an approved job template. See AI Agents & MCP.