SSH session recording, replayable from the console

What actually gets recorded

The event log is always on. It records connections, the commands run inside them, access granted and revoked, every just-in-time request with its decision and approver, settings changes, and lifecycle events such as a user being disabled. It is append-only, and it is the layer an access review is built from.

The session recording is the terminal stream itself, captured in asciinema format and replayed in the console with a scrubber. It answers a different question from the log: not what command was issued, but what the person saw and did, in order, at the speed they did it.

Turning it on

A toggle per target, not a switch for the estate

Recording is set on the target, so production can be recorded while a scratch box is not. That matters more than it sounds: a policy that records everything gets turned off entirely the first time somebody objects, and one that records what is worth recording survives.

What is in which edition

The per-command audit log is in every edition, Community included, and the database query audit runs on by default in all of them. Full session recording and live watch begin at Pro, and the SIEM stream at Ultimate. The editions table carries the full split.

Reviewing what was recorded

Replay a finished session

Recorded sessions carry a play button in the console. The replay runs in the browser, at the original timing or faster, with the whole terminal buffer intact rather than a summary of it.

Watch a live one, and end it

An administrator can shadow a session that is still open, downgrade it from read-write to read-only while the other person stays connected, or close it outright. That is the capability an incident actually needs, and it is the one a recording alone does not give you.

Where the record lives, and for how long

Retention you set

Both layers are kept indefinitely by default and bounded independently: TESSERA_AUDIT_RETENTION_DAYS for the event log and TESSERA_RECORDING_RETENTION_DAYS for the replays. A daily job does the deleting. Keeping replays for ninety days and the event log for seven years is a normal pairing, and it is two variables rather than a support ticket.

A copy outside the broker

On Ultimate and Enterprise, events are posted to your SIEM as they happen, in JSON, which puts a copy somewhere the broker's own administrators do not control. Delivery is best-effort and never blocks a session, so treat it as a second copy rather than as a replacement for the log the broker keeps. How the SIEM stream works.

Why record at the broker rather than on the host

The usual alternatives run on the machine being recorded: script, a shell wrapper, a pam module, an auditd ruleset. They work, and they share one weakness, which is that the thing being watched is also the thing doing the watching. A user with enough privilege can bypass the wrapper, and the recording has to be shipped off the host before it can be trusted.

Recording in the broker inverts that. The session is captured on the way through, by a machine the user has no account on, and it is written before anything on the target could influence it. It is also why there is nothing to deploy: adding a server adds a row, not a rollout. What it does not cover is a session that never went through the broker, which is an argument for closing the direct path rather than for recording twice.

The point of all this

An auditor testing an access control does not want the policy that says sessions are reviewed. They want a named session from a date they picked, with what ran in it. That argument, at length.