
Mosh: the mobile shell - ColinWright
http://mosh.mit.edu/#about
======
saurik
If anyone is interested in the downsides:

1) mosh lowers the average latency, but it causes the perceived latency to be
highly variable.

The issue is that there are various moments where the algorithm somewhat-
correctly decides it cannot predict what will happen due to new incoming
keystrokes. An example of this is after you hit enter: you might be running an
entirely different program at this point.

In essence, the algorithm "warms up" as it makes correct decisions, and once
it decides "ok, my decisions seem accurate: when he types a character they
seem to echo back to the terminal" it makes a sudden transition from "slightly
slower than raw SSH" to "much faster than SSH and only slightly slower than a
local screen session".

These sudden transitions are jarring: when they happen to you with normal
connections the expectation is "oh, my connection is failing", a feeling that
with mosh you have every time you type a command.

Meanwhile, for the interactive-shell or complex-text-editor use case, these
"unpredictable events" always happen at the worst possible moment: when you
first start doing something; the result is that the perceived incidence of
latency is actually worse than with normal SSH, as every "new event" has a
higher latency... by the time it starts prediction, you are probably "in the
flow" enough to not even be paying attention.

2) it relies on a specific range of UDP ports

Because it operates over a custom supposedly-mobile-optimized protocol, it
tends to end up being inaccessible when you actually need it due to pervasive
modern firewalls. You'll start a session at home, go to the office, and...
nothing... because you can't communicate over that UDP port. This happened to
me quite often while evaluating mosh.

3) it doesn't have a good way to reconnect later

While it supports sitting down at a different computer and taking over your
session, it requires you to drop to a rather low-level mechanism based on
knowing the secret session key that was established at the time the server was
setup. This actually undermines the "mobile" use case, as it only lets the
connection be mobile, not the session.

(I also have some specific issues with a library it relies on for spoofing
hostnames in wtmp: just having that library installed on your system opens a
vulnerability where any non-privileged user can spoof their hostname as anyone
else... their opinion differs, but it seems to mostly be due to a knee-jerk
reaction of "you don't get fired for avoiding setuid" than "this is actually
secure".)

The result is that after spending a bunch of time testing it, working with the
codebase, getting frustrated at a bunch of the design decisions, and then
having it both totally fail to work in real-world network settings _and_
become yet another source of infuriating latency, I pretty much dropped all
interest in the project and replaced it with autossh, which worked great.

    
    
        function cysh() {
            AUTOSSH_GATETIME=0 autossh -M 0 -t -e none \
                -o ServerAliveInterval=2 -o ServerAliveCountMax=4 \
                "$1" screen -xRS "$2"
        }
    

The primary downside of this is that it doesn't handle the packet loss problem
well, as you are really just still using normal SSH to do the connections. The
session might get weirdly slow and even lock up in these packet-loss
situations.

However: it doesn't require any special code on the server, which is a
downside of mosh I didn't even list above (as it is fairly obvious and
something you know going in): this means you get to use it for every
connection to every server you might ever care about.

Otherwise, you get everything you expect from normal ssh and screen: it works
everywhere you might theoretically have been able to connect to the server
anyway (so no ending up at the client site and finding out that they firewall
UDP), it is obvious how to reconnect to (or even share) the screen session
from a different computer or a different client without special software, and
you don't need to even contemplate "what if this introduces a security
vulnerability by running a new daemon on my server?".

The other annoyance of using autossh is it is pretty adamant about doing
exponential back-off on reconnect, and in the naive way I have it setup in
that function it is also going to be doing slow-to-fail DNS requests as it
attempts to do the reconnection sequence, so the result is that the "open
laptop, wait for all terminals to connect" sequence doesn't always click
perfectly.

However, that is easily fixable by using a simpler wrapper (to be clear: use
autossh when autossh is appropriate; it is designed, however, for server-to-
server backend links to maintain persistent port forwarding), so I bring you
cysh.sh, which is what I actually use (and which I've done some testing with
others to verify works on random platforms):

<http://test.saurik.com/hackernews/cysh.sh>

(Yes: you are now downloading a random shell script from someone on a web
forum. However, it's like 35 lines of very easily readable sh: you should just
read it; hell, after reading it, you might consider it so simple you just want
to rewrite it for yourself. ;P)

