Session Logging & Audit Trails for Remote Access

This chapter closes the content chapters where it makes sense to: access itself is worth logging, for exactly the same "evidence over guesswork" reason this whole subject has been built on since log1's own first chapter — not surveillance of the support engineer, the same principle applied one layer earlier, to how a session even started.

What Gets Logged, Typically

SSH connections land in auth.log or secure — log1's own territory for where these actually live. RDP connections show up in Windows Event Viewer's own Security log, with specific event IDs for logon and logoff. For genuinely privileged or sensitive access, some organizations go further with full session recording — keystroke logging or video-style capture — through dedicated privileged-access-management tooling. Worth being honest: full session recording is a more invasive, higher-scrutiny practice, typically reserved for genuinely sensitive access, not blanket surveillance of all routine remote work.

Reading Your Own Access History Like Evidence

Checking your own recent connections is a legitimate, useful diagnostic step in its own right — confirming exactly when you connected relative to some other event, or confirming a session actually ended cleanly, the same "confirm it's actually disconnected" discipline Chapter 5 covered for screen sharing, now applied to SSH and RDP as well.

Using Session Logs During an Incident

During a genuine incident, remote-access session logs are themselves timeline evidence, per log1's own material — "who connected to this system, and when" can directly corroborate or contradict a hypothesis, the same way any other log source does. Worth noting this cuts both ways: confirming no unauthorized session occurred during a suspicious window is itself genuinely valuable, reassuring evidence — session logs are useful whether or not something bad is actually found.

Session Logging Is a Deterrent Too, Not Just a Record

Knowing that access is logged is itself a mild, healthy deterrent against exactly the kind of "just this once" shortcuts this course has warned against — sharing a private key, using a shared account, skipping least privilege. Not because anyone assumes bad faith by default, but because visibility genuinely does change behavior for the better, the same way any other accountability mechanism does. Worth stating honestly, rather than pretending logging exists purely for forensics after something has already gone wrong.

Privacy and Proportionality

Session logging should scale with the actual sensitivity of the access involved — routine read-only diagnostic access on a low-sensitivity system doesn't need the same scrutiny as privileged access to a system handling sensitive data. Organizations should be transparent with engineers about what's actually being logged and why — the same "know your organization's own policy" advice Chapter 1 opened this course with.

Working Example: "Nobody Remembers Changing This"

A sensitive configuration file changed overnight; nobody remembers doing it. Checking session logs for the exact time window shows exactly one SSH session, from one specific engineer's own key, at precisely the right time. Confirmed directly with that engineer — who then remembers making a quick, legitimate change and simply forgetting to mention it. A benign resolution, not a security incident — a realistic reminder that most mysteries logs resolve end this way, not with "aha, a breach," but with "oh right, that was me."

Hands-On Exercises