How to record operation videos of SSH sessions on a server

You can capture SSH sessions on the server itself and turn them into replayable recordings. Several methods make this possible: the built-in script command, asciinema, ttyrec, and commercial session-recording gateways such as Teleport and JumpServer. Each option captures terminal activity at the pseudo-terminal, so the output plays back like a video of the session.

Your real question is practical. Which method fits your environment, and how do you implement it today? The answer depends on your goals. Some teams need quick capture on a single host. Others need shareable replays, classic compatibility, or centralized compliance controls. This guide helps you record operation videos with the approach that matches your audit, troubleshooting, or training needs.

How SSH recording works

Text logs vs. replayable recordings

A plain text log stores the characters an operator typed and the output the server returned. You get a flat transcript. That transcript tells you what commands ran, yet it loses the order and rhythm of events. A replayable recording keeps the same content plus timing data. Each keystroke and each line of output carries a timestamp. Playback then reproduces the session at the original pace, so you watch a command execute and see the result appear seconds later, just as the operator saw it.

Escape sequences make the second difference. Terminal programs send control codes for colors, cursor movement, and full-screen redraws. A text log either strips these codes or stores them as unreadable noise. A recording preserves them, and a player interprets them during playback. Menus, progress bars, and interactive editors therefore render correctly. You can scrub through the timeline and pause on the exact moment a configuration change went wrong.

Server-side capture and the pty

Every SSH login allocates a pseudo-terminal, or pty, on the host. The shell, the commands, and the applications all read from and write to that pty. Capture at this layer and you sit between the operator and the shell. Nothing reaches the process without passing through your capture point.

This placement solves a common gap. Client-side tools record only the machines where someone installed them. An operator on a personal laptop, a jump host, or a tablet bypasses that software entirely. Server-side capture follows the session itself, so the recording starts the moment authentication succeeds. The operator’s local setup stops mattering. One configuration on the host covers every person who connects, and the archive stays consistent across teams and shifts.

Methods to record operation videos

Recording with the script command

The script utility ships with most Linux distributions as part of the util-linux package, so you need no extra install and no configuration file. It writes everything that passes through your terminal to a file, including timing data when you request it.

Start a capture with script session.log. The tool opens a new shell, and every keystroke and line of output lands in that file. Type exit to close the recording. Add the -t flag to store timing in a separate file: script -t timing.log session.log. You then replay the session with scriptreplay timing.log session.log. The replay honors the original delays, so the result looks like a video of the session. The player also accepts a speed divisor, which lets you skim a long session quickly. Keep the timing file beside the session file, because the player needs both.

For automatic capture, place the command in a user’s shell profile. A line such as script -q -a /var/log/sessions/USER-(date +%s).log appends each login to a timestamped file. The -q flag suppresses the startup banner. This approach gives you a lightweight way to record operation videos on any host without new packages. Pair the profile line with log rotation, so old files do not fill the disk. Keep in mind that script stores raw terminal output, so a player must interpret escape codes correctly. Test one replay before you rely on the archive.

Recording operation videos with asciinema and ttyrec

asciinema produces compact, shareable casts. Install it through your package manager, for example apt install asciinema or pip install asciinema. The tool needs Python, which most servers already carry. Confirm the interpreter version meets the tool’s requirement before you install. Run asciinema rec demo.cast to begin. Press Ctrl-D to stop. Play the file back with asciinema play demo.cast, or upload it to asciinema.org for a link your team can open in a browser. The cast format stores text and timing, so files stay small. You can cap idle gaps with the --idle-time-limit option, and a config file under the user’s home directory sets defaults for every new recording.

ttyrec follows a similar model with a longer history. Install it from your distribution’s repositories, such as apt install ttyrec. Run ttyrec session.tty to start and Ctrl-D to finish. Replay with ttyplay session.tty. The -a flag appends to an existing file, which helps when you want one archive per operator. The format enjoys broad player support, which helps when you must open old archives. Community scripts convert ttyrec files to other formats when you need them. Both tools capture from inside the session, so they suit operators who want personal recordings.

For fleet-wide capture, managed gateways such as Teleport and JumpServer record every session at the proxy layer. They add centralized storage, access policies, and search. Each recording carries metadata such as the user, host, and start time. You configure the gateway once, and all traffic through it becomes replayable. Deployment takes more planning than a single command, yet the payoff is uniform coverage. Review the vendor’s documentation for supported protocols and storage backends. This option fits teams that need consistent coverage across many servers.

Comparing recording methods

Performance and cost

Each method adds some load to the server, and the size of that load depends on where the capture happens. The script command runs as a local process inside the login shell. It writes raw terminal output to disk, so the overhead stays low and predictable. asciinema and ttyrec work the same way, with a small process attached to the session. Their cast and tty files store text plus timing, so archives stay compact and cheap to keep. Managed gateways such as Teleport and JumpServer add a proxy layer. That layer handles encryption, storage, and indexing for every connection, which raises resource use on the gateway host. You trade some compute for centralized control.