You use this in the same way as the function, which I didn't even document
earlier anyway as I knew I'd just be replacing it with this shell script by
the end of the comment ;P.

    
    
        cysh saurik@server.saurik.com stuff
    

This will reconnect to the existing session named stuff on server.saurik.com
with the username saurik. It will disconnect other clients when it connects:
if you don't want that, change -dRS to -xRS. It also disables normal screen
control with ctrl-A (so it feels more like "just a console"): if you don't
want that, remove -e'\0\0'. If you want some other screen setting: just add
it. ;P

(BTW, if you are curious why I have it set to do -dRS "by default" as opposed
to -xRS, is that if you have multiple clients associated with the session the
size of window can't be automatically updated; the result is that you often
find yourself connecting back to copies of things like irssi or even bash
prompts that are now the wrong width; -dRS works perfectly out of the box.
Many people, however, know enough about screen that they love -x: if that
includes you, you should definitely just change that.)

So, if you don't need the "severe packet loss" protection, I really think you
are better off just passing on mosh and using something infinitely simpler
cobbled over ssh. The latency mitigation feature are overrated or even
annoying, and it seems many people actually just want mosh for "easily auto-
reconnecting mobile shell", something you seriously can solve very well with a
very short shell script and no special server-side logic.

(If anyone tries using that script, it doesn't work, and you want help
debugging it, I'm happy to do so; that said, it is purposely not "a product"
right now because different people seem to want different things, and it is
frankly really simple to write this from scratch if you need it, or just kind
of pull it apart and fix/change whatever you don't like about it: just
attempting to get an automatically-reconnecting shell is a fairly simple
problem.)

~~~
moe
0) It sabotages your scrollback (just like screen), no more mouse-wheel
scrolling. Showstopper for me.

~~~
geofft
That's somewhat on purpose -- terminal rendering is on the server-side, so
that if there's a lot of changes to the screen (a long terminal command, a
full-screen curses app that did several updates, etc.), and the connection was
bad during that, then the client only needs to see what's currently on the
screen. If you're ever used a curses app over a bad connection, and seen it
slowly update itself over the course of several seconds to catch up, you can
understand why this is useful.

As other folks have mentioned, if you run screen on the server-side, then you
can ask screen for its scrollback. Also, see this open ticket:
<https://github.com/keithw/mosh/issues/2>

~~~
moe
Yup I know the reasons and implications (have written my own terminal
emulators in the past). I just felt the list is not complete without the
biggest(?) annoyance of them all.

I wish someone would write a "dumb screen" that simply plays back the last n
kb when I re-attach and otherwise doesn't try to emulate a terminal inside my
terminal. screen and tmux (which I use heavily) are terrible crutches from a
distant past that do way more (and poorly) than most people actually want.

I know mosh tries to fill a different niche (high latency links) so take this
less as a stab against mosh but more as a general rant about the fact that
it's 2013 and my laptop, which can render photo-realistic 3d videogames in
realtime, is still not able to seamlessly resume a handful of text-mode
terminal sessions without resorting to one of the above kludges.

Well, first world problems, shoemakers son always goes barefoot, etc...

------
jread
I've spent the past year using Mosh from high latency, unreliable satellite
connections in Afghanistan. I would have been pulling my hair out without it.
My only complaint is the scrollback buffer often gets jumbled.

------
rshm
Previous discussion <http://news.ycombinator.com/item?id=3819382>

------
koffiezet
While a nice idea, licensing issues are a problem for this project... I don't
understand why they didn't use the standard MIT license, but instead went for
GPL3, but still chose a proprietary encryption method.

iSSH on iOS now also experimentally supports it with an own independent
implementation, with an in-app purchase, since the encryption uses a
proprietary encryption method only freely licensed for opensource projects.

~~~
eli
I definitely get the concern over proprietary encryption, but why does the
license matter for an end user like me?

~~~
michael_miller
Many paranoid companies will often prohibit all use of GPLv3 software. The
justification I've heard is that the terms of the license make it possible
that anything you produce using GPLv3 software is also GPLv3. So, for example,
if you use a GPLv3 licensed version of emacs, and you write some code, the
code you wrote will also become GPLv3. It's a very conservative reading of the
terms of the license, but understandable for companies which have most of
their net worth tied up in source code.

~~~
hdevalence
> The terms of the licence make it possible....

No, they do not. In fact, the example you gave is exactly the example given by
the FSF to explain why this does not occur.

