Running it remotely, if you kill the
ssh process, the other end should die. Unless you are letting this end suspend for some reason. If that is the case, you might want to run it as part of a larger script on the background.
You also should not use root remotely, and you certainly not need root on the side doing the ssh. Avoid working as root as possible. Use a remote user with
You probably also do not need "w -" as
tcpdump by default writes to stdout.
You can also limit
tcpdump on the number of captured packets to control the session better. Please do note you have to exclude port 22 from the system doing
ssh otherwise the remote system will capture the current session in a kind of self-feeding recursive way.
So you to capture 1000 packets you could do:
$ssh email@example.com "sudo tcpdump -i eth0 -s0 -c 1000 not port 22" > /tmp/local_file
Another less clean alternative is running afterwards a pkill:
$ssh ..."sudo tcpdump"
$ssh ..."pkill tcpdump"
As a last warning,
/tmp or the root where it resides, often is in limited filesystems or in RAM; it is also a security risk to create predictable names in a /tmp directory, specifically as a privileged user. You might want to user another location for the capture file.
You also may get better results as a sysadmin investing in a tool like
ansible. For automating or using more complex tools for remote admnistration, please see Linux equivalent to PowerShell's "one-to-many" remoting