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.
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 local port forwarding, so a local ssh tunnel, 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, 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, but 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://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 username@server.com 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.
1A canonical answer and a layman's answer are very different things... – Jason – 2014-08-28T20:02:54.733
Sorry! All I wanted is a detailed explanation. Can I change it somehow? – Rahil Arora – 2014-08-28T20:10:05.053
Are you also interested in other common methods of securely connecting to remote LANs, such as VPNs or RDS? – Jason – 2014-08-28T20:16:27.120
Not actually. I've trying to understand these methods and having a hard time understanding the differences in these methods. – Rahil Arora – 2014-08-28T20:34:23.473
@Jason nah you can have a canonical layman's answer. SSH is a complex thing.. so where he asks for a layman's answer, he (and in this case it's clear), he's not asking for an explanation to the neighbour or his grandpa, he's somewhat technical and is asking for an explanation, that covers the ground of local,reverse,dynamic). – barlop – 2014-08-28T20:47:53.810
@barlop Exactly. I'm just having a hard time in visualizing the difference. – Rahil Arora – 2014-08-28T20:50:37.540
@RahilArora took me a long time to get my ahead around it and many times I thought i'd got my head around it but then had the insight that let me get my head around it more.. i'm still not sure how far my head has got round it. As a start, try contemplating the 4 aspects.. Who runs the SSH.EXE who runs SSHD.EXE who runs the regular client and who runs the regular server e.g. the VNC client and VNC server. So 4 elements there. And write them on paper 'cos it's a lot for the mind. – barlop – 2014-08-28T22:31:17.017