You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If there's a NAT not only server-side, but client-side as well, rssht currently works by ssh-ing to a relay server from the server, then ssh-ing again to the same relay server from the client. This works well, but it introduces load on the relay server and impacts both latency and bandwidth.
Implementing STUN / ICE would enable direct SSH connection from the client to the server, by just signalling the server to the client and vice-versa. In the rare cases where it wouldn't work, the current TURN approach could be used as a fallback.
Additionally, it might be possible to rely on some public STUN server to avoid the public server requirement altogether.
Also, see #11 for an approach which doesn't even need a STUN server (pwnat).
The text was updated successfully, but these errors were encountered:
If there's a NAT not only server-side, but client-side as well, rssht currently works by ssh-ing to a relay server from the server, then ssh-ing again to the same relay server from the client. This works well, but it introduces load on the relay server and impacts both latency and bandwidth.
Implementing STUN / ICE would enable direct SSH connection from the client to the server, by just signalling the server to the client and vice-versa. In the rare cases where it wouldn't work, the current TURN approach could be used as a fallback.
Additionally, it might be possible to rely on some public STUN server to avoid the public server requirement altogether.
Also, see #11 for an approach which doesn't even need a STUN server (pwnat).
The text was updated successfully, but these errors were encountered: