
Mosh: A replacement for SSH - jayfk
https://mosh.mit.edu/
======
hf
Mosh is a truly impressive feat of thought and, perhaps more importantly,
engineering. The thinking behind Mosh is substantial, the paradigms are fresh.
Reading about mosh on its excellent website, I _always_ leave with a profound
feeling of enthusiasm. Mosh belongs a school of software development ethics
that I'm sorely missing in the world.

However, I do concur that, perhaps, Mosh solves a deep problem on the wrong
level or, even, in the wrong domain. The feeling, already expressed here, that
"tmux oughta do it" never leaves me. Why is that?

Because I know that ssh, by itsself, can handle connection loss quite well[0].
Rather, I suspect, ssh can't deal with IP changes or the destruction of the
underlying interface.

So, here's the rub: Why is a stable, somehow-abstract, network interface with
a local IP, sitting on top of the actual network interfaces, be they wired or
wireless, _not_ the answer? Over the years, on and off, I tried to get the
Linux ethernet bonding stack (ifenslave) to provide me with just that
solution, but was never able to.

Hence, I keep revisiting mosh, then revisiting ifenslave...

[0] On a machine that doesn't dynamically switch network interfaces on demand,
just unplug an ethernet cable, wait a while and plug it back in: your ssh
session will resume.

~~~
crest
You missed the point of Mosh. SSH transfers a bidirectional stream of bytes
between server and client. It uses TCP as transport. You can combine SSH with
tmux to preserve your sessions as tmux sessions. If you use SSH to access your
tmux session you fixed a part of the problem. Your client can now roam by
reattaching the tmux session from a new SSH connection.

The other half of the problem remains: SSH transfers unmodified byte streams
between client and server over TCP. On networks with high latency or high
packet loss this design doesn't work. Mosh fixes this part of the problem by
redefining the problem. Instead of transferring every byte in both directions
it runs a terminal emulator on both sides and the problem turn into: keep the
terminal emulator states in sync. The server sends patches from the last
confirmed client state to the current server state to the last known client
address:port pair via UDP. The client sends the user input (and pings) to the
server via UDP. This design allows Mosh to skip over lost messages.

------
sagichmal
Mosh is brilliant software. I use it every day. Being able to close my laptop,
move to a different café, and open it back up with all of my sessions
seamlessly reconnecting is invaluable.

But -- mosh still can't do proper SSH agent forwarding[0], which is a real
drag. Many of my common workflows become impossible. I hope it gets fixed!

