It sounds to me like you need a socks client, or a ssh client that understand socks. -D is for ssh to be a socks server/proxy.
You could use ssh under tsocks, or another SOCKS wrapper. Or use ssh's ProxyCommand in conjunction with socat or nc -X:
ssh -o ProxyCommand='socat - socks:B:%h:21,socksport=1080' C
To have a HTTP proxy that uses the SOCKS server to send HTTP requests, you can run a small proxy (like tinyproxy) under tsocks.
Note that not all applications play nicely with tsocks or any similar wrapper that relies on LD_PRELOAD, but tinyproxy does.
Also note that you may have issues with domain name resolution (depending on whether you want the names to be resolved on either side of the tunnel). tsocks doesn't work well for resolving names remotely. The only way it can work is when your nameserver (in /etc/resolv.conf) is reachable from the other end and you're using TCP for domain resolution (which tsocks can attempt to enforce but generally fails in my experience). socksify from dante's SOCKS client/server works better in that instance as it also wraps resolving functions and can also use a nice little trick to fake name resolution so that SOCKS by-name connections can be used.
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:
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:
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
Best Answer
So, if I understand correctly, you can ssh from machine 1 to machine 2 but not from your laptop (from which you can ssh to machine 1). So you'd like to have a socks server on machine 1 and use it from your laptop? So looks like all you need is port forward that 8080: run on your laptop: