1 - general case
Suppose you have two server in a company network.
From local server "L1" you have access to a remote server "R1" via ssh on port 22.
The server R1 host a web service, but firewall/NAT/whatever block direct access to port 80.
"R1" can't access "L1" directly due to NAT issue.
from L1 you connect using (same user on both host)
ssh -L 10080:localhost:80 -R 10022:localhost:22 R1
now,
-L 10080:localhost:80
local browsing on 10080 will be forward to distant host (R1), localhost (e.g. distant 127.0.0.1) on port 80, thus you could browse distant host (R1), while blocked by firewall/NAT.
-R 10022:localhost:22
remote use of port 10022 will be forwarded to localhost (L1) port 22, you can initiate scp/ssh from remote to localhost. (using scp -P 10022 file localhost:
(note upper -P
) )
This is actually a command line I use from an Ubuntu (14.04) laptop to go to production server (I can firefox to localhost:10080 and use scp from server to localhost:10022 to bring back file )
now your IP are
192.168.1.1 L1
172.17.17.1 R1
you use
ssh -L 10080:172.17.17.3:80 -R 10022:192.168.1.5:22 \
-L 192.168.1.9:8888:172.17.17.9:9999 R1
now
- distant access to port 10022 (any IP) will be forwarded to local 192.168.1.5 ssh/scp.
- local access to port 10080 (any IP) will be forwarded to distant host 172.17.17.3 port 80.
- local access to port 8888 from 192.168.1.9 will be forwarded to port 9999 on 172.17.17.9 (192.168.1.9 is a local address in L1, using alias mecanism, this is not a firewall rule).
those setting can be used on putty/bitwise client
Ask Ubuntu question
what about
-R 8000:localhost:80
this read as
-R
remote
8000
port 8000 (remote port 8000 ... )
localhost
(remote port 8000 goest to localhost .. )
80
( remote port 8000 goes to localhost port 80 )
1.) Yes: if you specify a local port forwarding (option -L
in OpenSSH), your SSH client will act as a proxy that forwards the connection that's incoming to a specified local port/socket onto a specified target at the remote end of the SSH connection. And if you specify a remote port forwarding (option -R
in OpenSSH), the sshd
daemon at the remote end will act as a proxy that forwards connections incoming to a a specified remote port/socket to the specified target on the local side of the SSH connection.
In both cases, both the SSH client and the sshd
daemon work together to implement the functionality, but whichever is accepting the incoming connections could be said to act as a proxy for the actual service on the opposite side of the SSH connection.
2.) Also yes, but then the request must be specified using a protocol that is understood by SSH. A dynamic port forwarding (option -D
in OpenSSH) does just that, supporting the SOCKS4 and SOCKS5 protocols.
For example:
You might have a server room full of equipment with web-based remote console functionality. Since those aren't always updateable to the latest TLS standards, you've connected them to a strictly local network segment that is accessible through a particular network administrators' workstation only. This workstation has two NICs: one to the regular network, and another to the remote console segment, but it is intentionally configured to not act as a router. Of course the network administrators' workstation runs Linux :-)
You're on a well-earned vacation, when the big boss calls and tells you that the your stand-in is sick from food poisoning and some old router in the server room needs to be rebooted ASAP. You're hundreds of miles away from the server room. Through the company VPN, you can access the network administrators' workstation remotely, but you know from experience that using X11 forwarding to run a remote browser is painfully slow. So, what do you do?
<connect VPN>
laptop$ ssh -D 1234 tim@netadmin_workstation.company.intra
netadmin_workstation$
Now, as long as that SSH connection is up, you can fire up a local browser, configure it to use a SOCKS proxy located at localhost:1234
and all the outgoing network connections from that browser will go out through the SSH connection to the netadmins' workstation, and from there on as regular TCP connections to whatever address specified in the browser. Effectively, your browser's network connections will now seem to originate from the netadmins' workstation, while the browser (and any associated Java applets) will still be run fully locally, with minimum latency.
And so you can access the Java-based web GUI of that pesky old router remotely with a somewhat tolerable level of latency...
(If you're using Firefox, you may want to set an about:config
option network.proxy.socks_remote_dns
to True
, in order to have the browser also forward any DNS requests through the SOCKS proxy connection, so you can use the DNS resolution of the netadmins' workstation too.)
(Disclaimer: any resemblance of the above description to any particular series of real-life events is entirely coincidental. Something very much like it has probably happened many, many times in a lot of different places all over the world.)
Best Answer
Yes, you have to specify a destination IP and port when using local forwarding. From
man ssh
:Clearly, only the bind address is optional.
No, you can't specify a destination host or port when using dynamic forwarding. In dynamic forwarding, SSH acts as a SOCKS proxy. Again from the manpage (emphasis mine):
With
-L
, SSH makes no attempt to understand the traffic. It just sends everything it receives on the local port to the target port - you determine the target port at the time the connection is made. With-D
, SSH acts as a proxy server, and therefore can handle connections from multiple ports (for example, a browser configured to use it as a SOCKS proxy can then access HTTP, HTTPS, FTP, etc. over the same connection). And like with other proxy servers, it will use the traffic to determine the destination.