This is an often misunderstood feature and I’ll try my best to explain it briefly.
I’ll be using three computers designated as client, destination and ssh-server.
The client computer witch runs all the commands and uses the tunnel afterwards
Where the client would like to connect to
A computer running ssh daemon where the client has access.
The client would like to connect to destination, but for some reason is unable to. Maybe a firewall is preventing outbound traffic to that port, or maybe the destination is restricting ip address that can connect. There are many reasons why going through a third party can be usefull.
ssh -L 5050:cnn.com:80 bob@ssh-server
This command will bind the local client port 5050 through an encrypted tunnel ending up at the ssh-server. Using bob as the username to gain access to the ssh-server. Communication from ssh-server to the website will not be encrypted, as it is no longer inside the tunnel. To specify further; communication will not be encrypted by the ssh-tunnel, but if the communication was already encrypted on the client before entering the tunnel, it would still be when leaving ssh-server.
The destination will only see a connection from ssh-server, even if it originated from the client.
So http://localhost:5050 on the client will now show cnn.com. Although tunnelling to a website is a bad idea, because a webpage usually requires many other sites (content, script and stylesheet may be hosted on a subdomain or simmilar), and may try to redirect to other port or addresses. But it illustrates the point.
ssh on non-standard port
What if the ssh deamon is listening on a different port? say port 2022.
just add -p 2022 like this:
ssh -L 5050:cnn.com:80 bob@ssh-server -p 2022