Mosh: Send a mosh-server payload along with ssh connection
I just discovered mosh and it looks very promising! But I did expect at first to have a real drop-in replacement of ssh (ie not having to install mosh-server).
Did you consider embedding statically linked mosh-servers for different architectures, and sending them with the first ssh connection? You could have a strategy to detect server os/architecture and sending correct binary this way.
I just imagine that being fully retro-compatible (by not having to change the default setup of most servers), this feature would allow mosh to be much more easily adopted.
Disclaimer : I am not a sysadmin veteran and I could easily miss an obvious problem with this suggestion. Also, sorry if it's a duplicate I missed.
laurent-descrivan
All 12 comments
Statically linked binaries are a bad idea - a maintenance and security hole waiting to happen.
What you propose is itself a security hole (even if the mosh-server was dynamically linked) because
you want to push an executable and run it on the remote end. If you are trying to connect as a user who can elevate their privilege level on the remote system then you'll be able to subvert the security of the remote host.
This issue should be closed as "will not fix".
jmcp
on 16 Jul 2014
Fair enough, I see that it might be a maintenance nightmare and this reason alone is enough.
However, for the sake of understanding, what is preventing a compromised ssh client to send such a payload? How is trusting the ssh client not to do it is different from trusting the mosh client not to do it?
laurent-descrivan
on 16 Jul 2014
This is honestly the first idea that I had when I heard about this. Bootstrap ssh to send the daemon over and forward a port through. Use ssh to reconnect and reforward the port as needed to connect back to the previously started user-mode daemon. Full-on backwards compatibility, simple, no need to install mosh on servers you don't own.
Also, the large statically linked binary thing mentioned by @jmcp is a red herring. Small dynamically linked should be easy enough to do for most common distros. There is no need to elevate privilege - use a non-privileged port, run the binary in user mode.
When this feature is implemented, the barrier to entry for new users becomes close to non-existent. Personally, I'll wait until something like this is available. Until then, autossh + screen or otherwise.
robmccoll
on 3 Sep 2014
For that matter, go read the homepage of the project.
"Mosh doesn't listen on network ports or authenticate users. The mosh client logs in to the server via SSH, and users present the same credentials (e.g., password, public key) as before. Then Mosh runs the mosh-server remotely and connects to it over UDP."
"No privileged code. No daemon. You don't need to be the superuser to install or run Mosh. The client and server are executables run by an ordinary user and last only for the life of the connection."
Mosh already does everything except for ship itself through. Sounds like it wouldn't have significant library needs (security could be totally managed by ssh - currently looks like they do some of their own crypto).
robmccoll
on 3 Sep 2014
+1 for sending over a statically linked mosh-server. Mosh is cool without it, but actually usable with it.
placeybordeaux
on 5 Sep 2014
What you're asking seems to be mentioned in #188, I'm interested in trying something like that as well.
Manouchehri
on 25 Dec 2014
You can do it with bash.
notorand-it
on 2 Jan 2015
@notorand-it What do you mean?
elyscape
on 20 Oct 2015
@elyscape Bash (https://www.gnu.org/software/bash/) has the ability to handle UDP and TCP packets. In "theory"(tm) you could bootstrap a minimal mosh-like server written in bash in the case you don't have mosh installed in the remote server. Maybe you can also try a number of interpreters on the remote machine. Sending a binary poses constraints on the remote machine (32- vs 64-bit, Intel vs ARM etc.).
notorand-it
on 20 Oct 2015
A python or bash-based mosh server would seem like the most logical approach. Most, if not all Unix machines will have these interpreters, regardless of machine architecture.
I am administering dozens of servers, some of which I don't have root on. Installing mosh on them is not an option. It would be best of the mosh client could streamline all of the necessary steps to run mosh-server on the remote end.
In fact, implemented properly, the need for mosh-server as a standalone package could be avoided entirely. You would just install mosh on your client machine and you'd be good to go.
haarp
on 28 Nov 2015
mosh requires a level of crypto and network support that just can't be done in bash.
As currently coded, mosh has inner loops that do comparison/rendering from complex data structures for the frame buffers for every update. Doing it in Python is certainly possible, but I think it would be too slow to be usable-- the current Mosh design doesn't work well for interpreted languages.
But if anyone can prove me wrong, please do!
cgull
on 28 Nov 2015
Closing as duplicate of #188.
andersk
on 2 Jun 2017
Related issues
shibumi
路
5Comments
a-b
路
6Comments
jscinoz
路
7Comments
brandonkal
路
7Comments
pravi
路
5Comments
Most helpful comment
This is honestly the first idea that I had when I heard about this. Bootstrap ssh to send the daemon over and forward a port through. Use ssh to reconnect and reforward the port as needed to connect back to the previously started user-mode daemon. Full-on backwards compatibility, simple, no need to install mosh on servers you don't own.
Also, the large statically linked binary thing mentioned by @jmcp is a red herring. Small dynamically linked should be easy enough to do for most common distros. There is no need to elevate privilege - use a non-privileged port, run the binary in user mode.
When this feature is implemented, the barrier to entry for new users becomes close to non-existent. Personally, I'll wait until something like this is available. Until then, autossh + screen or otherwise.