Should You Exclude the SSH Flow From a Remote Capture?

Capturing on a remote box while you watch the output through the same connection is a self-referential measurement, and it distorts what you are measuring. Every packet you print travels back through the session being captured. Excluding that flow is usually right, but the size of the exclusion is a real decision. Too narrow and the capture floods itself; too wide and the evidence disappears.

Why the capture records itself

The capture sees the return path of its own output. Each line printed to your terminal becomes one or more packets on the management connection, which the filter then matches and prints again. The result is a loop that grows until the buffer or the link gives up.

That is why a capture written to a file looks fine and the same capture streamed live becomes unusable. The traffic is not new; you created it. A ten-second capture can produce more output than the link can carry once the loop starts.

Build the exclusion as one group

Start from how the remote host sees your session, not from the address in your local terminal. A jump host or a NAT device can make the peer something you never typed, so read the address from the remote side's own view. Then group the host and the port together so the negation applies to the pair.

tcpdump -ni eth0 '(net 10.60.0.0/24) and not (host 203.0.113.77 and tcp port 2222)'

Quoting the whole expression keeps the shell from reading the parentheses as syntax. Print the filter back before you trust the result.

The filter that looks right and keeps everything

The wrong filter is the one that reads naturally: source is not the peer, or destination is not the peer. For a packet from your workstation the first test is true; for the reply the second is. Joining them with or keeps both directions, which is exactly what you meant to drop.

pcap filter logic gives and and or equal precedence and evaluates left to right, so parentheses are not optional when you mix them. Negate one grouped expression instead of combining two negations. That single change separates a working filter from a capture full of your own typing. The pcap filter reference is short enough to read in the terminal and worth checking whenever a filter behaves unexpectedly.

Decide by what the capture must prove

Decide how much to exclude by asking what the capture must prove. If you need to see application traffic to the same host, exclude only the SSH port and accept noise from other sessions. If the host is irrelevant to the question, excluding it entirely is simpler and removes a whole class of self-generated packets. Write the choice next to the capture file, because a filter is an assumption about the evidence.

Interface choice decides what you can see at all. On the tunnel you see inner traffic; on the physical interface you see the encrypted transport. If the management packets are already absent at the point you chose, no exclusion will fix a capture aimed at the wrong layer.