
Mosh v1.3 Released - nikolay
http://mailman.mit.edu/pipermail/mosh-users/2017-March/000341.html
======
st3fan
Mosh would be more widely available, outside of just this 'reference
implementation', if it did not use patent encumbered OCB crypto.

Phillip Rogaway holds patents relevant to OCB. See the following for his
patent grant:
[http://www.cs.ucdavis.edu/~rogaway/ocb/grant.htm](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.

~~~
tptacek
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.

~~~
Shish2k
> 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?

~~~
tptacek
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.

------
jiqiren
SSH Agent forwarding issue >5years old now. :( [https://github.com/mobile-
shell/mosh/issues/120](https://github.com/mobile-shell/mosh/issues/120)

~~~
emmelaich
To be clear a FeatureRequest not a Bug. So I think the age is understandable.

~~~
st3fan
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.

~~~
tibbetts
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.

------
therealmarv
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).

~~~
yebyen
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.

~~~
geofft
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](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)

~~~
nojvek
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.

~~~
geofft
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.)

~~~
yebyen
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.

~~~
geofft
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)

------
chatmasta
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.

~~~
weitzj
How do you handle the nested tmux shortcuts? Just another keybinding?

~~~
cookiecaper
Not the guy you asked, but for me, nested tmux is usually just pressing the
hotkey twice. ^b^b <cmd> for nested and ^b <cmd> for parent.

------
tombert
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.

~~~
fishnchips
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.

~~~
tombert
For that, just running my stuff in tmux is generally sufficient.

------
Zarel
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.

~~~
tibbetts
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.

------
daleroberts
Still no true color support? :-(

~~~
cyruscm
Considering mosh is a wrapper for ssh, it is very unlikely they'll work on 24
bit color

~~~
baobrien
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.

------
scriptdevil
I don't know why this isn't plugged more, but on a Windows laptop, I found
[https://github.com/rpwoodbu/mosh-chrome](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.

------
xmichael99
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.

~~~
apostacy
I'm sure there are good security reasons. ssh is very conservative about how
it is invoked.

~~~
geofft
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.

------
mwcampbell
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?

~~~
moosingin3space
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.

~~~
Buge
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.

~~~
JdeBP
You've glossed over the part about TCP connections. Try roaming _whilst one of
those HTTP transactions is in progress_.

~~~
Shish2k
> 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.

~~~
JdeBP
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! (-:

------
iso-8859-1
Please note that Mosh does still not support IPv6...

~~~
JdeBP
That is a slipshod statement that is not true. See
[https://news.ycombinator.com/item?id=11573487](https://news.ycombinator.com/item?id=11573487)
for some more accurate information.

------
placeybordeaux
No true color :'(

------
simooooo
This text based page is not a cool way to do a release

~~~
skrebbel
It's not a "text based page", it's a mailinglist archive page. The release was
done by sending an email to a list.