[0]
[https://github.com/keithw/mosh/issues/120](https://github.com/keithw/mosh/issues/120)

~~~
quotemstr
I feel like mosh is fixing problems at the wrong layer. Instead of making
application protocols connectioness, we should make Mobile IP work so that
connections don't need to be broken in the first place, or, failing that,
separate the protocol management from the session persistence system.

Combining regular ssh with screen has worked fine for me for years. Why would
I want to switch to something with a much shorter track record for security?

(By the way: if you want a line-buffered ssh for use over bad connections, run
ssh inside Emacs with M-x shell.)

~~~
morsch
Yes. I was wondering, faced with an unreliable on-train mobile connection, is
there any existing way to improve the content delivery by using a proxy host?

It seemed to me as if the mobile browser kept redoing a whole lot of work, ie.
essentially re-requesting web sites from scratch. I'd like to make a single
request to a web site, have my proxy host complete the request and deliver the
bytes piecemeal to the browser as I go in and out of range.

I think it's possible to do this transparently to the browser, but I think you
might need a proxy host with a reliable connection as well as a proxy software
running on the mobile device that can deal with the situation by telling the
reliable host: I'm back, here's a list of running requests and the last byte I
received, please continue.

~~~
kyrra
I believe this is how the opera browser for ios works, or amazons browser for
their fire tablet.

~~~
Piskvorrr
Alas, both of them are proprietary and monolithic - IOW, you can only use the
infrastructure iff you're also using the one specific client. Not very useful
for extending even for other browsers, or even different protocols - which is
a pity :(

------
zeograd
Too bad mosh needs an udp port to run its own server.

One of the greatness of ssh is its lean network requirements (it can even be
considered https if seen from intermediate proxies, hence whitelisted) and
this extra udp port is quite a burden in some environments.

I still agree that mosh is a fine tool for mobile users. I'm just a tad
worried about its security layer implementation being less audites than
openssh for instance (as mosh isn't as widely used)...

~~~
icebraining
Well, Mosh still uses OpenSSH for the initial authentication, and during the
rest of the connection, all the security is handled by a single layer (AES-
OCB, using the reference implementation), which is not specific to Mosh.

That said, it has never been audited.

------
kolev
It's not a replacement at all - it doesn't support scroll back (screen
buffer). Latency often changes the order of keystrokes. I've tried to used it
so many times and gave up every single time after the enthusiasm ran out.

~~~
theon144
>Latency often changes the order of keystrokes.

I've never had this experience! And I've used mosh for some time extensively
on all sorts of connections ranging from abysmal to horrible. Maybe you used
an older version?

~~~
kolev
Yes, it's been an issue in the past as I gave up on Mosh. To be fear, I will
reinstall and try. Worst of all, I was having these issues on relatively fast
connection, so, that's what turned me off as I could imagine when there are
real latency issues in place.

------
sjackso
Several commenters are asking what mosh provides that's better than
ssh+screen/tmux.

A few years ago I spent a summer at a remote field site, sharing a flaky T1
with 100 other people over equally flaky site-wide wireless network. (Many of
those people were undergraduates who had been politely asked not to use the
research network to access facebook, but, well, you know.) Not only was packet
loss common, but latencies to an outside host varied whimsically from 50ms to
2000ms. In those conditions ssh was unusable, tmux or not. I was able to do
work on remote servers only because of mosh.

~~~
ryan-c
Let me clarify a little more. Mosh _hides latency_ by doing display
prediction. It guesses what the results of your keystrokes will be and
displays them locally, highlighted as predicted with an underscore.

------
blueskin_
My main issue with mosh is having to open a massive UDP port range, which just
goes against my instinct when it comes to security.

The other security issue is the whole 'seamless reconnect' \- it's probably
been thought of, but does anyone have any links to how they've mitigated the
massive MITM risk this opens users to?

~~~
skrause
You don't actually need to open a UDP port range, a single UDP port is enough.
But then you'll have to tell mosh with the -p parameter which port it has to
use.

------
emikulic
I wish half of this had been implemented in tmux instead. tmux is already
client/server, add local typeahead (which is very cool) to the client and let
me run it over whatever transport I want (spoiler: it will still be ssh,
because I don't really benefit that much from their reinvention of TCP)

~~~
sina
Both "client" and "server" in TMUX terminology are on the same machine. AFAIK,
MOSH creates a terminal emulator in each connected machine and keeps them in
sync.

------
nieve
My biggest complaint about Mosh is that how it handles the login sequence
breaks common .bashrc/.bash_profile idioms like

test -z "$BASHPROFILEREAD" || return

(to avoid double-sourcing) and there's no good way to fix them. I haven't
tested ksh93/zsh yet, but I suspect similar issues. I suspect the developers
do little more with their shell initialization than set a few aliases and
variables so it's not an issue for them, but fixing it for myself is far more
work than worth it. It's too bad, everything else works well for me with mosh.

------
phil_ips
Was thinking before opening the link.. do we really need a replacement for
SSH?

> supports intermittent connectivity

That's all you need to say really..!

~~~
marcosdumay
Screen deals with intermittent connections just fine. I still don't see the
need.

~~~
jdong
I don't think you've ever actually been on a bad connection. mosh has saved my
ass more than once when I've been stuck with a satellite connection in the
middle of nowhere. (Try fixing a failing loadbalancer while on a transatlantic
cruise, using SSH)

~~~
xux
Why not just use Tmux or Screen?

~~~
jdong
Because even a small amount of packet loss makes SSH absolutely unusable (e.g
making it completely freeze), whereas I've managed to function using mosh with
around 30% packet loss.

------
zobzu
are those links becoming invalidated after 3month and auto reposted or
something ? This URL must have shown up like 3 times on the front page in the
past year alone

------
Gonzih
How it can be replacement if it uses ssh to start daemon on server to listen
on UDP port? But yes, it's great. Still not perfect, still issues with non
unicode chars sometime, still some issues with rendering from time to time.

~~~
rspeer
> still issues with non unicode chars sometime

What's a non-Unicode character, and where would you find one? Do you mean the
crazy private use characters used to make fancy Vim status lines, or something
else?

------
dllthomas
I actually find lack of local echo somewhat valuable. When my connection is
spotty, that gives me immediate feedback about what is and is not getting
through.

~~~
sjackso
You get similar feedback when using mosh -- text that is echoed locally but
has not yet reached the remote host is displayed with an underline. On a bad
connection, you see underlined text promptly as you type, and the underline
gradually disappears as the network catches up.

~~~
dllthomas
Ah, great!

------
snvzz
Mosh is nice, but "A replacement for SSH" is quite stretching it, considering
it does use ssh to setup its own connection and so it depends on SSH.

It also doesn't provide most of SSH functionality, and it doesn't support IPv6
yet, whereas SSH does.

------
theandrewbailey
Getting 403 forbidden, so have some cache:

[https://webcache.googleusercontent.com/search?q=cache:Sb3IKA...](https://webcache.googleusercontent.com/search?q=cache:Sb3IKAMHCSEJ:https://mosh.mit.edu/+&cd=1)

------
afarrell
I have been using mosh for two years now and it has greatly improved my life.
It means that rather than buying a brand-new laptop, I can just connect to a
$5/mo linode with an SSD and program on that.

------
pbhjpbhj
FYI to install on Kubuntu 14.04 I only needed to "sudo apt-get install mosh"
to get mosh 1.2.4a.

------
lasermike026
Has security review been done?

~~~
icebraining
No:

    
    
      Q: Has your secure datagram protocol been audited by experts?
    
        No. Mosh is actively used and has been read over by security-
      minded crypto nerds who think its design is reasonable, but any 
      novel datagram protocol is going to have to prove itself, and
      SSP is no exception. We use the reference implementations of
      AES-128 and OCB, and we welcome your eyes on the code. We think
      the radical simplicity of the design is an advantage, but of
      course others have thought that and have been wrong. We don't
      doubt it will (properly!) take time for the security community
      to get comfortable with mosh.

------
teamhappy
Still one of of my favourite tech talks. Mosh is great too.

------
plicense
Aw, fonts - [http://imgur.com/v9E9vOY](http://imgur.com/v9E9vOY), the full
stop under the P.

------
zhovner
Scrolling still not working?

~~~
dedward
And it likely won't.. at least not without giving up the ability to work over
high latency/lossy connections properly.

The reason mosh shows you current-state rather than playing catch up with
every byte transmitted by the terminal is very deliberate, and desired.

------
xxdesmus
Nice repost? Posts about Mosh from 2 years ago:

[https://news.ycombinator.com/item?id=3819382](https://news.ycombinator.com/item?id=3819382)
[https://news.ycombinator.com/item?id=5016745](https://news.ycombinator.com/item?id=5016745)
[https://news.ycombinator.com/item?id=3871687](https://news.ycombinator.com/item?id=3871687)
[https://news.ycombinator.com/item?id=3814589](https://news.ycombinator.com/item?id=3814589)

...just to name a few examples.

Mosh is awesome, but also not something new.

~~~
dang
A few reposts are ok if the story hasn't had significant attention on HN in
the last year or so:
[https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html).

[https://news.ycombinator.com/item?id=6321474](https://news.ycombinator.com/item?id=6321474)
was within a year, but I guess was borderline, so we'll leave the current
post.

~~~
xxdesmus
gotcha, thanks for the clarification.

Mosh continues to be awesome, and definitely deserves to be more well known.
It works wonders when you have a crappy connection.

------
hbbio
In French, Mosh is exactly pronounced as "moche" which means ugly.

Of course, this doesn't change anything in the project interest!

~~~
pbhjpbhj
In en-gb it means wild, aggressive dancing synonymous with the stage-front
area dancing at a heavy-metal concert.

[http://en.wiktionary.org/wiki/mosh](http://en.wiktionary.org/wiki/mosh)

