PuTTY Session Logging: Client-Side Audit Trails for SSH Troubleshooting

The Problem: Missing Visibility Into Remote Sessions

When an SSH session hangs, a command fails silently, or a junior engineer accidentally runs rm -rf on the wrong directory, the remote server's bash_history often tells an incomplete story. It records only executed commands, not their output, timing, or interactive prompts. Server-side auditd or syslog can help, but they require root access and configuration on every host — impractical when you're connecting to appliances, network gear, or customer environments you don't control.

PuTTY's built-in session logging solves this by capturing the full terminal stream — both sent keystrokes and received output — on the client machine, independent of the remote host. The feature has existed since early PuTTY versions (0.58+) and works with SSH, Telnet, Rlogin, and serial connections.

How PuTTY Session Logging Works

Under Category > Session > Logging in the PuTTY Configuration window, you choose a log file path and one of five logging modes:

• None — logging disabled (default)
• Printable output — only characters that would display on screen
• All session output — everything received from the server, including escape sequences
• SSH packets — raw SSH protocol packets (binary, for protocol debugging)
• SSH packets and raw data — both decrypted packets and raw wire data

For auditing and troubleshooting, All session output is the practical choice. It captures the complete terminal transcript: your typed commands (including passwords if typed in cleartext), command output, error messages, ANSI color codes, and cursor movements. The log writes in real-time as the session progresses.

Worked Example: Persistent Per-Host Audit Logs

Suppose you manage a fleet of Linux servers and want a chronological, per-host log of every administrative session. You can configure this once per saved session in PuTTY:

1. Open PuTTY and load (or create) a saved session for prod-db-01.
2. Navigate to Category > Session > Logging.
3. Set Session logging to All session output.
4. In Log file name, enter a path with the &H placeholder: C:\putty-logs\&H-&Y-&M-&D.log.
   • &H = hostname from the session configuration
   • &Y, &M, &D = year, month, day at session start
5. Choose Append under "What to do if the log file already exists" to keep a single growing file per host.
6. Set Log file encoding to UTF-8 if your servers use UTF-8 locales (most modern Linux), or ASCII for legacy appliances.
7. Return to Session category and click Save on the session profile.

Now every time you open prod-db-01, PuTTY creates or appends to C:\putty-logs\prod-db-01-2026-10-13.log. A typical log snippet looks like:

[2026-10-13 14:22:01] user@prod-db-01:~$ sudo systemctl status postgresql
[sudo] password for user: 
[?1034h[?1034h
[?25l  (systemd pager ANSI codes)
[?25h
 postgresql.service - PostgreSQL 14 Database Server
   Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
   Active: active (exited) since Thu 2026-10-10 08:15:02 UTC; 3 days ago
...

The ANSI escape sequences ([...m) are preserved. For human reading, pipe through cat -v or use a log viewer that renders ANSI (like less -R on Linux/WSL).

Trade-offs and Limitations

Enable logging only for interactive admin sessions, not monitoring tails. Use a log rotation script (Task Scheduler/cron) to compress and age out files.

Concern	Impact	Mitigation
Plain-text secrets	Passwords, API keys, tokens typed or printed during the session are stored unencrypted on the local disk.	Use key-based auth; avoid pasting secrets. Encrypt the log directory with BitLocker (Windows) or LUKS (Linux). Rotate and purge logs per policy.
Disk consumption	High-volume sessions (e.g., tail -f /var/log/syslog) can generate hundreds of MB per hour.
Crash loss	If PuTTY terminates abnormally (power loss, kill -9, BSOD), the OS buffer may not flush; the last seconds to minutes of the session can be missing.	Not eliminable in PuTTY. For critical sessions, run script or tmux logging on the remote side as a redundant capture.
No integrity guarantee	Local user can modify or delete logs after the fact.	Write logs to a write-once share, SIEM forwarder, or append-only filesystem if non-repudiation is required.

Verification Checklist

After configuring a session, confirm it works:

1. Open the saved session and run a distinctive command: echo "PUPPET-LOG-TEST-$(date +%s)".
2. Close the session cleanly (type exit).
3. Open the log file in a text editor and verify:
   • The test command appears with its output.
   • Timestamps (if you added them via shell PS1) or session boundaries are visible.
   • ANSI codes are present (indicating All session output mode, not Printable output).
4. Compare a few lines against ~/.bash_history on the remote host — you should see commands that bash_history misses (failed commands, interactive input, sudo prompts).

When to Use This vs. Alternatives

PuTTY session logging shines for:

• Ad-hoc troubleshooting — no server-side change, works on any SSH endpoint.
• Network devices and appliances — Cisco, Juniper, FortiGate, etc., where you cannot install agents.
• Vendor support engagements — hand the log file to a vendor to reproduce an issue.

It is not a replacement for:

• Centralized audit logging (use SSH certificate authorities, ForceCommand, or a bastion host with session recording like auditd or teleport).
• Compliance-grade immutable logs — client-side logs are mutable by the local user.
• High-volume automated sessions — use application-level logging instead.

Actionable Next Step

Pick your five most critical saved sessions in PuTTY. Enable All session output logging with the &H-&Y-&M-&D.log naming pattern, pointed at a dedicated folder (e.g., %USERPROFILE%\putty-logs\). Set a calendar reminder for 30 days to review disk usage and prune. This gives you a safety net for the next "what just happened?" moment without any server-side coordination.