Live terminal

Give authorized operators an interactive terminal on a host through Renga, when nothing else will do, with more control and a better record than handing out SSH access. RFD 1 requires live terminal access to be disabled by default and to need authentication, RBAC, agent-side allow/deny policy, short per-session leases, and target-level access rules, with step-up authentication and session recording as organization settings (RFD 19). This RFD designs each, and the installation credentials that terminals and RFD 14's VM operations both need.

An intake key authenticates an organization, not a machine (RFD 3), so anyone holding it can claim to be any installation. That is fine for inventory and RFD 9's observe jobs, and fatal for a terminal.

Each installation therefore generates an Ed25519 key pair in its state directory (mode 0600) and presents the public key on check-in. Renga records the first key it sees for an installation as pending. An owner or admin approves it on the Collectors page, comparing the fingerprint the agent prints locally. From then on, every lease of an operate or interactive job must be signed with the approved key, over the job ID, lease token, and a server nonce. A key change returns the installation to pending, blocks its privileged jobs, and opens a finding. A stolen intake key alone can then report inventory, but cannot take a terminal or VM job.

Approving a key proves installation identity, not which resource it may control. Privileged targeting requires a separately approved, organization-scoped binding between the resource ID and installation ID plus approved key fingerprint. An owner/admin verifies this binding through a trusted enrollment process; shared intake observations, submitted identifiers, source associations, and saved-view membership cannot create or silently change it. Binding changes require explicit approval and invalidate pending authorizations for the old binding.

Grants authorize resource IDs against these trusted bindings, not whichever agent an inventory report currently associates with them. Target sets derived from views or teams must not gain privileged targets through shared-key inventory alone. Renga captures the binding/version in each job and rechecks the grant, organization policy, binding, and approved credential before dispatch and lease. The signed request includes the target and binding version alongside the job ID, lease token, and nonce. Missing, changed, or conflicting bindings block execution instead of redirecting a job to another installation. RFD 14 extends the same rule to the provider and domain identity of a VM.

A terminal session requires all of these:

The browser renders the session with xterm.js, which implements terminal emulation (escape sequences, colors, mouse, paste, and resizing). The relay only carries bytes and window-size changes, so Renga implements no terminal behavior itself. Each keystroke’s round trip adds the browser-to-Renga and Renga-to-agent latency, typically tens of milliseconds, comparable to other relayed web terminals.

Operators may use their own terminal and SSH client instead of the browser. A host behind NAT cannot accept a direct connection, and an agent-generated key would have to be shipped to the user as a secret, so neither is used. Instead:

Recording is an organization setting, on by default (RFD 19). When it is on, Renga records each session’s input and output as an asciicast stream, with timestamps, bounded at 50 MiB per session and kept for one year by default. Command logging is not used as the record, because a shell can always hide a command from it. The user is told before a session starts whether it is recorded. Owners and admins can replay sessions, and every replay is itself logged. With recording off, Renga still records who opened each session, on which host, when, and for how long.

Progress is tracked in the implementation checklist.