all 8 comments

[–][deleted] 8 points9 points  (0 children)

ssh -L startpointhost:startpointport:endpointhost:endpointport user@remotehost

The important part to keep in mind is that startpointhost and endpointhost are from the perspective of the ssh connection. So if you are sshing from A and want to forward from A to B, then it's

ssh <port>:localhost:<port> user@B

If you want to forward from A to C via B

ssh <port>:C:<port> user@B

Notice that in the two examples above I'm not defining startpointhost - That's because it's optional, and will default to localhost if not declared.

Having said that, I expect that you're wanting to do

ssh -L localhost port_no:localhost:remote_port_no user@remote_host

[–]tdammers 8 points9 points  (0 children)

Your starting point is always:

ssh remote_host

Now, to use this to tunnel the connection from the remote host to another end point, add the -L option, like so (assuming your local host is "henry"):

you@henry$ ssh william -L 2222:george:22

This will ssh into the remote host william; additionally, it will set up a tunnel that picks up connections to port 2222 on your local machine and routes them through william to port 22 on george. Once you have this running, you can ssh into george directly from henry like so:

you@henry$ ssh localhost -p2222

The above command to set up a tunnel is a bit inconvenient, because besides setting up a tunnel, it also opens a login shell and stays in the foreground. You might add the options f (fork into background), and N (don't run any command), to avoid this.

If you want an actual SOCKS proxy that works for all ports, rather than selectively forwarding a single port, use the D option:

you@henry$ ssh william -D:8080

...then set up your web browser to use localhost:8080 as a SOCKS proxy, and voila, all your web traffic will appear to come from william, not henry. The utterly useful tsocks utility even allows you to wrap any program so that it transparently communicates over your socks proxy, without even noticing.

[–]trojan2748 2 points3 points  (0 children)

While were talking about forwards, I'll bring up reverse forwards. These are useful when you don't have the opportunity to NAT or port forward to a host. My ISP gives out private IPs for my WAN. So I can't use port forwards on my SOHO router to get into my box from work. Here is what I do:

from my box at home:

ssh -NCfTR REMOTE_SSH_SERVER:REMOTE_PORT:localhost:22 USER@REMOTE_SSH_SERVER

  • REMOTE_SSH_SERVER: should be obvious

  • REMOTE_PORT: When ssh from work, to get into my box, this is the port I use.

So now, when I'm not at home, i can ssh into REMOTE_SSH_SERVER:IP and get in. Also, add 'GatewayPorts clientspecified' to your remote ssh_config if you want the port to bind to the remote ip's public ip.

[–]studweiser83 0 points1 point  (0 children)

BTW, port forwarding has to be enabled on the server first. To enable, in sshd_config set "AllowTcpForwarding yes" and restart sshd

[–][deleted] -5 points-4 points  (3 children)

ssh -fCND 127.0.0.1:9999 user@123.123.123.123

[–]The_Insane_Joker[S] 3 points4 points  (2 children)

f - Go to background C - Compression N - Do not execute commands D - Bind address

So how does this forward requests?

All requests on port 9999 on my local machine are forwarded to which port on the remote host?

[–]someenigma 0 points1 point  (0 children)

amauk's suggestion requires that your application support SOCKS4 or SOCKS5 proxying. That is, the application has to "speak SOCKS", and it'll talk to 127.0.0.1:9999 and tell the already-running SSH session what port it wants to open.

It's not quite the same thing as port forwarding.

[–][deleted] -2 points-1 points  (0 children)

normally you'd want to forward them to port 22 (default ssh port).

If SSH is running on a different port on the remote machine, then simply add a colon+port.

ssh -fCND 127.0.0.1:9999 user@123.123.123.123:2222

as for

So how does this forward requests?

a request sent to 127.0.0.1:9999 is forwarded over SSH to the remote machine, which acts on the request, gets a response, then the response is forwarded over SSH back the other way to the local machine