|
|
|
|
|
by tommyvan
1912 days ago
|
|
i use an amazing ssh library called asyncssh, altho I've had to go very low level in it to scale beyond a single instance so my code looks quite different to the examples. ssh tunnels are a part of the ssh spec, like most of what you "see" when using ssh it uses an ssh channel.
Every time a request comes in from clients I read (technically MSG_PEEK for those that love TCP) into the TCP stream to find the destination and match it up with an opened tunnel. on the free plan and port 80 requests to the paid plan this means reading up to the HTTP Host header, and on TLS this means reading up to the SNI headers. Once I have that match I create an SSH channel and wire up the traffic to flow back and forth. You can try your own ssh reverse tunnel if you have a server on the internet, all you need to do is install an SSH server on it and then use the same command as you do to connect to localhost.run, but change my hostname for yours. You won't get the Host SNI level routing so this doesn't work as well for more than one user but it is an interesting exercise to see SSH tunnels in action when you control both ends of the connection. If you want to dive deeper into the internals of SSH definitely give the RFC a read, https://tools.ietf.org/html/rfc4254#section-7.2 is the beginning of a tunnels journey. I know RFCs can be intimidating if you've not read them much, i felt that myself pre-localhost.run, but they're written concisely and unambiguously, and once you've gotten to grips with the writing style they're by far the best way to understand standards like SSH. |
|