Cost follows the same pattern. The three command-line tools ship free with most distributions or install from public repositories at no license fee. Your real expense is storage and staff time to set up rotation and access rules. Commercial gateways carry licensing and infrastructure costs, and those costs scale with seats and servers. A small team with a handful of hosts will find the built-in tools cheaper to run. A large fleet with many operators often finds the gateway cost easier to justify, because one platform replaces scattered scripts.

Use case fit matters as much as price. Pick script when you want capture on a single host with zero setup. Choose asciinema when you need a link a colleague can open in a browser. Reach for ttyrec when you must open old archives with long-standing player support. Select a managed gateway when you need uniform coverage across many machines and a searchable index. You can also mix methods, for example asciinema on developer boxes and a gateway on production.

Compliance fit

Compliance needs shape the choice more than raw performance does. Auditors want proof that every session was captured, that the archive stayed intact, and that only authorized people can view it. The command-line tools give you the capture, yet they leave tamper protection and access control to you. You must lock down file permissions, ship logs to a central store, and keep an audit trail of who read what. That work is doable, and many teams handle it well with careful scripting.

Managed gateways build those controls in. They tie each recording to an authenticated identity, store it in a central backend, and log every playback. That design suits regulated environments where you must show a complete chain of custody. The trade-off is dependency on the vendor and a heavier deployment.

Match the tool to your audit obligation first, then to your budget. A free tool with weak access control can cost more in a compliance review than a licensed platform.

Whichever path you take, test one replay end to end before you scale. Confirm the timing looks right, the colors render, and the file opens in your chosen player. Then roll out with a retention policy and a clear rule for who can watch. That habit keeps your effort focused on the goal behind the capture: audit, troubleshooting, or training. Teams that record operation videos with this discipline get archives they can trust when a question arises months later.

Recording best practices

Storage and retention

Send recordings to a central location, not the local disk of each host. A shared mount, an object store, or the gateway’s own backend keeps files together and survives a server rebuild. Local-only files vanish when the machine is replaced, and they scatter across hosts as your fleet grows. Central storage also lets you apply one retention rule to every archive.

Set a retention period that matches your audit obligation and your disk budget. Keep recordings long enough to answer a question raised months later, then delete them on a schedule. Automate rotation with a cron job or your log management tool. Test the deletion job before you trust it, because a broken cleanup script fills disks quietly. Teams that record operation videos for incident review often keep a shorter window than teams that record for compliance.

Security and access

Treat a recording as sensitive data. Sessions can contain passwords typed in plain text, customer records on screen, and internal hostnames. Restrict read access to the people who need it, and log every playback. File permissions alone are weak protection on a shared host, so prefer a central store with role-based access.

Protect against tampering. Write recordings to append-only storage or a backend that keeps an immutable copy. Compute a checksum when the file closes and store it separately, so you can prove later that nobody edited the archive. Pair each recording with an audit trail that names the operator, the host, the start time, and everyone who watched the replay. That chain of evidence turns a raw file into something an auditor will accept.

Test one replay end to end before you scale. Confirm the timing, the colors, and the access rules all work as intended.

Pick the tool that matches your goal. Use script for quick built-in capture on a single host. Choose asciinema for lightweight, shareable replays. Reach for ttyrec when you need classic compatibility. Select a managed gateway such as Teleport or JumpServer for compliance-heavy environments.

Start small. Pilot one server, then verify replay fidelity before you scale. Check the timing, the colors, and the player support. Roll out next with retention and access policies in place.

Finally, match the tool to your purpose. Record operation videos for audits, troubleshooting, or training, and let that aim guide every choice. A clear goal keeps your archive useful months later.

FAQ

Does a session recording capture passwords typed at a prompt?

Yes. Capture happens at the pseudo-terminal, so every keystroke lands in the file, including passwords and secrets shown on screen. Treat each archive as sensitive data. Restrict playback to authorized staff and store files in a protected backend. Never share a raw cast file through an open link.

Can you capture a session without the operator knowing?

You can, and many compliance programs do exactly that. Server-side capture runs outside the operator’s control, so it starts at login regardless of local setup. Check your local rules and your employment agreements first. In many jurisdictions you must notify users that sessions are monitored.

How much disk space do these recordings consume?

Text-based casts stay small because they store characters and timing, not video frames. Actual size depends on session length and output volume. Measure a few real sessions on your own hosts, then size storage from that sample. Set a retention window and automate cleanup so archives do not grow without limit.

Does the script command work on every Linux server?

It ships with util-linux, which most distributions include by default. Confirm the package exists on your base image before you rely on it. Minimal containers and some embedded systems may omit it. Run a quick test capture and replay on one host before you standardize.

How do you confirm a recording plays back correctly?

Replay one file end to end in your chosen player. Check that timing feels right, colors render, and full-screen programs redraw properly. Verify the file opens on a machine other than the one that captured it. Repeat this check after any upgrade to the tool or the player.