![]() ![]() ![]() Ssh _HOST -i "LOCAL_CYGWIN_PATH_TO_PRIVATE_KEY" -o CheckHostIP=no -o StrictHostKe圜hecking=no "tcpdump -ni REMOTE_INTERFACE -s 0 -w - not port 22" | "LOCAL_CYGWIN_PATH_TO_WIRESHARKEXE" -k -i. ![]() If you use the standard port 22, it gets simpler: Ssh _HOST -p REMOTE_PORT -i "LOCAL_CYGWIN_PATH_TO_PRIVATE_KEY" -o CheckHostIP=no -o StrictHostKe圜hecking=no "tcpdump -ni REMOTE_INTERFACE -s 0 -w - not port 22 and not port REMOTE_PORT" | "LOCAL_CYGWIN_PATH_TO_WIRESHARKEXE" -k -i. Looking into stdbuf at the moment.)Īnyway, using cygwin with standard packages and either replacing or defining anything in caps, you'd run: (Unconvinced about gzip|gunzip, but so far my tests show that fewer packets get lost this way, at the cost of speed and latency of course. For various reasons of convenience, I can't / don't want to use named pipes unless they can be incorporated into a one-liner. Still, not ALL the packets show up on the capture, compared to a local file tcpdump dump. I experimented with opening remote/local tunnels seeking to capture and display all the packets that came, even if they would be displayed with a delay, and so far this so the most accurate representation. Yet it allows you to benefit from the convenience of Windows Wireshark while utilizing the power of Linux's tcpdump. It doesn't strictly require you to use a key to authorize, but if you don't, it stops being a one-liner.Īlso, it isn't hugely efficient in that some of the packets get lost to whatever perils there exist in ssh tunnels. It doesn't use the questionable plink (whose main disadvantage is that its flags don't map over to the far more widespread ssh's.), but instead relies on cygwin/standard ssh command. For what it's worth, I'll leave here my preferred one-liner solution for live remote capture on non-standard ssh ports using Windows' version of wireshark and standard tcpdump on whatever flavor of Linux the remote machine has. Seeing as this is actually fairly recent. Here, with ssh between the two, it may behave differently. I never tested with a named pipe on linux, only on Windows, where the capturing process waits for the receiver to connect to the pipe, then starts writing to it, and when the receiver disconnects again (which is a consequence of pressing "stop" in Wireshark), the capturing process terminates. If the result of "my" test is a file of 50 packets about which Wireshark does not complain, and the result of Harris' test is still a 0 B file, you know for sure that both tcpdump and ssh are OK if you use tcpdump with -w - and 2>/dev/null.įinally, try again with the named pipe, first also with the -c 50. This will make tcpdump stop the capture after first 50 packets. So please repeat both tests above with additional parameter of tcpdump, -c 50. You need to be extremely lucky that only part of the last packet would not be written to the output file in this case. The capture file appears to have been cut short in the middle of a packet is a consequence of the fact that you've stopped the ssh and tcpdump together by pressing ^C, so both processes were killed abruptly, not gracefully. ![]() So if tcpdump would be printing something to stdout, it would be the only output remaining, but the resulting file size is 0 bytes.īut there is still some space left for doubt. w /dev/null 2> /dev/null indicate that stderr should go to trash and the binary pcap data should also be written to trash instead of stdout (while -w - means to use stdout for the binary pcap data). Both tests seem to indicate that there must have been some typo in your original attempts, because:Ģ> /dev/null prevents tcpdump's stderr from being grabbed by the ssh session at the server and thus intermixed with the contents of the capture file at the client (as Harris wrote, ssh mixes stdout and stderr together at server end so you cannot split them back at client end) Ssh "echo thePassword | sudo -S tcpdump -s 0 -n -w -U -i eth0 not port 22 2>/dev/null" > /tmp/remotecapture Ssh "tcpdump -s 0 -n -w -U -i eth0 not port 22 2>/dev/null" > /tmp/remotecapture Tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytesĬheck Guy Harris' answer below and my comment on 14 Feb When Wireshark threw an error regarding libpcap format, I also tried clipping the first line that's passed before the raw packets, to no avail though. Redirecting to a simple file does work but not in a format Wireshark can read later. No packets captured! As no data was captured, closing the temporary capture file!.Ssh -t "tcpdump -s 0 -n -w -U -i eth0 not port 22" > /tmp/remotecapture.fifoĪnd tried some variations that resulted in I set a remote capture to a host using tcpdump and a named pipe like so ![]()
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |