tcpdump Remote Capture: Pipe Over SSH to Wireshark (2026)

The most surprising thing about tcpdump remote capture is that you’re not actually running tcpdump on the remote machine in the way you might intuitively think.

Let’s watch it happen. Imagine you want to capture traffic on a remote server, server.example.com, and analyze it live in Wireshark on your local machine, localhost.

First, on localhost, you’d open your terminal and run this command:

ssh user@server.example.com tcpdump -i eth0 -s 0 -w - 'not port 22' | wireshark -k -i -

Let’s break down what’s happening here, because it’s a bit of a shell trick.

ssh user@server.example.com tcpdump -i eth0 -s 0 -w - 'not port 22'

This is the "remote" part.

• ssh user@server.example.com: This establishes a secure shell connection to the remote server.
• tcpdump: This is the command being executed on the remote server.
• -i eth0: We’re telling tcpdump on the remote server to listen on the eth0 interface.
• -s 0: This is crucial for capturing full packets. It means "snap length zero," which tcpdump interprets as "capture the whole packet." Without this, you’d only get headers.
• -w -: This tells tcpdump to write its output to standard output (-) in its binary packet format.
• 'not port 22': This is a filter applied on the remote server by tcpdump. We’re excluding SSH traffic itself so we don’t capture the packets that make up our capture.

Now, the pipe: |

This pipe symbol is operating on your localhost. It takes the standard output from the ssh command (which is the raw packet data tcpdump is sending from the remote server) and feeds it into the next command.

wireshark -k -i -

This is the "local" part.

• wireshark: You’re launching Wireshark on your local machine.
• -k: This tells Wireshark to start capturing immediately.
• -i -: This tells Wireshark to read its input from standard input (-), which is receiving the raw packet data piped from the ssh command.

So, the tcpdump process on the remote server is writing raw packet data to its standard output. ssh is relaying that standard output over the network to your localhost. And on localhost, Wireshark is reading that relayed data from its standard input and displaying it as if it were capturing locally.

This technique is incredibly useful for debugging network issues on servers that don’t have a GUI or where you can’t easily install Wireshark. It allows you to leverage the power of tcpdump on the remote end and the analysis capabilities of Wireshark on your local machine.

The real power comes from understanding that the tcpdump process itself is running remotely, but its output is being streamed as raw binary data to your local machine, where Wireshark then interprets it. It’s not like tcpdump is sending ASCII-formatted packet summaries; it’s sending the actual byte streams of captured packets.

If you need to filter traffic on the remote end with more complex rules, you can extend the tcpdump filter string. For example, to capture HTTP traffic from a specific IP:

ssh user@server.example.com tcpdump -i eth0 -s 0 -w - 'host 192.168.1.100 and port 80' | wireshark -k -i -

The next hurdle is often dealing with large capture files or slow network links, which can lead to dropped packets on either the sending or receiving end if not managed properly.