Audit, recording and alerts

The audit log

Open Audit Log from the Dashboard's side rail. Every device keeps its own log, per profile, on its own disk. It is written as things happen and is never cleared automatically. It never contains a password, a passphrase or a key.

The Filter menu groups the events:

Some entries appear only under All events, among them vault membership decisions (approved, denied, revoked, role changed), relay sessions terminated from the PAM Dashboard, share links revoked, policy deletions, and changes to audit forwarding or the host agent.

Two views are available from the icons beside the close button: cards, and a plain console you can select and copy from. Export… saves the whole log as CSV (for a spreadsheet) or JSON Lines (for a script or SIEM). Clear Log empties it; that cannot be undone, but anything already forwarded stays at the destination.

Check that nobody edited it

Each entry carries a SHA-256 hash that covers its own content and the previous entry's hash, so the entries form a chain. Click Verify Integrity to walk the chain again. It reports either that the chain is intact, or the first line where a row was inserted, removed or changed. Entries before that line still verify.

The PAM Dashboard's Audit evidence section shows the same result as a headline (Chain intact or CHAIN BROKEN), with the number of events, the date range, and Export Audit Log….

The chain proves that the log was not altered after the fact. It cannot stop someone with access to the machine from deleting the whole file. That is what forwarding is for.

Forward the log to a SIEM

Forwarding sends a copy of every record, as it is written, to a syslog server or an HTTPS collector. The local log stays the source of truth.

1. In Audit Log, click Forwarding and tick Forward every audit record to a SIEM.

2. Choose a Destination:

   • Syslog (RFC 5424): enter the Server, Port (514 by default) and Transport (UDP or TCP).
   • HTTPS collector (JSON): enter the Collector URL and, if your collector wants one, a Bearer token. The token is kept in the operating system's keychain.

3. Click Send Test Record, check it arrived, then click Save.

What the receiver gets:

# one syslog message (the record is shortened here)
<108>1 2026-09-29T10:15:02.114Z WORKSTATION-7 mangossh 4312 host_key_rejected - {"ts":…,"event":"host_key_rejected","host":"web01",…,"hash":"…"}

Record sessions

Recordings are kept in Session Logs (under Tools, or in the Dashboard's side rail). They are encrypted with your Personal Vault, so the vault must be unlocked to record, list or play them.

SSH

SSH sessions are recorded as asciicast v2, the asciinema format: the full terminal output with timings. There are four ways to switch it on:

• One session: the record button on the terminal toolbar.
• One host, always: Edit → Session → Always record sessions.
• Every SSH session: Record sessions at the top of Session Logs. It is the same setting as Record every SSH session by default on the Policies page.
• By policy: the Always record the session rule, for a group, a tag or the fleet.

RDP and MangoSSH Direct

Use the record button on the session bar (Record session (screen capture)). The recording lands in Session Logs as a screen recording. Select it and click Play to open it in the Recording Player. VNC, Telnet and Serial sessions cannot be recorded.

Browse, keep and export

Session Logs lists recordings newest first, with search and a protocol filter. An SSH recording shows as readable text; a screen recording opens in the player. For each one you can add a note, Bookmark it, Export… it (.cast for SSH, .mrdprec for screen recordings) or Delete it.

Keep last sets how many recordings to keep in total; older ones are removed automatically. The default is 50. Bookmarked recordings are never removed and do not count toward the limit. Turning recording off deletes nothing; Delete All does.

All of these recordings are made by the connecting device, so the person connecting could stop one. The PAM Dashboard's Session recording section shows which of this device's open sessions are being recorded right now.

Server-enforced RDP recording

For a recording the connecting person cannot switch off, broker the RDP host through the PAM Broker and turn on Record every session brokered through this host when you provision it. The relay is the RDP client for those sessions, so it records every one on its own disk. The connecting device has no toggle and no way to tell.

• Recordings are encrypted with the relay's RELAY_BROKER_CACHE_PASSPHRASE. Lose it and they cannot be read.
• They are written under RDP_RECORDINGS_PATH (rdp_recordings by default; the Docker setup puts it inside the relay's volume).
• Vault admins see them in the PAM Dashboard under RDP recordings. Download saves a decrypted copy, which you open in the Recording Player.

Brokered SSH sessions have no server-side recording yet.

Follow a server's sshd log

The audit log normally records what happened in MangoSSH. Following a server's sshd log adds what the server saw: every login, failed login and disconnect, including ones from other tools.

1. Open the SSH host with Edit → Session.

2. Turn on Follow server sshd log — ingest server-side SSH events into the audit log. A policy can turn it on for many hosts with Follow the server sshd log.

While you are connected, MangoSSH reads the log over the same SSH connection, with no second login. It tries journalctl for the ssh or sshd unit, then /var/log/auth.log, then /var/log/secure. Your account needs permission to read one of them; membership of the adm or systemd-journal group is usually enough. If none can be read, nothing is added and no error is shown.

Each event records the account targeted and the source IP. The Internet edition adds an approximate location for public IPs; the Secure edition leaves it out. Two rules raise a server alert:

• a successful login as root or admin;
• three failed logins from one IP against one account within 60 seconds.

This works with Linux and other POSIX servers only. Windows event logs are not read.

Alerts

Alerts are set up in Connection Health (in the Dashboard's side rail). Click Alerts.

1. Tick Send alerts. It is off by default; nothing is sent until you turn it on.

2. Under Send when, choose the kinds: Host goes down, Host recovers, Latency spike, Security alert and Access request waiting.

3. Choose where they go. Show a notification uses the desktop's notifications and only works while MangoSSH is running, so keep it in the tray. POST to a webhook sends to Slack or Teams, Discord, or any service that accepts raw JSON; paste the URL and click Set. The URL is a credential, so it is kept in the keychain and not shown again.

4. Set the Limit (10 per minute by default, 0 for none) so one failing switch does not become forty alerts. Click Test, then Save.

Security events are also marked as syslog warnings when you forward the log, so your SIEM can alert on them as well.

Team-wide views

The audit log is per device. These views bring devices together:

• Team Audit (Team Vault). Each device also writes its audit entries, encrypted, to the Team Vault's shared store. Open Sync → Team Audit on the Sessions page to search every machine's events by host, machine, event and time. The Team Vault must be unlocked. See Vaults.
• Vault Dashboard (Self Hosting Vault, admins). Its History page lists approvals, denials, revocations and role changes, taken from this device's audit log.
• PAM Dashboard. Fleet sessions as the relay sees them and as devices report them, the JIT queue and grants, and every browser link issued. These come from the vault server and relay, not from one device. See PAM Broker and browser access.

Troubleshooting