Session recording: what your logs are not telling you, and why admins end up wishing they had it

Every infrastructure team keeps logs. Far fewer keep recordings. The distinction sounds academic until the afternoon something breaks and the only honest answer to “what did we actually do on that box?” is a shrug and a scrollback buffer that closed an hour ago.

In this article

• What a session recording is, and how it differs from a log line
• The accountability gap that logs cannot close
• Shared accounts, and why they break attribution
• What auditors actually ask to see
• The four ways session recording quietly fails
• Storing recordings without drowning in them
• Playback, search, and the value of text
• Retention, history, and knowing what you have
• How MangoSSH handles it

Overview

Two different things get called “session logging”, and conflating them is the root of most disappointment.

Metadata logs

This is what sshd and your syslog collector give you for free: a user authenticated, from an address, at a time, and later disconnected. It is cheap, it is structured, and it ships to your SIEM without argument. It tells you that access happened.

Session recordings

A recording captures the session itself — the keystrokes, the command output, the timing. It tells you what happened. For a terminal, that means the byte stream the shell wrote to the screen, with timestamps, replayable at the pace it originally ran.

The gap between the two is not a matter of detail. It is the difference between knowing a door opened and knowing what walked through it.

Side-by-side comparison

The accountability gap

Consider a concrete case that comes up in insider-risk work. An engineer opens a session, prints the contents of a sensitive file to the terminal, reads it, and closes the session. No file is copied. No package is installed. Nothing is written.

Your syslog records exactly one meaningful fact: a session opened for that user, and later closed. Every control you own reports green. The data left the building through a screen, and the log has no vocabulary for that.

A session recording shows the command and the output. That is the whole difference, and it is why teams that have been through one serious investigation tend to come out of it wanting recordings.

Shared accounts break attribution

Walk into most audits and you will find generic accounts — root, admin, sa — shared among a handful of engineers, with no check-out process and a password that has not changed in a year. Metadata logging attributes every one of those sessions to the same string. It is accurate and completely useless.

Recording does not fix this on its own, but it changes the shape of the problem. Behaviour becomes visible even when identity is not, and pairing recordings with a check-out workflow — who requested the account, when, and for how long — restores individual accountability without forcing you to abolish shared accounts that exist for good operational reasons.

What auditors actually ask for

The frameworks are more specific than people expect. PCI DSS 4.0 requirement 10.2 and SOC 2 criterion CC6.8 both want evidence that privileged access is recorded, not merely that it is authorised. ISO 27001 and HIPAA programmes lean on the same material.

In practice, three properties decide whether a recording counts as evidence:

Completeness

Full interactive sessions, not login metadata with a recording bolted on for the systems that happened to be easy.

Integrity

Protected from alteration. A recording an administrator can quietly edit is not evidence about administrators.

Attribution

Tied to a verified identity, so a session maps to a person rather than to a credential.

Coverage matters as much as capability. If a high-risk system can still be reached by an unrecorded path, you do not have a recording programme — you have a recording habit with a known blind spot. Auditors respond far better to a team that can state that boundary plainly than to one that discovers it during testing.

Where session recording goes wrong

Four failure modes account for most of the disappointment.

Recordings nobody can find

The most common one, and the most embarrassing. Recording gets switched on, files accumulate somewhere on disk, and nothing in the product ever lists them. They exist and they are unreachable. Six months later someone needs one and discovers the feature was decorative.

Plaintext on disk

A terminal recording is the complete byte stream of the session — including anything that was echoed to the screen. A token pasted into a command, a secret printed by a misbehaving script, the contents of a config file someone cat-ed to check. Teams routinely encrypt their credential store and then leave recordings of those credentials sitting beside it in the clear.

Storage that grows without a plan

Video-based session capture is heavy, and heavy storage gets deleted early. Retention policies quietly shorten, or recording gets limited to “critical” systems, and the coverage gap opens up again for budgetary rather than technical reasons.

Recordings you cannot search

A recording you can only watch is barely better than no recording when you are trying to answer “did anyone touch this config in the last quarter?”. Scrubbing through video to find a command is a task nobody does twice.

Storing recordings without drowning

The single decision that determines whether a recording programme is sustainable is the format.

Screen capture produces video — large, opaque, and expensive to keep. Terminal capture produces text with timing, which is smaller by orders of magnitude. The asciicast format used by asciinema is the common shape here: a JSON header describing terminal size and start time, followed by timestamped output events. Recordings compress extremely well; zstd typically brings them to around 8% of the original.

The practical consequence is that keeping every session for a year stops being a budget conversation. A text recording of an hour-long session is measured in kilobytes.

Two properties are worth insisting on when the store is designed:

• Encryption at rest, using the same key material protecting your other secrets. A recording store is a secret store, whether or not it was designed as one.
• Append-only writing, so a long session is durable as it runs rather than held in memory and written at disconnect. A session that runs for days should not be a session that loses everything if the client crashes.

Playing it back

Text-based recordings have a property video does not: the playback view is real text. You can select it, copy a command out of it, and paste that command somewhere useful. Search works. Diffing two sessions works.

Timing matters too. Replaying at the original pace shows hesitation, retries, and the order things were attempted in — context that a list of commands strips out. When you are reconstructing an incident, the rhythm of a session is frequently the part that explains it.

Graphical sessions are harder. There is no text to recover, so the practical approach is to record screen deltas rather than full frames, which keeps the size sane while preserving what was on screen.

Retention and history

A recording store is only useful if you can answer questions about it without opening it. Which host, which user, how long, when. That means an index that stands apart from the recordings themselves.

It sounds like a small design point. It is not: if listing your session history requires decrypting every stored body, the history page becomes slow enough that people stop opening it, and a feature nobody opens is a feature you do not have.

The same reasoning applies to retention. A cap on stored sessions, an explicit purge, and a way to mark the ones that matter are what keep a store from becoming an undifferentiated heap that is technically compliant and practically unusable.

How MangoSSH handles it

MangoSSH keeps every recorded session in one encrypted, browsable store, and the design is a direct response to the failure modes above.

Encrypted with your vault

Recordings ride the Personal Vault's existing lock state. A .cast file is the complete terminal byte stream; leaving it in plaintext next to an encrypted host list was an inconsistency worth closing.

Index separate from bodies

The list of sessions is its own encrypted file, so opening your history does not decrypt megabytes of session content just to render names and dates.

Appended as the session runs

Each segment is sealed and appended independently. Appending costs the same whether the log is 1 KB or 1 GB, memory stays flat on a session running for days, and a crash does not take the recording with it.

Text for terminals, deltas for screens

SSH sessions are stored as asciicast v2. RDP and direct sessions use a dirty-rectangle format, so a graphical session stays a reasonable size.

Separated by profile

A Work profile's recordings never appear in Personal.

Retention you control

A cap on stored sessions, explicit purge, bookmarks for the ones worth keeping, and export as an action on a stored recording rather than the only way to keep one.

The point of all of it is unglamorous: recordings that are findable six months later, safe to store, and cheap enough that nobody proposes turning them off.