Establishing a Secure Reverse Proxy with Bridge for Accessing Internal Networks from the Public Internet.

[hongyi-zhao]

I'm trying to figure out a method to securely access resources on an internal network from the public internet using the bridge tool. The setup involves three main components:

• An internal machine within the private network.
• A publicly accessible server with a known public IP address.
• A client machine on the public internet seeking access to internal resources.

The process works as follows:

The internal machine initiates a connection to the public server using bridge, establishing a reverse SSH tunnel:

bridge -b :0 -p ssh://public_ip:12022

The public server runs bridge to listen for SSH connections and forward them to a SOCKS5 proxy:

bridge -b socks5://:1080 -p ssh://:12022

Clients can then access internal network resources through the SOCKS5 proxy on the public server:

curl -x socks5://public_ip:1080 http://internal_service_address

Am I right?

Regards, Zhao

[wzshiming]

I guess the following command run on your internal machine will meet your needs.

I recommend using the ssh key to access the server will be safer.

bridge \
  -b socks5://:1080 \
  -b ssh://root@public_ip:22?identity_file=/root/.ssh/id_rsa \
  -p -

[hongyi-zhao]

Then, you suggest the following steps?

• On the internal machine:

bridge \
  -b socks5://:1080 \
  -b ssh://root@public_ip:22?identity_file=/root/.ssh/id_rsa \
  -p -

• On the public server:

bridge -b socks5://:1080 -p ssh://:22

• Use it as follows:

curl -x socks5://public_ip:1080 http://internal_service_address

[wzshiming]

The public server does nothing, only add the pub key of the internal machine to its /root/.ssh/authorized_keys.

[hongyi-zhao]

The public server does nothing,

Do you mean the following step can be omitted?

• On the public server:

bridge -b socks5://:1080 -p ssh://:22

only add the pub key of the internal machine to its /root/.ssh/authorized_keys.

Thank you for pointing this out.

[wzshiming]

Yep

[hongyi-zhao]

It seems that the following methods are roughly equivalent:

• The method discussed here:

  bridge \
  -b socks5://:1080 \
  -b ssh://root@public_ip:22?identity_file=/root/.ssh/id_rsa \
  -p -

• Pure ssh based method:

autossh -M 0 -4 -NT -o ServerAliveInterval=30 -o "ServerAliveCountMax=3" -o "ExitOnForwardFailure=yes" -o StrictHostKeyChecking=no -R 1080:localhost -i /root/.ssh/id_rsa root@public_host -p public_host_ssh_port
#or
ssh -fNT -R 1080:localhost -i /root/.ssh/id_rsa root@public_host -p public_host_ssh_port

See the related discussions below: https://www.cnblogs.com/makefile/p/ssh-rev-tun.html https://serverfault.com/questions/361794/with-ssh-only-reverse-tunnel-web-access-via-ssh-socks-proxy

[wzshiming]

Yep, you can do it in any of the 3 ways.

The bridge was originally designed with the need to pass through multiple jump machines. e.g.

bridge \
  -b socks5://:1080 \
  -b ssh://root@internal_ip_2:22?identity_file=/root/.ssh/id_rsa \
  -b ssh://root@internal_ip_1:22?identity_file=/root/.ssh/id_rsa \
  -b ssh://root@public_ip:22?identity_file=/root/.ssh/id_rsa \
  -p - \
  -p ssh://root@other_public_ip_2:22?identity_file=/root/.ssh/id_rsa \
  -p ssh://root@other_public_ip_1:22?identity_file=/root/.ssh/id_rsa

It listened to internal_ip_2 1080 via 3 machines, and forwarded via 2 machines.

[hongyi-zhao]

I tried to give alternative pure SSH-based counterparts to the above bridge method but failed to sort out the logic and find the corresponding implementation. Can corresponding SSH implementations handle such complex scenarios?

[wzshiming]

You might look at the difference between -b and -p in the bridge

[wzshiming]

Actually, I can't remember the command of ssh or other proxy tools

[hongyi-zhao]

It is certain that even if they can be implemented, there will be numerous pitfalls and extreme complications.

BTW, another wonderful tool is gost.

[wzshiming]

It is not the same as bridge's goal, which leads to the difference in functionality, it can not be implemented to listen to the remote server's port via jump machines, and as a parameter to the ssh ProxyCommand.