Monitoring & Diagnostics

Purpose

See at a glance which of your saved hosts are actually reachable, across SSH, RDP, and VNC, without opening each one.

How to do it

1. 1Open More → Connection Dashboard .
2. 2Hosts are split into separate SSH/RDP/VNC sections; each row shows a live up/down indicator based on an actual probe (not just "was connected once").
3. 3Right-click a row (or use the failed-connect flow) to open a real Ping test with a packet-by-packet success/failure summary.

How to verify

1. 1Open More → Connection Dashboard immediately after launching the app, before connecting to anything.
   • Expect hosts to show a neutral pending/unknown indicator, not a false "Up".
2. 2Wait for the first automatic probe pass (or trigger one).
   • Expect a host you know is currently reachable to flip to Up, and one you know is powered off to show Down.
3. 3Right-click a Down host and run its Ping test.
   • Expect a summary row reading exactly "FAILURE — 0/1 packets received" for an unreachable target; run the same test against a reachable host and expect "SUCCESS — 1/1 packets received" — not just a bare pass/fail label with no counts.

Troubleshooting

• Shows Up for a host that's clearly offline — confirm at least one probe has actually completed this session (a never-probed host used to default to a misleading "Up" state; this was fixed to show a real pending/unknown state until the first probe completes).

Purpose

Watch CPU, memory, network throughput, disk usage, and top processes on a connected SSH host, using only commands run over the existing session — no agent to install on the target.

How to do it

1. 1From an open SSH session, open the Monitor tab (in the session toolbar).
2. 2CPU/RAM/Network render as colored area-chart graphs; two separate Top-5 process grids show highest-CPU and highest-memory processes side by side; disk usage shows as threshold-colored bars.
3. 3Polling continues in the background even if you switch to another tab — it only stops when the SSH session actually disconnects.

How to verify

1. 1Open the Monitor tab on a connected SSH host.
   • Expect CPU, Memory, and Network to each render as a colored area-chart graph, two separate "Top 5 · CPU" and "Top 5 · Memory" process grids to populate side by side, and disk usage to show as threshold-colored bars (green/yellow/red).
2. 2Watch the CPU/Memory graphs update across at least two polling intervals, then switch to the Terminal tab and back to Monitor.
   • Expect the graph history to still show the earlier samples rather than restarting from empty — this confirms polling kept running in the background instead of stopping when you left the tab.
3. 3On a Windows target specifically, check the "Top 5 · CPU" grid.
   • Expect at least one process to show a non-zero, plausible CPU% — not every row pinned at 0%.
4. 4Connect to a second SSH host and open its Monitor tab too.
   • Expect each host's graphs to show that host's own data — switching between them should never show one host's history under the other's name.
5. 5Disconnect the SSH session while Monitor is open.
   • Expect polling to stop cleanly with no console errors from a dead session (open DevTools if you want to confirm directly).

Troubleshooting

• Graphs never populate — Monitor depends on being able to run plain shell commands ( /proc reads and ps / vmstat / df on Linux, PowerShell/CIM on Windows) over the SSH session — a heavily locked-down shell that blocks these will show empty graphs.
• Switching between multiple connected hosts mixes up graph history — this was a real bug (a single shared history object instead of one per session) fixed by keying Monitor state per-session; if you see history from the wrong host, it's worth confirming you're on a current build.

Purpose

Spot configuration drift between two servers that are supposed to be identical (or should have diverged only in specific, known ways) — e.g. confirming a config change rolled out to every node in a cluster.

How to do it

1. 1Open More → Tab Overview or the dedicated Compare panel, pick a left host and a right host (each an already-saved SSH connection), and pick what to compare — a specific file, or a command's output (e.g. dpkg -l on both sides).
2. 2The panel renders a side-by-side diff.

How to verify

1. 1Pick the same file (e.g. /etc/hosts ) on two hosts you know are identical, run the compare, and confirm the diff view shows no differences highlighted.
2. 2Edit one line on one of the two hosts (e.g. add a comment to that file), re-run the same compare, and confirm the changed line is now highlighted in the side-by-side diff while unchanged lines are not.
3. 3Compare a command's output instead of a file (e.g. dpkg -l on both sides) and confirm the diff view renders the same way — line-by-line highlighting on whatever text came back from each host.

Troubleshooting

• "Unsaved edits" warning when leaving mid-compare — if you edited either side in-place before finishing the comparison, confirm you actually want to discard those edits before proceeding.

Purpose

• Keep a local, hash-chained record of connection and policy events — logins, failures, disconnects, vault/team actions, secret access — where any after-the-fact edit to a past entry is detectable, not just a plain append-only text log.
• Entry #1 seed hash Entry #2 hash(prev+data) Entry #3 hash(prev+data) ?
• any edit breaks the chain Each entry's hash includes the previous entry's hash — edit or delete any past entry and every hash after it stops matching.

How to do it

1. 1Open Settings → Audit Log to browse events, filtered by category (connections, secret access, vault/team actions, policy).
2. 2Click Verify integrity to re-walk the entire hash chain and confirm nothing has been altered since it was written.
3. 3Enable Follow server sshd log (SSH chapter, Delegate tab) on specific hosts to also ingest the target server's own authentication events into this same log.

How to verify

1. 1Connect to and disconnect from a couple of hosts, then open Settings → Audit Log.
   • Expect each connect/disconnect to show up as its own row with a correct timestamp, newest first.
2. 2Click "Verify integrity" .
   • Expect the status line to briefly read "Verifying integrity…" and then settle on a message reading exactly "Verified N of M entries — chain intact." with N equal to M.
3. 3Filter the log by a specific category (e.g. connections only, or secret access only) and confirm only matching rows remain visible.

Troubleshooting

• Verify integrity reports a break — treat this seriously: it means something edited the audit log file outside of MangoSSH itself (or a genuine bug).
  • Don't dismiss it as a false positive without investigating what touched the underlying file.
• sshd-log events aren't appearing — that ingestion is POSIX-target-only and requires "Follow server sshd log" enabled specifically on that host (see the SSH chapter) — it's not automatic for every connection.

Purpose

Know before an SSH key or certificate expires, instead of finding out when a connection suddenly starts failing — and deploy/revoke a key across many hosts at once instead of one authorized_keys file at a time.

How to do it

1. 1Open Settings → SSH Keys — each key shows its age and, for certificates, the actual expiry date pulled from the cert itself.
2. 2Select a key, pick target hosts from the list of currently-connected sessions, and click Deploy to append it to ~/.ssh/authorized_keys on each, or Deauthorize to remove it the same way.
3. 3Rotate an expiring key with Rotate… — leave "When rotating, also remove the old key from the selected hosts" checked (its default) so the new key is deployed before the old one is removed, never the other way around, to avoid locking yourself out.

How to verify

1. 1Open Settings → SSH Keys and note a certificate's shown expiry date.
   • Cross-check it against ssh-keygen -Lf run directly on the cert file — the two dates must match exactly.
2. 2Connect to a test host, select a test key, tick that host in the target list, and click Deploy .
   • Expect the operation log to show success for that host.
3. 3On the target host, check ~/.ssh/authorized_keys directly and confirm the new key's line is present and correctly formed, then disconnect and reconnect using that key to prove it actually works, not just that a line was appended.
4. 4Click Deauthorize for the same key/host pair.
   • Expect a confirm dialog reading "Deauthorize key " < name > " on 1 host?
   • This removes the key line from each host's ~/.ssh/authorized_keys.
   • Make sure you keep another way in." — confirm, then check the target host again and verify the line is actually gone.

Troubleshooting

• Deploy/Deauthorize shows no target hosts — both actions only operate over your currently-connected sessions; connect to the host(s) first, they won't appear in the target list otherwise.
• Deauthorized a key and now locked out — this is exactly why the rotate-before-remove order matters; if it already happened, you'll need another still-valid auth method (password, a different key) to get back in and fix authorized_keys by hand.