Something changed on a production server last Tuesday. The logs say an administrator logged in at 02:14, and then the trail goes quiet. You know who knocked. You have no idea what they did once inside. That gap is what session recording closes, and it is also why auditors ask for it.
Logs and recordings answer different questions
An access log answers “who connected, from where, and when.” A session recording answers “what happened next.” You need both, because each is weak where the other is strong: logs are small, searchable and easy to alert on, while recordings are heavy but settle arguments.
NIST draws the same line. Its session audit control (AU-14 in SP 800-53) says the capability should let designated users record, view, hear or log the content of a user session, and its guidance notes that session audits “can include monitoring keystrokes, tracking websites visited, and recording information and/or file transfers.” It also says this is “implemented in addition to event logging”, not instead of it.
What Windows gives you for RDP
Windows records the door, not the room. When someone logs on over Remote Desktop, the target server writes event 4624, and Microsoft defines logon type 10 (RemoteInteractive) as a user logging on “remotely using Terminal Services or Remote Desktop.” The event carries the account, the workstation name and the source network address. It also has an Elevated Token flag, which Microsoft says is “Yes” when the session has administrator privileges.
If the person disconnects and comes back, event 4778 logs the reconnection, with the client name and client address. Microsoft’s own monitoring advice for these events is to watch high-value accounts, odd hours and clients that should never connect.
One caveat from Microsoft’s page: the IP address and workstation fields are “populated depending on the authentication context and protocol used.” Some logons arrive with blanks. None of this shows a window, a command or a file that was opened.
What SSH gives you
OpenSSH’s sshd logs connection events. Its LogLevel setting defaults to INFO, and the manual lists the levels from QUIET up to DEBUG3. It warns that “logging with a DEBUG level violates the privacy of users and is not recommended”, so turning up the volume is not the route to a transcript.
ForceCommand shows the limit from the other side. It runs a command you choose and ignores the one the client sent, which is handy for restricted accounts, but the manual describes it as an execution control, not a recorder. For an interactive shell, commands typed inside the session are not something sshd is documented to capture. If you need that, something has to sit in the path and watch.
Four ways to get a real record
| Approach | What you capture | Weak spot |
|---|---|---|
| Native logs only | Logons, source, privilege flag | No view of actions |
| Command or process auditing on each server | Commands and processes | Configured per host; a root user can tamper with local files |
| Jump host or gateway that records | Full session, one place | You now run, patch and defend that host |
| Broker with session recording | Full session, no inbound listener on the server | Another component to choose and own |
Recording on the server itself has a built-in conflict of interest: the person being audited is often an administrator of the thing doing the auditing. CISA’s logging advice is to “centralize your logs with a log management solution” and to “protect logs from unauthorized access or deletion.” The same logic applies harder to recordings. Ship them off the host and make them read-only to the people they describe.
- Logs onlyWho, from where, when, whether elevated
- Logs plus recordingPlus what was typed or shown, files moved, replay, end it live
What to do, in order
- Turn on and centralise the basics. Collect the Windows logon events and SSH authentication logs somewhere other than the server. NIST SP 800-92 exists for this: it is a guide to “sound computer security log management.”
- Decide who counts as privileged. AU-14 asks you to define the users or roles whose sessions can be audited, and the circumstances. Start with domain admins, root, database admins and every vendor.
- Record those sessions through one path. One place to capture is easier to protect than a patchwork of agents.
- Control the recordings. Store them off the target, limit who can replay them, and set a retention period you can defend.
- Review, don’t just store. A recording nobody watches is evidence after the fact. Alert on odd hours and unexpected sources, and sample sessions.
- Talk to legal and HR first. AU-14 says to develop session auditing “in consultation with legal counsel”, and its guidance notes it can reveal information about individuals that may create privacy risk. Tell staff and vendors that sessions are recorded. This is general information, not legal advice.
Where SSHepherd fits
If the server has no inbound listener, the broker becomes the only way in, and it is a natural place to watch. With SSHepherd®, servers and users connect outbound to a broker, which joins them for authorised identities. The same broker supports session monitoring, recording and a kill-switch to end a session in progress, across SSH, RDP, databases and file transfer. See the SSHepherd page and the Windows RDP use case.
The bottom line
Logs tell you who got in; a recording tells you what they did. Keep both, put the recording path somewhere the audited admin cannot edit, and clear the policy with legal before you press record.