I think this is the primary reason why there are still no alternative clients. And specifically, no good Mobile clients.
The reliance on OCB is unfortunate. I wish the Mosh developers would introduce multiple cipher schemes so that people can move away from OCB.
Unfortunately the protocol is also pretty poorly designed, with no easy backward compatible way to do this.
For example, when a client starts a session, the server prints "MOSH CONNECT 60001 sdmDrHqo8DBdpKxtAFAUyw" where the last part is the OCB key. It should have been prefixed with the ciper type for extensibility, but it is not. So this would need a backward incompatible redesign to get it going.
This is a red herring. OCB --- which is possibly the best "mainstream" authenticated encryption construction --- has a blanket patent license for open source software. It applies to any software licensed under any license recognized by OSI, and its only restriction is that the license is withdrawn if you initiate patent litigation.
OCB should be far more widely used than it is.
Meanwhile, configurable "cipher schemes" have in practice been a disaster. They are, for instance, the reason we still have RC4 in TLS today, despite knowing for almost 2 decades now that RC4 is broken.
> Meanwhile, configurable "cipher schemes" have in practice been a disaster. They are, for instance, the reason we still have RC4 in TLS today, despite knowing for almost 2 decades now that RC4 is broken.
If TLS had hard-coded RC4 with no alternatives, how would we be better off?
You have one cipher, deployed in exactly one authenticated encryption construction. The protocol has a version. If the cipher is weakened or broken, you upgrade the whole protocol. You don't add better ciphersuites to the existing protocol to compensate.
Having a bunch of ciphersuites, all believed at the time of their inclusion to be strong, just maximizes the attack surface of the protocol. Having ciphersuite negotiation at all practically guarantees that interoperability will require lowest-common-denominator security.
One reason that independent alternatives do not exist is nothing to do with patents, and everything to do with the protocol never actually being properly documented.
Why do you think it's missing it? It has the same persistence as the mosh-client on a deskop. That is, the connection will persist as long as the client process exists. If you are observing anything else, that would justify a bug report on Blink. The one complication is that iOS can sometimes kill background processes at will, which would also kill the mosh-connection. As far as I know, the Blink team is currently working on dealing with this better (issue #59). It shouldn't happen very often, though, and I've certainly had Blink persist in the background for multiple days.
"Open standard" doesn't really mean anything. It's standardized, in that there is a standard (actually, multiple compatible standards) that you can code to and end up with interoperable OCB. The complaint upthread is that OCB is patented, which it is. But for many years now, OCB has been free for open source software.
The license terms are vague. Is it connected to OpenSSL or not? Do you have to ask the author permission or not? And it is limited to open source software.
Nobody wants to involve expensive lawyers, so for many folks that rules out OCB.
Mosh is a great idea, but by connecting it to OCB, the authors completely stalled more widespread adoption. That, and like you said, the complete lack of protocol spec.
X Forwarding and TCP Forwarding is also insecure. Not everyone has the same threat model, but for the average person it's a bad idea to do agent Forwarding unless they fully understand the consequences. This doesn't mean the OpenSSH team should remove it.
A patch for SSH Agent forwarding has existed for 4+ years, and there have been several iterations of PRs to merge that into Mosh. The maintainers don't care enough to merge working code for an oft-requested feature.
No, what it shows is that this project is just in maintance mode. There is plenty to be improved, but there is zero momentum.
This is hard for open source projects in general. What it needs is not just a happy user base, but also developers and a strong leader wanting to move this into the future. I think specially the latter is missing. I think Mosh was a great thesis project, but stalled after that.
It has so much potential. I wish they would push this to the next level and do proper protocol documentation and an IETF proposal like an RFC.
I figure this can go along like screen for a long time. I remember in about 1999 I was really annoyed that screen wasn't getting better fast enough and no one wanted my patches. Then I got used to using screen and it was fine. Now the cool kids use tmux or something and I can't be bothered to change, but I am abstractly glad the world is improving. Similarly I expect someone to clone/replace/improve mosh, and for people who demand the best new functionality to eventually head there.
Used moshed a lot when I was travelling in the Philippines and done some devops on US servers. It works great and better than ssh (compressed), even with flakky bad connection, high ping to US and 500Kb/s on an island.
Tip for getting scrolling back also working:
mosh yourserver -- screen
Ctrl+a Esc let's you scroll through your screen (with iTerm also with your mouse scroll).
I would rather have the terminal's native scrolling... is that really impossible with mosh? I know I can use screen but I don't like screen's scrolling behavior.
It's "impossible" as defined because the advantage of Mosh is it synchronizes your current screen (the visible, 80x25 or whatever part) as if it were frames in a variable-bandwidth video stream. So, if you're behind a very bad connection and you cat a large file, the scrolling all happens server-side, the intermediate frames get dropped, and only the final frame actually gets sent to the client.
Meanwhile, in ssh, if you're behind a very bad connection and you cat a large file, your TCP bandwidth gets throttled down, but it still has to send the entire file over the connection, driving performance way down.
There is a fork of mosh (https://github.com/4ast/mosh/commits/master , primarily the "use UserStream instead of Terminal" commit) which disables the frame-sync behavior and just uses the byte-stream-sync code (which is used for keyboard data) to sync the raw bytes / ANSI escape codes back to the client. I haven't tried this, but my guess is that you'd be very sad once you accidentally catted a large file, but if you manage to never do that, you'll get mosh-like behavior but also scrollback.
I think you could also change the mosh model to involve maintaining scrollback server-side and syncing it (so you'd render and sync a (80+10000)x25 array, not just the last 80 lines), possibly at lower priority than the non-scrollback portion of the screen. I don't know if anyone's tried implementing this.
(Personally I just use screen anyway, so this isn't a major pain point for me)
I think mosh could be improved with a single trick. Native scrolling for last 10000 lines is super useful. however 99% of time user only looks at say 150x80 chr screen.
Mosh syncing that 150x80 screen is a superb idea. Udp is great for mobile hotspot connections. However mosh server should save a buffer of 150x10000 on server side. Only sync 150x80 but If user uses native scroll then it should ask server for last X lines depending on scroll position.
But native scroll is native. There's no way for mosh, a program running inside the terminal, to know when a user is trying to scroll, and fetch data then.
If you want non-native scroll, just nest mosh inside screen/tmux.
(That may actually be why my theory doesn't work: once a line has scrolled off the screen, there's no way to update it, I think. So even if mosh wanted to do background, low-priority sync of scrollback, it couldn't. The only way to update the scrollback is to write the scrollback before writing the current screen.)
How many kilobytes are in 10000 lines of text? Less than about a megabyte, right...
There could be a happy medium mode or setting that enables scrolling as you described by emulating the keyboard behavior, but mosh would recognize through some buffer capacity if you catted more than about 1MB and skip to printing the last 0.75MB of it. (Makes me want to go on and read that patch you sent to see if I can get it to work like that...)
You probably didn't mean to read more than about 1000 lines of text into your terminal so you could mouse cursor select it by hand into your paste-buffer. You answered very informatively, thank you.
That's probably doable. I think you don't want to start with the patch I linked, since that disables all terminal sync and all use of the Terminal classes. Instead, try editing Terminal::Framebuffer to have a concept of both normal rows and scrollback rows, and adjust Terminal::Display's new_frame function to sync the scrollback rows in some different way. Note that there's already some code in that function to do scrollback, if the diff between two frames consists of scrolling.
(I haven't really contributed to mosh and haven't looked at the codebase in years, so asking on the mailing list or IRC is probably a better place to start)
It's impossible by the design of mosh. Mosh transmitts the current state only... it does not care about the past, so you know what currently happens. Imagine your connection is lost for 2 seconds (or many hours/days) and you reconnect... then you will get the current state right back but not everything from the past will be transmitted. So screen or tmux saves you there.
Mosh is the best kind of software. It's an indispensable tool that I use every day without even noticing I'm using it because it does its one job very well.
I run tmux with nested tmux over a mosh session in a pane for each remote server.
I like Mosh, but it's one of those programs that's "insufficiently better" for me to use, especially since it doesn't implement all the features of ssh.
Yes and no. I don't use mosh these days, mostly because SSH is perfectly fine for my current use case of occasionally having to log in to a remote server and perform some quick one-off task. When I did on-call shifts for large production systems, often with complex tasks that took a while to complete - that's when the combination of Mosh and tmux on a remote machine came in very handy.
I've been using mosh a lot because I travel a lot so my internet is pretty questionable most of the time.
My main issue with it is that it can't clean up after itself.
When I log in, I always get multiple messages like "Mosh: You have a detached Mosh session on this server (mosh [25933])." These are because I closed mosh (e.g. restarted my computer) while not connected to the internet. Especially since mosh is made for unreliable internet connections, you'd think it'd be better about this.
mosh says it can't automatically deal with these sessions (e.g. by reconnecting) because it's not the same mosh process that opened them, but it's the same computer. It shouldn't be too hard to write the information necessary to reconnect to disk.
Just have your mosh server attached to a screen client package (by connecting with "mosh hostname -- screen -rd") and then when you detach that screen client it will terminate the now-useless mosh server. I think that's how most mosh developers do it.
I don't think mosh is just an SSH wrapper. IIRC, it uses SSH to start a mosh session on the server side, but from there it uses it's own UDP based protocol to sync the terminal 'framebuffer' instead of sending character streams.
I don't know why this isn't plugged more, but on a Windows laptop, I found https://github.com/rpwoodbu/mosh-chrome the best client to connect to remote Linux machines. mosh-chrome+tmux is so good that I got a tonne of my friends who previously used VNCs to switch. You can get as good a screen resolution as you want with all your favorite fonts - I use Fira Code that I couldn't get working in putty.
Mosh is great, however, I don't understand why it can't safely failback to regular SSH mode. My point being if the server I am connecting to doesn't have Mosh installed why can't it just warn, and then proceed as a normal SSH session. E.g. if mosh is there you get the benefits of mosh, if its not there well you still got a regular ssh.
Don't fall into the trap of thinking that mosh is based upon SSH, that mosh is just another SSH client. mosh is not "mosh special" SSH in place of "normal" SSH. The actual main run-time operation of mosh does not involve SSH at all.
It is not even architecturally the same as SSH. mosh runs an internal terminal emulator on the server machine. SSH employs an external terminal emulator on the client machine. The terminal emulator on the server machine is the mosh-server program, which is necessary for this architecture to work. If there is no server-side program installed, part of the overall system is missing, for which SSH is not a substitute.
mosh uses SSH, but merely at client startup, as a means of remotely executing the server command that it speaks to and exchanging a shared secret with it. In theory, it could even be changed to use something other than SSH for that, without changing the primary operation of the mosh client and server. (Parsing the output of a shell, including the output of whatever non-interactive startup scripts that shell may run, for a magic sequence is a somewhat rickety mechanism; reminiscent of Fidonet handshakes and Zmodem, but not done as well as they.)
Mosh already negotiates an ssh connection, so I think you can do this safely - attempt to execute mosh-server, if the execution fails, open a normal shell and proxy the data back to the original screen.
You probably don't want mosh to do the proxying, since ssh (the client) is a pretty involved program - it handles signals, it supports port-forwarding, etc.
I sort of suspect SSH ControlMaster would work. I could imagine a mosh client script that sets ControlMaster=yes and a random ControlPath, tries to mosh, and runs ssh -o ControlMaster=no if it fails. And then unconditionally does an ssh -o ControlMaster=no -O exit.
mosh root@192.168.1.10
root@192.168.1.10's password:
bash: mosh-server: command not found
Connection to 192.168.1.10 closed.
/usr/local/bin/mosh: Did not find mosh server startup message. (Have you installed mosh on your server?)
I'm pretty sure they could just change it to execute /usr/local/bin/mosh;/bin/bash without much of an issue. As that is all it is, it is a terminal.
The home page says that web apps like Gmail don't support roaming as mosh does. Why would that be the case? After all, web apps use HTTP requests, which are fundamentally transient (though persistent connections are available as an optimization). Do long polling and WebSockets mess this up?
A TCP connection is identified by the tuple of (source IP, source port, destination IP, destination port), therefore whenever one side's IP changes (the effect of roaming), the connection has to be re-established.
Mosh is built on UDP, where there are no "connections" and the wire protocol is stateless, so when the client IP changes, that endpoint simply transmits some "session cookie" information to the server, which allows it to carry on, uninterrupted.
HTTP runs over TCP, so it cannot roam like mosh does. QUIC (Google's experimental HTTP/2, TLS, and UDP integration) is interesting in part for this reason.
Most interactive webapps such as gmail send many HTTP requests. And those requests do not have to be over the same TCP connection. So the webapp could continue to work even if you change IPs. Any requests going at the time of the change would fail, but ideally the javascript of the app would retry them.
> Try roaming whilst one of those HTTP transactions is in progress
That specific connection silently fails, then the app silently retries, and succeeds - from the end user's perspective, they've switched IP addresses and the webapp still works fine.
Incorrect. TCP does not work that way and the failure mode is nowhere near that smooth. I suggest actually trying it.
No cheating and watching Keith Winstein's video on the mosh WWW site, which shows what actually happened in the case of one fairly well-known WWW app, now! (-:
On my Android phone, the user experience is significantly degraded when that happens -- the app has to wait to re-establish a TCP and TLS connection, which is relatively slow.
> fancy apps like Gmail-in-Chromium or on Android still behave atrociously on dodgy connections or after switching IP addresses. (Have you ever had Gmail leave an e-mail message in "Sending..." for ten hours while merrily retrieving new mail and not indicating any kind of error? Us too.)
So it's about the mobile app, not the web app. Not necessarily HTTP. Maybe someone who knows more about Android can say what happens to existing TCP connections when roaming. Or what protocol the Gmail app is using.
HTTP uses TCP, which is always terribly slow to establish a connection, often useless with high packet loss.
Mosh is UDP, so there is no connection establishment (no need for multiple initial round trips before sending one bit of data) and no indiscriminate retransmission of data. Additionally, you can just continue sending data when your IP changes, connections aren't lost. That typically happens when in a train and you're quickly traversing multiple cells.
Phillip Rogaway holds patents relevant to OCB. See the following for his patent grant: http://www.cs.ucdavis.edu/~rogaway/ocb/grant.htm
I think this is the primary reason why there are still no alternative clients. And specifically, no good Mobile clients.
The reliance on OCB is unfortunate. I wish the Mosh developers would introduce multiple cipher schemes so that people can move away from OCB.
Unfortunately the protocol is also pretty poorly designed, with no easy backward compatible way to do this.
For example, when a client starts a session, the server prints "MOSH CONNECT 60001 sdmDrHqo8DBdpKxtAFAUyw" where the last part is the OCB key. It should have been prefixed with the ciper type for extensibility, but it is not. So this would need a backward incompatible redesign to get it going.