[http://www.gnu.org/licenses/gpl-
faq.html#CanIUseGPLToolsForN...](http://www.gnu.org/licenses/gpl-
faq.html#CanIUseGPLToolsForNF)

It's not a conservative reading so much as an incorrect one, and it's also
nothing to do with v3 versus v2. The concern about v3 is that it means that
companies are not allowed to use patent or hardware restrictions to do an end-
run around the GPL's user protections.

The "viral contamination" FUD has been around for over a decade at least; it's
nothing to do with version 3.

------
HorizonXP
I just installed this on my Chromebook with Ubuntu, and on my EC2 instance.
I've been very frustrated with the lag I was experiencing while typing in the
shell, due to high/variable latency. In my very preliminary testing over the
last hour, this has solved my problems almost completely.

Security is less of a concern because I'm running OpenVPN to my instances, so
the UDP traffic mosh uses is encrypted anyway, and not open to the public.

One issue I did notice is that irssi isn't refreshing quite as quickly. Seems
to lag behind the conversation a bit. I'll have to troubleshoot. I wonder if
running byobu/screen is part of the problem.

~~~
carbocation
I also run a similar setup and am trying out mosh now. I agree re: the lag in
irssi. Additionally, if I start typing into irssi and then rapidly delete the
text, I can delete the channel name temporarily:

    
    
        [#startups] I was thiknin^H^H^H^H^H^H
        [#start

~~~
Maakuth
Yeah, this is due to their clever predictive local echo not being that clever
all the time. When the client sees that sending ^H actually results in
character disappearing, it imitates that behaviour locally for next ^H:s
making you experience less lag. Most of the time it works well but there's
these edge cases with funny results.

~~~
LeonidasXIV
Well, my simple solution would be to delete the channel name from the prompt
because it does not serve me any purpose. Too bad I don't actually know how to
do this in irssi, I already looked for an option.

~~~
coolj
You can use "/statusbar prompt disable" (and "/save" to make it persistent).

------
zobzu
After using mosh on and off for a year, I realized that what they wrote in
their PDF is absolutely true:

mosh latency isn't much different from SSH latency, which is a common
misconception. What mosh adds is:

\- decent prediction (this is what mitigate most of the latency)

\- integrated auto-reconnect (even thus auto-ssh and others do the same thing,
they're not built-in)

\- mostly asynchronous keystrokes thanks to UDP+stream protocol, so if you hit
^C it will abort stuff even if the screen is scrolling. Note that the way
keystrokes are handled makes it susceptible to a timing attack, and there
might have been work to mitigate this that i'm unaware of.

~~~
saurik
> so if you hit ^C it will abort stuff even if the screen is scrolling

I might be wrong, but AFAIK the fact that your terminal isn't handling this
correctly already is due to a flow control setup problem somewhere in the
chain (probably the terminal itself, as usually the server-side components are
the most ancient): if your local console is only able to download and display
and scroll data at a certain rate, it should "push back" on the server to get
it to send you data at a slower rate, which in turn will push back on the
terminal. When setup correctly, this flows all the way back to the original
application, which will itself slow down whatever it is that it is doing.

~~~
zobzu
its tcp congestion issues. ^C will work just fine locally. it would also be ok
if there were 2 tcp channels. or. udp. ;)

~~~
saurik
I don't mean locally: I mean that if you have all of your flow control stuff
setup correctly, you shouldn't ever end up in the situation of "I hit ctrl-C
to try to stop the massive stream of text, but this text was actually
generated a minute ago and was streamed to me in a massive 10MB block and
buffered in a bunch of sockets, so my ctrl-C is meaningless".

------
doctorpangloss
_Most network programs lose their connections after roaming, including SSH and
Web apps like Gmail._

Gmail.com has been a roaming-safe/disconnect-tolerant web app for quite some
time now. It is even tolerant of huge disparities in time, as far as SSL will
allow it to be.

I wonder what Gmail client they're talking about...

~~~
lwf
Gmail often says "reconnecting" for me, and this does not always work
correctly unless I manually tell it to "reconnect now".

------
niggler
Relevant discussion from an hour ago:
<http://news.ycombinator.com/item?id=5016357>

------
kami8845
I love mosh, I've been using it since it was released and it's been working
flawlessly.

------
nicoritschel
<http://www.zinger-soft.com/iSSH_features.html>

iSSH includes the mosh protocol as a 99c in-app purchase. Use mosh on your
mobile device, just where it should be!

------
jakozaur
I would love to see mosh-like solution, but client only.

Pretty much a wraper to ssh which will use screen plus some predictions. I
guess it could get 80% of mosh benefits without the hassle of deploying new
software on servers.

------
Karunamon
Are there any versions of this that work with Windows GUI apps? (Along the
lines of puTTY instead of Cygwin)?

------
daenney
Mosh has been brilliant so far. I travel a lot by train but even SSH'ing over
the trains WiFi can be problematic. Connecting through Mosh solves all the
typical issues and with local echo you can continue to type as if the
connection was still up.

------
kolev
I loved Mosh... until I started using it. Latency is definitely a big problem
for me - even on fast connections. Often keystrokes arrive in the wrong order
if you type too fast, making it useless.

~~~
keithwinstein
Hi, thanks for your feedback! I have heard of this happening with iSSH's
clean-room reimplementation of the protocol, but never with Mosh. Please file
a bug report at <https://github.com/keithw/mosh> because we are eager to trace
this down. (We have never heard of this happening to anybody, and it should
not be possible if all is well.)

------
DoubleMalt
I simply could not work without mosh. I do not experience significant lag and
it allows me to have connections open even if I switch from WiFi over to 3G
and back which is often the case.

------
wangweij
I know this sounds not very secure, but since one of the best features of mosh
is that you needn't install it, why not provide a place to download binaries
for all platforms?

------
jiyinyiyong
I was sad because it was disturbed when I try to login my VPS(Burst) from
mainland China with Mosh, after I was so happy to find it and installed it on
all my Linux OS.

------
visarga
So, er, does the [mo]bile[sh]ell have a mobile app for iPhone?

~~~
geofft
iSSH has an independent proprietary implementation of the mosh protocol as an
in-app purchase. (mosh itself has license terms explicitly permitting
redistribution on the App Store, but nobody has done the port yet.)

~~~
nwh
Panic has mentioned that they will fully implement Mosh into their Prompt iOS
client, it's just not high priority at the moment.

<http://twitter.com/panic/status/281208183094145024>

~~~
visarga
By the way, with mosh we can have persistent shell over changing IP address,
is there a text editor that would work with SFTP in a similar persistent way?

I mean, suppose I work on a project, close the laptop lid and some time later,
open it. I might have a new IP, or in general the SSH connection might have
been terminated.

In that case I would have to reload all the files in the project. Would it be
possible to do IP hopping and maintain the SFTP connection unterminated?

I use Mac OS.

~~~
geofft
There's a ticket (with no discussion) about a mosh equivalent for SFTP/sshfs:
<https://github.com/keithw/mosh/issues/280>

------
rckrd
I love the concept, but "Clients may not even know they have roamed".

Can anyone briefly rehash some of the security issues that were brought up
with mosh?

~~~
geofft
I don't understand your first sentence. Are you claiming that that's a
security issue, or a problem somehow?

------
leh0n
I used it for like 30 minutes before I realized there was no way to enable SSH
agent forwarding.

------
st3fan
Mosh needs a proper security and crypto review. AFAIK that has not been done.

~~~
geofft
Has that been done for OpenSSH?

------
tquai
I wrap a normal OpenSSH connection in CurveCP.

~~~
zokier
CurveCP seems interesting (like most of djbs work). Would you get most of its
client-side benefits (mobility support etc) if you'd create VPN over CurveCP?
That way you wouldn't need to install it to the destination servers, but
instead use a server with a stable, fast connection as a gateway.

Or is there some neat VPN solution that has good support for mobility already?

~~~
visarga
Is there a neat VPN solution that would work through SSH ?

It is much easier to use one of the servers you have than pay for a VPN
account to a provider.

------
tkahn6
I would love to use it but last time this came up (almost a year ago), people
voiced security concerns.

Any different perspectives on this now?

~~~
zobzu
One of them, besides the elite crypto issues, is that mosh requires having a
wide range of UDP ports open to function properly. Many admins are not willing
to do that.

~~~
geofft
You can pick a single UDP port and use `mosh -p`.

Absent a single privileged moshd, though, every user's mosh-server process
needs to have its own UDP port, hence the default behavior. If you want to
assign yourself a UDP port and open that single port on the firewall, you can,
though.

~~~
zobzu
which is exactly the issue.

