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.

1. The server R1 host a web service, but firewall/NAT/whatever block direct access to port 80.

2. "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 )

It looks like you should be using local port-forwarding instead of remote port-forwarding. You may want to refer to the following helpful blog post by Dirk Loss:

• SSH port forwarding visualized

It includes the following illustrative diagram:

In order to read the diagram you need to know that it describes the relationships between 4 different roles involved in creating and utilizing an SSH tunnel:

• an ssh client (i.e. ssh - the OpenSSH command-line client) used to establish the tunnel;
• an ssh server (i.e. sshd - the OpenSSH server daemon) used to maintain the other end of the tunnel;
• an application server (e.g. another ssh server or an http server);
• an application client (e.g. another ssh client or a web-browser) which wants to access the application server via the tunnel.

It's also important to understand that the two different types of forwarding correspond to two different use cases:

• Local Forwarding: where the application client connects via the ssh client

• Remote Forwarding: where the application client connects via the ssh server

Remote forwarding is so called because the forwarding is performed remotely (at the ssh server) rather than locally (at the ssh client). I also find "remote forwarding = reverse forwarding" to be a useful mnemonic.

So as you can see, in order to initiate a connection from an ssh client at the origin host through an sshd server on a proxy jumphost to a third target host you would have to use local port-forwarding. Remote port-forwarding is for the case in which you want the entry point to the tunnel to be located at the host running the sshd server rather than at the host running the ssh client.

In the man page the local port-forwarding syntax is written as follows:

ssh -L [bind_address:]port:host:hostport user@remote

This can be written more intuitively as the following:

ssh -L [local_bind_address:]local_port:remote_host:remote_host_port user@proxy_host

Or, using your naming conventions:

ssh -L [origin_bind_address:]origin_port:target_host:target_host_port user@jump_host

If we modify your command to use local port-forwarding instead then we end up with the following:

user@origin:~$ ssh -L *:1234:target:22 myusername@jumphost