[mosh-devel] Mosh on Kuberbnetes

[Anders Kaseorg]

You may have a misunderstanding about how a Mosh session is set up.  The 
mosh script launches a mosh-server on the remote system via SSH; 
mosh-server picks a port number and a random encryption key, and writes 
them to stdout, where they go back over SSH to the mosh script; then the 
mosh script launches mosh-client passing the IP address, port number, and 
encryption key.  The newly launched mosh-client and mosh-server processes 
exchange UDP packets encrypted with the shared key; communication is 
successful if the packets can be decrypted.

There’s no separate “key checking” step to be disabled.  And it doesn’t 
make sense to “refuse more than 1 connection on the same port”, both 
because UDP is connectionless, and because a new mosh-server is launched 
on a new port for each Mosh session (it is not a daemon like sshd).

The easiest way to put Mosh servers behind a load balancer is with 
round-robin DNS where a single hostname resolves to many addresses, or to 
different addresses for different clients and/or at different times.  
We’ve already gone out of our way to make the mosh script resolve the 
hostname only once and use the same address for the SSH connection and the 
UDP packets, because that’s needed for MIT’s athena.dialup.mit.edu pool.

If that’s not an option and you really need all connections to go through 
a single load balancer address, you could try wrapping mosh-server in a 
script that passes different disjoint port ranges (-p) on different 
backends, and forwarding those ranges to the corresponding backends from 
the load balancer.

Unrelatedly, brow.sh doesn’t resolve with DNSSEC-enabled resolvers like 
1.1.1.1 or 8.8.8.8, seemingly due to some problem with the DS records set 
with the registrar: https://dnssec-debugger.verisignlabs.com/brow.sh.

Anders