Results 1 to 4 of 4
I'm trying to learn the basics of SSH tunneling, and I followed a guide that I liked O'Reilly Network -- Using SSH Tunneling
So, I executed with the command syntax
...
- 07-13-2008 #1
Slight confusion with SSH tunneling.
I'm trying to learn the basics of SSH tunneling, and I followed a guide that I liked O'Reilly Network -- Using SSH Tunneling
So, I executed with the command syntax
I didn't want to test it with POP right off the bat, so I setup a small Netcat connection between my desktop and server on port 4200; the server was ran withCode:$sudo ssh -L 4200:server:4200 -l user -N server
and the desktop withCode:sudo netcat -l -p 4200
To establish a raw TCP connection between the two, in which I sent plaintext to view with tcpick.Code:netcat server 4200
The "server" in this case is the router for the network, and thus sees all the traffic. When I run tcpick on port 4200 and the interface my LAN is routed through, the data being sent on port 4200 is not encrypted.
I'm wondering if this is because since I'm already setting up the SSH connection on the server that I'm running the packet sniffing on, that it's going to see the data unencrypted no matter what. The only other machines on the network are all Windows so I haven't tried sniffing a connection tunneled between my desktop and one of them, but I'm pretty sure that the only reason I'm able to see the info unencrypted is because the machine I'm running the sniffing on is the "host" per se of the entire SSH tunnel and sees all the data unencrypted by the time it actually makes it to port 4200?
Just wondering if I've got the principles correct and a flawed test, and not the other way around.
- 07-13-2008 #2Linux Enthusiast
- Join Date
- Apr 2004
- Location
- UK
- Posts
- 658
It looks like you've got the ssh tunnelling correct. Because you are working with ports over 1024 you shouldn't need to use sudo, but that shouldn't affect what you are trying to do just now.
The problem looks like the netcat. When you set up local port forwarding you open up a listening port on the ssh client which then encrypts the traffic and forwards it to the server, which then passes it onto whichever destination was specified in the -L switch.
To make this work, on the client, you need to do
Let us know how you get on,Code:netcat localhost 4200
Chris...To be good, you must first be bad. "Newbie" is a rank, not a slight.
- 07-14-2008 #3
Oh, okay, I have a better idea of what's going on here now. It seems I was bypassing the SSH tunnel almost entirely with the way I first used netcat.
However, this time, when I run a packet sniffer, I can't even see any packets traveling on 4200 at all. Is this because the data is actually being sent over port 22? I would test to see if this was the case, but I already have a few SSH sessions open, and I wouldn't be able to distinguish what was data from that and what was data from the netcat connections.
- 07-14-2008 #4Linux Enthusiast
- Join Date
- Apr 2004
- Location
- UK
- Posts
- 658
That is exactly what is happening. As far as I know, there is no way to distinguish what is going on, but then that is the idea.
The only thing I can suggest is making sure your tunnel is the only thing active while the transfer is going on.
Let us know how you get on,
Chris...To be good, you must first be bad. "Newbie" is a rank, not a slight.


Reply With Quote
