Remote packet capture

Local packet capture taps your own interfaces. Remote capture runs on-box over SSH: start a capture on the far end, stop it, pull the PCAP back to your machine. Pro tier and above.

The problem it removes is the four-step version — SSH in, tcpdump -w /tmp/x.pcap, remember to stop it, scp it back, remember to delete it — which you do wrong at least once per incident.

Running one

Pick any saved SSH connection as the target. Choose the remote interface, set a BPF filter and a limit, start.

Capture runs on the remote host. Progress reports back live, so you can see packets accumulating rather than guessing whether your filter matched anything. Stop when you have enough, then Pull to transfer the file into your local captures list, where it opens like any other PCAP.

Set a filter and a limit before starting. An unfiltered capture on a busy uplink fills the remote host’s disk, and it will be the one host in the fleet without monitoring on /tmp.

Requirements on the target

tcpdump present, and rights to capture — root, sudo, or the cap_net_raw capability on the binary. Missing capture rights is by far the most common failure, and the surfaced error says so rather than returning an empty file.

Cleanup

The remote temp file is removed after a successful pull. If a session drops mid-capture, the file stays on the remote host — deliberately, so a network blip doesn’t destroy the capture you were collecting. Re-attach and pull it.

Via a connector

Remote capture start and pull are exposed to MCP clients as action tools, so an attached assistant can propose a capture but you approve it in the ShellYard window before anything runs on a production host.

Pairing with a port mirror

Capture on a host shows you that host’s traffic. To see traffic between two other devices, mirror it to a port first — see the Port Mirror helper — then capture on whatever is plugged into the destination port.