Mosh v1.3 Released
mailman.mit.edu
mailman.mit.edu
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.
I use JuiceSSH [0] on Android, which is based around mosh-client. It works great... What precisely do you mean by the above?
Isn't OCB an open standard? https://www.rfc-editor.org/rfc/rfc7253.txt
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.
* https://news.ycombinator.com/item?id=11612615
Make that 5 years and counting.
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.
If TLS had hard-coded RC4 with no alternatives, how would we be better off?
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.
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.
PRs:
Most recent: https://github.com/mobile-shell/mosh/pull/696
https://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-con...
There is no excuse for denying mosh users existing patches/features and the above link changes nothing.
Tip for getting scrolling back also working:
mosh yourserver -- screen
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)
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.
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.)
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.
(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)
I run tmux with nested tmux over a mosh session in a pane for each remote server.
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.
Looks like it's a desired feature, but just requires some work (in part around parsing the extended escape sequences correctly).
Now if this was javascript, I'd be all over it.
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.
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.
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 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.
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.
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.
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! (-:
> 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.