Hello Mosh Developers, This is my first post to the list. Thanks for the introduction Keith.
I'm the author of Texttop (soon to be re-released as Browsh): https://github.com/tombh/texttop It is a fully-modern text-based browser. You can actually SSH into a demo: `ssh brow.sh` (no auth needed). This is not a publicised service yet, there are only 3 instances, so don't share it too much. Anyway, my problem is that the SSH service is running on Kubernetes behind a load balancer and of course the load balancer likes to spread out connections to the instances. Thus, by default, it cannot guarantee that, when using Mosh, the upgrade from SSH port 22 to Mosh port 60001 arrives at the same instance. I won't go into why, but it'll be a significant hurdle to enable IP-based sticky sessions, so that users are guaranteed the same instance. So first I just want to cross other approaches off my list. My first thought is whether anyone has ever wrapped mosh-server? Eg; How straight forward would it be to have a proxy listening on Mosh ports to intercept the handshake from mosh-client? That way I could have my own centralised token management, that once verified the token, could fire up mosh-server and feed it the incoming connection. At the very least, I could actually get away with just running mosh-server without key checking, as this is currently all only for demo purposes and no actual authentication is needed. I just need mosh-server to refuse more than 1 connection on the same port, which I assume it already does? Would it be as simple as patching a single line to disable key checking? Many thanks for any ideas or feedback, Tom _______________________________________________ mosh-devel mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/mosh-devel
