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 _______________________________________________ mosh-devel mailing list mosh-devel@mit.edu http://mailman.mit.edu/mailman/listinfo/mosh-devel