What exactly is SSH tunneling? What is the difference between the terms: SSH Tunneling and Port forwarding? What is the exact difference between different types of SSH tunneling methods?
Local port forwarding vs Reverse port forwarding vs Dynamic tunneling
What are the ideal scenarios where each type can be used?
In layman terms, Secure Shell or SSH is established between two computer programs :
The connection between client and server uses encryption, so establishing in effect a secure channel over an insecure network. The term "Secure Shell" comes from the ability of the server to run a local shell on the server computer, allowing the client to execute commands and see their result. But SSH can also be used for many other purposes.
Both server and client use a known protocol to communicate, which means a known format for their messages. However, SSH can also do tunneling, which means the transfer of messages-within-messages or protocol-within-protocol. The server in this case acts as a switch or agent, transferring messages back and forth between the client and its target, for example evading the local firewall :
The messages from the inner protocol are in this way encrypted and encapsulated inside the SSH protocol.
Below are detailed some, but by no means all, of the uses of SSH.
To run a command on a remote system without logging in, specify the command after the login information:
$ ssh host command
For example, to check remote disk space:
$ ssh host df
Another example for Linux is piping the microphone from one machine to the speakers of another:
$ dd if=/dev/dsp | ssh -C user@host dd of=/dev/dsp
For copying data and files over SSH, there are a few options.
It's possible to copy with the command cat. If you're trying to copy the output of a process instead of a file, this is certainly a reasonable route :
$ cat file | ssh -e none remote-host 'cat > file'
If these are going to be large files, you may want to use the -C flag to enable compression.
For copying files, the program scp works like cp, except it also accepts remote destinations :
$ scp .bash_profile [email protected]:~/.bash_profile
For an FTP-like interface for copying files, use the program sftp.
SSH allows secure port forwarding.
For example, suppose you want to connect from client A to server B but route traffic securely through server C. This is useful for evading firewalls.
From A, run:
A$ ssh C -L localport:B:remoteport
Then, to connect to B:remoteport, connect to localhost:localport.
If you use add -g, then anyone that can reach A may connect to B:remoteport through A:localport.
For example, suppose your work banned reddit.com. Run this:
# ssh yourserver -L 80:reddit.com:80
And, set the address of reddit.com and www.reddit.com to 127.0.0.1 in /etc/hosts (you will also need to disable any local web server). Now, it will surreptitiously traffic to reddit.com through your yourserver.
If you do this frequently, you might want to add a special host:
Host redditfw
HostName yourserver
LocalForward 80 reddit.com:80
Alternatively, suppose you wanted to give remote machine B access to another machine, A, by passing securely through your local machine C.
Then, on C, you can run:
C$ ssh B -R remoteport:A:targetport
At this point, local users on B can connect to A:targetport through localhost:remoteport.
If you want to to allow nonlocal users to be able to connect A:targetport through localhost:remoteport, then set in the sshd_config file:
GatewayPorts yes
If you do this frequently, set up a special host in ~/.ssh/config:
Host exportme
HostName B
RemoteForward remoteport A:targetport
Using the FUSE project with sshfs, it's possible to mount a remote filesystem over SSH. On the Mac, use Fuse4x.
Once it's installed, run:
$ sshfs remote-host: local-mount-directory
SSH tunneling is the same as port forwarding in this context, though SSH documentation and configuration parameters usually refers as the later one.
Tunneling or forwarding a port allows you to encapsulate TCP traffic inside a SSH connection. This could be used to
Local port forwarding is when the LISTEN port is established on the client side. I.e. you open a local port 80 on your machine, connected to someotherplace:80 on your server side.
Reverse port forwarding is when the LISTEN port is established on the server side. I.e. you open a remote port 8080 on the server, conected to your_proxy:8080
Dynamic acts as a SOCKS proxy.
Sample scenarios:
Let's say you are on Computer A and you connect to Computer B, so A initiates a connection to B.. Say it's web, so HTTP connection. There's no Proxy there and no Encryption. No SSH, no SSH command used. You could run that connection through SSH, that'd involve tunneling and port forwarding and would of course gain the benefit of encryption too, but tunneling which by the way always uses port forwarding, is not the most simple use of SSH.
You can have SSH without any "tunneling" so without encapsulating a protocol within it, by e.g. Say you are on Computer A and you want to access a command line on Computer B. SSH protocol can do that. And in fact i've seen a ssh -X, enable one to view a GUI on Computer B, where computer B ran Linux. So SSH can do quite a bit even without tunneling. And you get SSH's encryption whenever using SSH.
What you can also do, is let's say you want to browse the web from an internet cafe. You can make an SSH connection from computer A, to computer B, making a connection that is an SSH tunnel, it will encapsulate another protocol, e.g. requests to an HTTP proxy.. and at computer B, the web proxy will act, fetch the webpage and send it to computer A. All the person at the Internet cafe sees, is an encrypted ssh connection between A and B. Dynamic port forwarding would create a SOCKS proxy at B, and a SOCKS proxy can act as a web proxy.
You could use VNC to from A to B, but do it through an SSH connection.. so that's tunneling/encapsulating a VNC connection in through an SSH connection.
There is a concept in SSH of local port forwarding, and remote port forwarding(reverse tunnel). That is which side listens and which side forwards. Local is the typical. For example. A situation of ssh tunneling involves these elements.. ssh.exe (initiates the ssh connection, that's the ssh client). sshd.exe (the ssh server, listens for ssh.exe to connect to it). And the client and server of the encapsulated protocol. e.g. the VNC client and VNC server. And you have the computers on which each of these are running.
Say your computers are A,B,C,D
A-runs VNC client
B runs SSH client
C runs SSH server
D runs VNC server
B connects to C.
A connects to B, then C forwards that to D.
Everything between B and C is encrypted.
Anything between A and B, or C and D, is not encrypted.
The SSH tunnel is between B and C.
Between A and B, and between C and D, is the encapsulated protocol - VNC in this case.
We often do SSH and tunneling with just two computers. So eg A runs VNC client and SSH client. B runs VNC server and SSH server.
Now i'll get to what a reverse tunnel is and it is useful..
Suppose A is behind a NAT Router and B is behind a NAT Router.. If A wants to connect to VNC on B, then B has to do port forwarding on his router. (that's even without SSH). Another way though, would be if B can initiate a connection to A, enabling A to view B. So you the techie send joe bloggs an executable and then run it and you view their computer. PChelpWare does this- enabling you to create such an executable. But the process, of B can connect to you, can be done with SSH.
For example in a scenario of local ssh tunnel, you may have
CompA, runs VNC client and SSH client
CompB, runs VNC server and SSH server
So the tunnel and VNC connection go in the same direction.
A connects his SSH client(ssh.exe) to B's SSH server(sshd.exe). (requires B to do port forwarding on his router). ssh.exe on A then creates a port on A - the comp it is running on, which listens for a VNC connection. That is the listening side of the tunnel. And also when the tunnel was constructed it was determined that B should forward to whatever IP:PORT, B in this case. Which is where the VNC server is.
CompA/PersonA, connects the VNC client to the port that ssh.exe has opened on A. And that will then get forwarded to B.
But here's the problem with that, with local ssh tunnel. Suppose B has no idea how to do port forwarding on his router.
Then A cannot connect his SSH.EXE, his ssh client, to B's SSHD.EXE, B's ssh server.
Well, they could do a reverse SSH tunnel
A runs the SSH SERVER and VNC Client
B runs the SSH CLIENT and VNC Server..
B connects to A.. with a command that instructs that a reverse tunnel be created. So, the listening is done not local to where SSH.EXE was run(which is B), but the listening port is opened on A, even though B ran ssh.exe So B connects to A and makes an SSH connection. A now listens for the encapsulated protocol.
A then connects his VNC client to the port that opened on A, and views B.
B did not have to do port forwarding on his router. As all B had to do was initiate a connection.. There was no incoming connection to B. That is what an SSH tunnel can do.
(note that nowadays when A wants to view B they typically use a solution like teamviewer which probably involves both making an outgoing connection)
But anyhow that's a use of reverse ssh tunnel.
So whether to use an local ssh tunnel or a reverse one, depends on which side is blocking incoming. or which side is behind a device blocking incoming for which you cannot control. e.g. a NAT router or firewall that you cannot control.
a Dynamic tunnel, is where A connects to B via SSH, and a SOCKS proxy is created at B. A SOCKS proxy is like a generic proxy.. which can imitate a bunch of different kind of proxies. So it can act as a Web proxy. So if you were at an Internet cafe.. You could use a dynamic tunnel. Connect to CompB and that's all the person running the internet cafe sees. The thing with a web proxy is it doesn't juse forward to one computer otherwise you'd only get one website. It forwards to whatever web server you request, enabling you to browse the web.
To do SSH with -L, listens on the local end, and does port forwarding on the remote end, so with SSH -L, you do SSH -L PORT:IP:PORT user@sshserver -p 22 where of PORT:IP:PORT the first "port" is the port that ssh.exe will create locally for your e.g. VNC client to connect to. and IP:PORT is the IP:PORT of the e.g. VNC server. then you have sshserver -p 22 sshserver is an IP of the ssh server you are connecting to, and -p 22 means connect to it on port 22. You might actually instead of PORT:IP:PORT, say IP:PORT:IP:PORT where the first IP is 0.0.0.0 or * which means any computer can connect.
SSH but with a reverse ssh tunnel, listens on the remote end, and does port forwarding locally. So you do SSH -R PORT:IP:PORT where the first PORT is the port at the sshd.exe end that listens. And the IP:PORT is the IP:PORT of the e.g. VNC server, that that CompA, i.e. the comp running ssh.exe will forward to. And it's also SSH -R PORT:IP:PORT user@sshserver -p 22
Dynamic SSH would be of the form ssh -D 8080 <username>@192.168.1.1
There is a case of somebody doing a reverse version..a reverse SSH -D. https://web.archive.org/web/20200618074454/https://stackoverflow.com/questions/842021/ssh-d-port-usernameserver-com-but-in-reverse He ran an SSH server and wanted his friend to have access to his SSH proxy. So his friend would run ssh -D [email protected] But he didn't want his friend to have an SSH console too. There is no doubt a better way to prevent that, but what he did.. or asked to do.. Was He makes the SSH connection to his friend, but then have his friend access his SSH SOCKS proxy. So his friend has a proxy to access his SOCKS proxy! So he (the person-person A- setting his computer up so his friend could access his(A's) proxy) would type ssh -R 24680:localhost:12345 remotehost
And then, do ssh -D 12345 localhost That ssh -R, means the first port specified (24680) will open up on CompB. And anything received on that(which is where B connects his web browser) will be sent to A and forwarded to port 12345 which is where A runs his SOCKS proxy. And the funny thing with how the SOCKS proxy is set up which is how SOCKS proxies are set up with SSH, is it requires its own ssh connection. That is not tunneling SSH through SSH.. The SOCKS requests are tunneled through SSH. But the ssh connection that makes the SOCKS proxy is a separate connection that comes from A connecting to his own ssh server on port 22. (in addition to the SSH connection A is making to B). That last example, the reverse ssh -D is a very complex use of SSH! The other uses (local,reverse and normal -D) are still complex but not as complex as the reverse -D example. I just added it for more completeness.
see also my answer to Control raspberry via VNC from ouside LAN: how is this feasible without port forwarding?
