Is it possible to make a peer-to-peer SSH connection via bittorrent-like technique?

Question

As we discussed on my question, the question comes to this point:

Could we establish a TCP connection via UDP Hole Punching technique?

-- Original Question / History --

I'm using reverse tunnel feature of OpenSSH in order to connect an SSH server that is behind a firewall.

Now I can connect server-behind-firewall machine by issuing ssh me@my-known-server -p 12345

This way, all of my-laptop's traffic is routed to my-known-server, and my-known-server is routing this traffic to the server-behind-firewall machine. I think this is inefficient.

What I am looking for is a technique that will provide same functionality but using bittorrent's technique (which is, peers create UDP connections to the my-known-server (tracker) and sends packets to eachother directly)

Is there any way to achieve this functionality?

Edit:

Bittorrent connection is created via "UDP hole punching" technique.

Edit-2:

Apparently what I was looking for is making an SSH connection over "Hamachi" like software which uses NAT traversal technique.

Answer 1

ssh-p2p makes exactly what you were trying to do, it creates a direct peer to peer ssh connection using RTCDataChannel/WebRTC as transport (which use ICE NAT Transversal for hole punching).

If either the client or the server is inside a really restricted network, the direct connection will fail. Usually, peer to peer connections fallback to use a proxy server (in the case of RTC a TURN server), but ssh-p2p will just fail if a direct connection is not possible.

So, if ssh-p2p is failing to connect, you should use a proxy server. You can use the "reverse proxy" method that you described or you can use a third-party proxy as ngrok or serveo.

Answer 2

There seems to be a way to do this even without a 3rd party server (e.g. tracker) using a tool called pwnat.

For more detail see this superuser post or the pwnat github page and publication.

Answer 3

To answer your question, I'm pretty sure there is not functionality like this, first off because SSH is a TCP-based protocol rather than UDP.

The standard method for reaching hosts behind a gateway is to use the ProxyCommand option in your ~/.ssh/config file.

Tunnels are explained elsewhere, but the lowdown is that you can basically "hop" your SSH through proxies by simply specifying a command which will open a TCP:22 connection to a remote host that can function as the next SSH hop. (Though in many cases you only need one proxy.)

For example, using the hostnames you've mentioned in your question, you might add the following to my-laptop's .ssh/config file:

host server-behind-firewall
    ProxyCommand ssh -xaqW%h:22 my-known-server

You then ssh to server-behind-firewall, the ssh client on your laptop establishes a connection to my-known-server which establishes a connection to the firewalled server and proxies traffic back to you. This implies that you have an SSH account on my-known-server. While proxies are perhaps not the most efficient way of managing data, this is secure, well documented, and the accepted method for making this sort of connection.

The idea of "peers [creating] UDP connections ... and [sending] packets to each other directly" only works if machines can actually connect to each other directly. Since your firewalled machine CANNOT be reached directly, the only way to reach is is through the proxy on its gateway.

If your firewalled server is on a network that uses NAT to reach the outside world, then it is possible that the server could establish its own independent connection to some outside location to bypass the firewall. But beware of doing this. Network admins take firewall bypass strategies VERY seriously. To maintain your access to things, you should work with your network admins to find a solution, not around them.