I've seen a similar question but it's different enough for the answer not to quite work.

I have two Debian Buster hosts - one in a private network (A); one in Azure (B).

I'd like Host A to initiate a reverse SSH connection from Host B. Then Host B subsequently to open a SOCKS proxy listener so that connections to that are tunnelled back to Host A. I would like to achieve all of this just by entering commands on Host A.

I know that I can set up the reverse SSH tunnel from Host B to Host A (initiated by Host A) like so:

ssh -R b:localhost:a b.b.b.b

a = the listening port on Host A
b = the listening port on Host B
and b.b.b.b is the IP address of Host B.

How can I then get the second part - automatically creating a SOCKS proxy listener on Host B - to work? Is it even possible? Or would I need to create a script on Host B that creates the SOCKS proxy listener whenever netstat shows the reverse SSH tunnel is Established (or similar)?

Editted to try and clarify based on first answer.

  • A simple ssh -R b user@b.b.b.b makes Host B listen on port b and tunnel to Host A, which acts as a SOCKS proxy, the requests it receives there. Is this what you are looking for? (Especially if it's not,) showing a bigger picture (e.g. a browser → Host B, port b → (via tunnel) Host A → some server on A's private network) may help. – fra-san Jul 14 at 21:41
  • It might be what I'm looking for actually..! Easy to overthink this. I've just tried it and Host B is only listening on the loopback though. – noisey_uk Jul 14 at 21:52
  • 1
    Likely because of GatewayPorts in sshd's configuration on Host B (see man sshd_config). If it solves your issue, please feel free to self-answer your question (I'm not posting an answer right now). – fra-san Jul 14 at 22:06
  • Yes, gatewayports was the reason. Thanks fra-san - much appreciated! SSH to b.b.b.b:b doesn't work but I'll do a bit of troubleshooting and report back. – noisey_uk Jul 14 at 22:16

Have you established the first step, reverse ssh connection? If yes, then your local host A should be listening to an arbitary port, for example 2222, through which traffic will be forwarded to port 22 on Azure server B (if default sshd port is used on B).

  • Second step, socks proxy.

On host A type,
ssh -p 2222 -D 4444 -N localhost
I'm arbitary choosing port 4444 on local (host A) for the SOCKS proxy to listen.

Traffic: 4444 local A -> 2222 local A -> 22 Azure B

To test, use socks proxy setting on a browser, for example Chrome,
google-chrome --proxy-server="socks://localhost:4444"
or choose SOCKS version, 4 or 5
google-chrome --proxy-server="socks4://localhost:4444"

If everything is good, you should browse the Internet using you azure machine as gateway/proxy. Check your public IP to be sure.

| improve this answer | |
  • Thanks for your answer. Unless I've misunderstood, this will open the listener on Host A to forward to Host B though. I'm after the other way around. i.e. Host B opens a SOCKS listener and forwards traffic to Host A. But Host A sets everything up (no commands entered on Host B). – noisey_uk Jul 14 at 21:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.