skip to content

How do you stream a tcpdump capture from a remote Linux server over SSH into Wireshark on your workstation, and why does -U matter?

level: seniorimportance: should knowfreq 13%

answer

  1. pcap down a pipe
  2. standard output as the savefile
  3. flush every packet
  4. don't capture yourself

basics

~20 s

Run ssh host "sudo tcpdump -i eth0 -U -w - 'not port 22'" | wireshark -k -i -. -w - sends pcap to stdout, -U flushes each packet, and the filter keeps the capture from recording its own SSH stream.

solid answer

~40 s

Run `ssh [email protected] "sudo tcpdump -i eth0 -U -w - 'not port 22'" | wireshark -k -i -`. `-w -` makes tcpdump write raw pcap to standard output; Wireshark's `-i -` reads a capture from standard input and `-k` starts it immediately. `-U` makes the `-w` output packet-buffered: without it, output to a pipe is buffered and Wireshark may show nothing for a long time on a quiet filter. The filter must exclude the SSH session, or every captured packet sent back over SSH creates more packets to capture. sudo cannot prompt for a password there, because the command has no terminal and its output is the capture stream. For long or high-rate captures, write rotating files on the server and copy them instead.

go deeper

for a junior

Remember the shape: ssh runs tcpdump with -w - and the output is piped into wireshark -k -i -.

for a middle

Explain each flag: -w - for pcap on stdout, -U for packet-buffered output, -i - and -k on the Wireshark side, and why the filter excludes the SSH session.

for a senior

Show the operating judgement: no interactive sudo in the pipe, bandwidth and kernel drops on a congested link, cleanup of the remote process, and when to switch to rotating files.

for a principal

Discuss controls around remote capture: who may stream production packets to a laptop, how that access is granted and logged, and when a central capture service is the better design.

## Why stream instead of copying a file For a short interactive investigation it is convenient to watch packets arrive in Wireshark on your own workstation, without installing a GUI on the server or copying files back and forth. The usual pattern pipes tcpdump's output through SSH into Wireshark: ``` ssh [email protected] "sudo tcpdump -i eth0 -U -w - 'not port 22'" | wireshark -k -i - ``` ## What each piece does - `-w -` makes tcpdump write **raw pcap** to standard output instead of printing decoded lines. Wireshark reads only pcap or pcapng from a pipe, never tcpdump's text. - `-U` (`--packet-buffered`) makes the `-w` output **packet-buffered**: each packet is written to the pipe as soon as it is saved. Without it, output to a file or pipe is buffered, and the man page warns that a reader may not see packets for an arbitrary amount of time; on a quiet filter that can be minutes. - `wireshark -i -` reads the capture from **standard input** ("-" is the documented pipe name), and `-k` starts the capture session at once instead of waiting at the start screen. - tcpdump's own messages ("listening on eth0 ...") go to **standard error**, which SSH carries to your terminal, so they do not corrupt the pcap stream. ## The traps 1. **Capturing your own SSH session.** Each packet the remote tcpdump captures is sent back over the SSH connection, which creates new packets on the same interface, which are captured in turn. Exclude the session in the capture filter, with `not port 22` or, more precisely, the connection's own address and port. Wireshark's automatic remote-traffic filter applies only when Wireshark itself runs in a remote session; it does nothing for a remote tcpdump. 2. **sudo that wants a password.** The remote command has no terminal and its standard output is the capture stream, so an interactive password prompt cannot work. Use a sudo rule that does not prompt for this command, or a capture account given the privilege it needs; how that grant works is a separate subject. 3. **`-l` instead of `-U`.** `-l` line-buffers standard output for piping *printed* text into `tee` or `grep`. With binary pcap on standard output it would flush only when a newline byte happens to occur, not at packet boundaries; `-U` is the option documented for `-w` output. 4. **Bandwidth.** The stream crosses the network at the capture rate. A capture filter and a shorter snapshot length (`-s`) keep it manageable; a congested SSH link backs up into the remote capture buffer and shows up as kernel drops. 5. **Cleanup.** Closing Wireshark closes the pipe; confirm on the server that tcpdump has exited rather than assuming it. ## Checking the stream is healthy - Your terminal shows tcpdump's start line on standard error, such as `tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes`; if it never appears, the remote command did not start (often sudo). - Wireshark's packet count should grow steadily; bursts after long pauses point to a missing `-U`. - When you stop, the end-of-capture summary, including packets dropped by kernel, also arrives on your terminal; read it before trusting gaps in what you saw. ## Stream or file? | Situation | Prefer | |---|---| | Minutes of interactive debugging at a modest rate | streaming over SSH | | Hours or days waiting for an intermittent fault | rotating files on the server (`-C` with `-W`), copied later | | A high-rate link or a slow path to your workstation | a filtered, headers-only capture to a local file | | Evidence that must be kept | a file, with a checksum and a record of the command | ## Variations that keep the same mechanism - Capturing on a different interface or with `-i any` changes nothing about the pipe; the pcap header tells Wireshark the link type. - Wireshark also ships an `sshdump` component that runs a remote capture over SSH from the GUI; it is the same idea packaged as a capture interface. - If you only need text, skip Wireshark: `ssh host "sudo tcpdump -n -l -i eth0 'tcp port 5432'"` prints lines as they arrive, and here `-l` is the right flag.

  • Why must the capture filter exclude the SSH session?
    The capture runs on the interface that carries the SSH connection. Every captured packet is written into the pipe and sent back over SSH, producing new packets that are captured and sent again. The file fills with your own session and the feedback can saturate the link. Excluding port 22, or better the session's own address and port, breaks the loop.
  • What do you see in Wireshark if you leave out `-U`?
    tcpdump buffers `-w` output that goes to a pipe and writes it only when the buffer fills. Wireshark shows packets in bursts, long after they arrived, or nothing at all on a quiet filter, which looks like a broken capture. `-U` writes each packet as soon as it is saved.
  • When is copying a capture file better than streaming?
    When the capture must run for a long time, the rate is high, or the path to your workstation is slow or unreliable. Write filtered, rotating files on the server with `-C` and `-W`, then copy only the files that cover the incident. Streaming is for short, interactive looks.

saying these in an interview costs you the question

  • tcpdump's -l is the flag that flushes a -w - pcap stream after every packet.
  • Wireshark can read tcpdump's printed text lines from a pipe.
  • There is no need to exclude the SSH session from a remote capture.
  • Wireshark automatically filters out the SSH traffic of a remote tcpdump.
  • tcpdump's listening-on message will corrupt the pcap stream on stdout.