Thanks. Let me know if I misunderstood, but it seems that this is redirecting my custom domain customdomain.example.com to tuns.sh

customdomain.example.com. 300 IN CNAME tuns.sh.

_sish.customdomain.example.com 300 IN TXT "SHA256:mVPw"

What I want to do is:

1- to create a custom domain ON tuns.sh (or another Pico service)

2- redirect this custom domain to another DNS (such as a Load Balancer, an API Gateway, etc.)

Something like: {username}-{proj}.tuns.sh. 300 IN CNAME myalb-123abc.amazonaws.com.

I am not sure how you avoided collisions (network namespaces?) on the localhost port space, but for things like this, you would be better off forwarding to/from UNIX domain sockets. It is more efficient as local tcp sockets have several times the overhead. You probably would want to set StreamLocalBindUnlink yes and StreamLocalBindMask 0117 in sshd_config. Then use UNIX groups with the group sticky bit set on the directory where the unix domain socket is made to allow multiple users access. The directory would be owned by that group while each user with access would be added to that group. It reduces some network overhead and is highly secure. I recently used this trick to connect a bunch of machines to a remote service through a jump host.

Also, take it from someone who has been running services over port forwards for years. You want to set ClientAliveInterval and ClientAliveCountMax in sshd_config on the server (if you have not already). Users should be encouraged to set ServerAliveCountMax and ServerAliveInterval In ssh_config on their machines. Furthermore, it would be best if the tunnels were run by daemon tools and had ExitOnForwardFailure set as part of the command that is run. The ssh command used at the client side likely also should set -nNT. It is also good practice for the machines running ssh to have dedicated accounts for the tunnels such that their daemon tools scripts are essentially two lines, a shebang followed by exec setuiduid user ssh -i ...

Finally, if people want to do very low overhead and highly secure setups, they should bind the services that they reverse forward to unix domain sockets locally and reverse forward the local unix domain sockets over ssh to remote unix domain sockets. They can use a file mode sticky bit on the parent directory to make the local Unix domain socket accessible by the ssh command running on its own user, which locks things down locally fairly nicely. A typical process running on the machine will not be able to talk to the reverse forwarded service thanks to the Unix file permissions. Lastly, using ed25519 or ecdsa ssh keys would make the initial connection process very quick compared to using RSA.

So approximately nothing?