
Mosh: the mobile shell - tambourine_man
https://mosh.mit.edu/
======
mholt
> _Mosh (and its tolerance for high packet loss) helps Iain Learmonth escape
> from an elevator._

Um, wow!
[https://mosh.mit.edu/elevator.txt](https://mosh.mit.edu/elevator.txt)

~~~
neves
Hey, never, but never, go out of an elevator that isn't leveled in the floor.
By the description, I understand that he jumped from the elevator. If the
elevator started to move, he could have been cut in half. This happened other
day in my city.

If you are stuck in a elevator, wait for professional help to take you out.

~~~
andy_ppp
I once dreamt I was cut in half by a lift. It was not at all fun, so I'd
definitely follow this advice :-D

The other piece of lift related advice (that I really enjoy saying in more
crowded, rickety lifts): I once read if in a lift that is falling you should
attempt to lie flat on the bottom of the lift to limit the impact - preferably
on top of another human. Some hacker news physicist will prove me apocryphal
here I'm sure...

~~~
stouset
If an elevator is falling for long enough to give you time to recognize the
situation, recall this strategy, and actually lie prone upon the floor (in
~0G, somehow)… it's not going to matter.

~~~
vhost-
You both should watch the elevator hacking talk that was given at HOPE X:
[https://www.youtube.com/watch?v=ZUvGfuLlZus](https://www.youtube.com/watch?v=ZUvGfuLlZus)

~~~
nyolfen
Seconding this: I like to put hacker con talks on in the background while I do
other things, and this was the most entertaining panel from HOPE X in my
opinion

------
stegosaurus
Termux[0], the best Android terminal emulator (in my humble opinion), recently
had mosh added to its' package repository.

I currently use it and it's very nice. It makes me long for a better handheld
though (my 4" Moto G screen is difficult to type on, even with Hacker's
Keyboard).

I can have tmux sessions running on servers with say, an irc client running,
mosh in, chat away for a bit, turn it off, the irc client continues running.
Perfect. Same for e-mail using mutt, notes that are backed up on the server
automatically using vim, etc etc. Really nice workflow.

Give me a handheld device with ssh/mosh support and I'm happy. :)

[0] [https://termux.com](https://termux.com)
[https://play.google.com/store/apps/details?id=com.termux](https://play.google.com/store/apps/details?id=com.termux)

~~~
emilburzo
Have you tried JuiceSSH by any chance?

Curious how the two compare.

~~~
ae_keji
Another commentor expressed it, but JuiceSSH is proprietary. In most cases
open source is more of a preference for me than a necessity, but I may need to
sudo or access root over SSH, and there's no way to review closed source code.
JuiceSSH (IMHO) has too much control over my computer for me to use it based
on the assumption that I fully can trust the developer.

~~~
NoGravitas
Agree. Really wish mosh support would be merged into standard ConnectBot. The
linked build on the mosh site is hacked into an old version of an old
ConnectBot fork.

------
chatmasta
I've used mosh on and off for the past year. For me, the best feature of mosh
is the support for roaming. For the "persistence" aspect, SSH + remote screen
is sufficient.

There was a point where I used mosh whether I was roaming or sitting at my
desk, but eventually the friction of mosh made it only worthwhile to use in
roaming situations. By "friction" I mean the small annoyances of (1)
installing mosh on every new server, and (2) requiring the use of screen to
get scrollback buffers. I frequently use screen in my workflows outside of
mosh, so I would often end up in weird states where I moshed into a server and
auto-attached to my dedicated "moshscreen," but then had to detach from it
within the session to move to another screen that I wanted to use.

Because of those annoyances, I now just use simple SSH when sitting at my
desk, and put any long-running commands into a remote screen. But mosh is
still extremely useful in two narrow cases: train rides (moving between cell
towers) and traveling in developing countries (high packet loss).

------
michaelmior
I've had great success with using JuiceSSH[0] for mosh on Android. Great for
those times something important comes up and I'm away from my desk. Trying to
connect without mosh on mobile networks is pretty terrible.

[0] [https://juicessh.com/](https://juicessh.com/)

~~~
curiousgal
ConnectBot is also cool.

~~~
zanchey
You do have to install a patched version for mosh support, but for some reason
I could never get JuiceSSH to connect to our mosh server so I've been using
"mosh for irssi ConnectBot" from
[http://dan.drown.org/android/mosh/](http://dan.drown.org/android/mosh/) for
years.

------
visarga
Love mosh, but having no scrollback is a pain. I can hack a solution by using
screen on top of mosh. They say that version 1.3 will add support for
scrollback.

~~~
VarunAgw
I earlier tried running screen on top of mosh. But it did't worked for me. Can
you tell how you exactly did it?

~~~
clacke2
You run screen on the server side. mosh in, then screen. Works just fine.

~~~
visarga
And then you can use "Ctrl-A [" and arrows to scroll. Screen keeps a scroll
buffer server side.

------
nix0n
TL;DR: Install on both client and server, for ssh with better usability over
mobile networks (3G/4G or spotty WiFi).

~~~
geofft
Also, you don't need root privileges to install it on the server side. You can
just install it into your home directory, and run the client with
--server=/home/you/bin/mosh-server. (It uses SSH for connection setup, and
then communicates over UDP on a high-numbered port, so it doesn't need any
privileged code.)

~~~
hosh
Anyone know if the UDP packets are encrypted?

~~~
mcpherrinm
Yes. They use AES-OCB. I've gone through the crypto myself, and while I am not
an expert, it seems properly done.

------
mraison
I have been an extremely happy Mosh user for a while now. The feature I am
missing the most is port forwarding. I looked into adding it myself at some
point, but it wasn't entirely trivial because of how Mosh bundles together
network-related concepts and higher-level stuff like optimistic typing. There
is even a small bounty on it, I think :) [https://github.com/mobile-
shell/mosh/issues/337](https://github.com/mobile-shell/mosh/issues/337)

------
Arubis
This beautiful little tool was what let me do contract work over a (frequently
>10s roundtrip with >50% packet loss) 1-2kbps mobile uplink in rural West
Africa. It's indispensable in such situations.

------
tombert
Mosh is great, but I kind of stopped using it once I discovered Tmux so I
could resume a session if the connection dropped.

It's not that Mosh does anything _wrong_ , but SSH has more features, and is
supported by basically everything ever. Consequently, I stick with old-school
SSH.

~~~
neckro23
tmux complements mosh, it doesn't quite replace it. For me, the whole point is
that you don't _have_ to "resume a session", it just happens.

On my laptop I have a mosh session open to my remote shell basically all the
time. In situations with spotty net access, it's actually a pretty reliable
"canary" that indicates whether I have any access at all.

~~~
Adaptive
This. Here's a handy zsh alias that I use:

    
    
        alias tmosh='() {mosh $* -- sh -c "tmux a || tmux"}'
    

so I can mosh into any of my ssh aliases and resume my tmux session seamlessly

------
feld
Still no proper IPv6 support. I use v6 almost exclusively to get to all my
servers.

~~~
chitta
Curious on what advantages you see vs. using IPv6 Edit: IPv4 _

~~~
spdustin
I'll chime in and say: Support for IPv6. It's ... self evident? I think we've
reached a point that it's okay to call out a network client that doesn't
support it.

~~~
chitta
I am not sure I understand. How is it self-evident? Is there a benefit over
using mosh over IPv4? Performance, stability,anything else? Does it add
anything to what mosh can do over IPv4. Is the benefit from the client end or
the server end or in-between.

~~~
DanielDent
Well one benefit is that it works. Servers which don't have a v4 address are a
thing.

------
cyphar
I never realised people used mosh for persistence. I always use tmux (with my
zshrc set up to automatically drop me into a default session) and use mosh so
that I can write full commands while operating over a lossy connection. I
would use mosh over Tor, but Tor doesn't route UDP. :(

------
colindean
I use mosh daily and love it. It's great for moving around the office and
maintaining a connection - no accidental hups, no real need to use screen or
nohup.

My one beef with it is that it effectively defeats my terminal emulator's
scroll bar. Need to scroll back the output? Nope. You have to use less or more
profusely.

~~~
Filligree
My solution to that is to run mosh on top of screen. tmux would also work.

~~~
jessaustin
Is mosh on top of screen or is screen on top of mosh? Serious question, since
I share parent's love of mosh and frustration with the lack of scrollback.

~~~
mbrock
Mosh to the server, then run screen/tmux there. You'll have to use the scroll
features of screen/tmux. Running your stuff inside of screen/tmux is useful in
any case.

~~~
chatmasta
As mentioned on the website, you can even attach to the screen directly from
the mosh command:

    
    
        mosh pello -- screen -dr

------
elsurudo
Mosh is great for low-connectivity environments. I just wish there was a
decent iOS client for the protocol...

~~~
brians
Well, we'll see.
[https://github.com/blinksh/blink](https://github.com/blinksh/blink)

~~~
carloscabanero
We are currently in a very advanced state, shooting for Beta soon. Follow us
on @blinkshell
[https://twitter.com/BlinkShell](https://twitter.com/BlinkShell) if you would
like to have early access!

------
braincode
Pity it still does not support port forwarding transparently :/

[https://www.bountysource.com/issues/4471419-ssh-port-
forward...](https://www.bountysource.com/issues/4471419-ssh-port-forwarding-
doesn-t-work)

------
codewiz
Is this really news? Mosh has been around since 2012 and there haven't been
releases in almost one year.

------
greenspot
SSHing my servers with my iPhone over LTE with Prompt w/o Mosh.

Same low latency as on desktop over WiFi, perfectly fine, light code editing
in Vim is butter smooth. And if connection breaks I just get back to my tmux
session. So, can anybody tell what I miss?

~~~
carloscabanero
Speed and responsiveness. Mosh renders on the server sending only changes, so
a Ctrl+C or a dump like dmesg is crazy fast. Prediction makes a server in a
different country behave as if you were there. Also, although you mentioned
the connection breaking, this happens in iOS a lot and ends up being a pain,
having to tap the server again and again.

With Blink, which is Mosh for iOS (I'm the developer @BlinkShell
[https://twitter.com/BlinkShell](https://twitter.com/BlinkShell)), you also
get full keyboard support, with Caps as Ctrl, Alt as Meta, or any other combo
you want to have. And a great terminal with full configuration of color
themes, fonts, etc. beyond the standard included with the app. Everything a
real terminal should have.

------
benou
This is funny, mosh saved my day a few days ago to reliably access a
workstation connected through Comcast Business from an ATT Uverse home
connection... For some reason the SSH sessions break (timeout) every 2-3min. I
tried everything, but after a random time between 2 and 4min packets for those
sessions just disappear, despite ssh sessions between other networks being
perfectly fine. Anyway mosh works like a charm now. I think it is where it
shines: seamless access over high latency and/or unreliable networks.

------
shirro
I have mostly gone back to plain ssh. mosh was fantastic for keeping a
connection running across network changes and when accessing a plain command
line it does feel a bit snappier on slow connections.

But screen or tmux give me persistence and re-establishing an ssh connection
isn't very time consuming. A terminal multiplexer has a lot of advantages that
mosh does not provide.

mosh adds another layer of terminal emulation and while the extra latency
might not be a killer the terminal emulation can be as it is opaque to some
features.

~~~
0xADADA
Why not just use mosh to establish & maintain the connection then then use
tmux/screen to manage the terminal sessions?

~~~
hxegon
Also wondering this. Why not both?

~~~
mbrock
That's what I do. My laptop moshes into a tmux. It's like I'm just always
connected to my servers; the network is abstracted away. Mosh even has a very
useful "7 seconds since connection dropped" message for when the café WiFi
lags etc.

------
hendry
I'm not sure what exactly what does it in my
[https://github.com/kaihendry/dotfiles/blob/master/.ssh/confi...](https://github.com/kaihendry/dotfiles/blob/master/.ssh/config)
but my ssh sessions are remarkably reliable across spotty 3G connections in
Malaysia in a bus.

------
fpoling
I tried to use mosh, but it turned on really bad mobile network even it was
not helpful. What surprisingly worked OK was Emacs shell plus lsyncd. With
that I type commands locally and send the whole line on Enter while lsync
transparently syncs my edits of local files to the server. Then I can live
with latencies of over a second.

------
ukd1
mosh + zerotier = win for random home servers, imho

~~~
Karunamon
For anyone else that was curious, zerotier appears to be a virtual network
tool, kind of like Hamachi but not run by a terrible company and with a much
saner pricing scale.

~~~
otterpro
It looks great, is open-source, and free for up to 10 devices. I've been using
Hamachi, but I may switch.

~~~
api
It's actually free for unlimited use if you run your own network controller,
see docs in /controller and /service on GitHub. There's now a 100 device free
limit on my.zerotier.com which is just our hosted SaaS network controller.

(I'm the founder of ZeroTier)

------
Hydraulix989
Few HN posts propel me to even slightly alter my day to day workflow. Using
Mosh instead of raw SSH is a huge win for me because much of my day is spent
remoting into a server in Singapore from the US over Verizon 4G cellular data.

------
JdeBP
Sadly, there's no indication of a proper protocol specification for the State
Synchronization Protocol having been published in the four years since the
authors suggested that SSP might be usable outwith just mosh.

------
songgao
Is there a convenient way to run mosh-server on a box behind NAT a
ProxyCommand?

~~~
chatmasta
There are some suggestions here:

[https://github.com/mobile-shell/mosh/issues/48](https://github.com/mobile-
shell/mosh/issues/48)

My solution to this was for the box behind NAT to join a VPN, and then connect
to it via its VPN address.

------
ChrisArgyle
"Why use this instead of GNU screen?"

The low latency features really set this one apart. The smart local echo (it
underlines unconfirmed predictions) make it much nicer to use over laggy
mobile networks.

~~~
Filligree
I would say they're mostly orthogonal. I use mosh _and_ screen.

~~~
ChrisArgyle
That sounds like a scenario for long-form work over a mobile network (eg. on a
laptop through a mobile hotspot).

Mosh from a laptop is a no-go for me because there's no Windows-based, full-
featured terminal emulator (saved sessions, auth agents, etc) that supports
mosh.

~~~
raesene9
have you tried Mobaxterm for this? I've not used its mosh support but like it
as a general SSH client...

~~~
ChrisArgyle
I'm embarassed to say I haven't even heard of MobaXterm. This is going on my
remote-work rig tonight.

------
aerovistae
I'm not a security researcher, but somehow I suspect the "maintaining
connection while switching networks" holds potential for a flaw.

~~~
geofft
Can you describe what you're worried about?

The connection is set up over SSH, and mosh-client generates a random AES-OCB
key and sends it to mosh-server. Packets are sent over UDP, protected using
authenticated encryption, and discarded if they fail integrity protection
(which is fine, since packets could just be dropped and perhaps corrupted
anyway because of bad network connections). Replayed packets are invalid. At
that point the client's IP address no longer matters, since it's the only
entity with the key. The server accepts valid packets from anywhere, and also
sends packets to the IP address that most recently sent it a valid packet.

This should as much protection as an SSH connection over TCP. One thing I'd
worry about is whether the server or client can be DoS'd with invalid packets.
Is there anything else that seems concerning?

~~~
aerovistae
I guess I was thinking about something involving a principle similar to
session fixation, but it was just a passing thought. Your methodologies seem
sound.

~~~
geofft
Yeah, I think in order for session fixation to work, you have to have multiple
connections trying to use the same session, and trick one of them into
reattaching to the wrong session. For HTTP + cookies, that's doable. But the
only concept of a "connection" in mosh is this key shared between client and
server and only stored in RAM, and there's exactly one session per server
process, and one client per server. A new connection is a new session (you
have to use screen or something if you want to connect to an old terminal).

There are occasional requests for the ability to write out the client key and
cryptographic state to disk, so you can reboot your machine, kill and restart
a process on Android, etc. without losing your connection. But they've been
pushing back because it breaks this straightforwardness.

------
therealmarv
Don't use it. It's a bigger security risk than e.g. SSH because there is no
audit and so well tested regarding security.

~~~
somebehemoth
I think caution is good, but I am not sure "Don't use it" is a fair assessment
for all use cases given Mosh's technology and track record over the years. Of
course SSH is more battle tested but, Mosh has a FAQ entry just for this
concern:

"In one concrete respect, the Mosh protocol is more secure than SSH's: SSH
relies on unauthenticated TCP to carry the contents of the secure stream. That
means that an attacker can end an SSH connection with a single phony "RST"
segment. By contrast, Mosh applies its security at a different layer
(authenticating every datagram), so an attacker cannot end a Mosh session
unless the attacker can continuously prevent packets from reaching the other
side. A transient attacker can cause only a transient user-visible outage;
once the attacker goes away, Mosh will resume the session."

"However, in typical usage, Mosh relies on SSH to exchange keys at the
beginning of a session, so Mosh will inherit the weaknesses of SSH—at least
insofar as they affect the brief SSH session that is used to set up a long-
running Mosh session."

Also see, "Q: What is Mosh's security track record so far?" here:
[https://mosh.mit.edu/#faq](https://mosh.mit.edu/#faq)

~~~
zobzu
Mosh requires OpenSSH to run so no matter what, using Mosh is _ALWAYS_ less
safe than OpenSSH alone since all it does is add functionality on top.

Now, I wrote a 3DES-telnet tool back in 1996 and it has zero security
vulnerability. That's 20 years. Safe as hell! Yeah exactly. Everyone uses
OpenSSH. Very few use Mosh. Invalid comparison.

~~~
justizin
> Mosh requires OpenSSH to run so no matter what, using Mosh is ALWAYS less
> safe than OpenSSH alone since all it does is add functionality on top.

Not sure I'd agree with this, since after initial session establishment, it
completely replaces the functionality of OpenSSH in a way that guards against
privilege escalation and authenticates every packet.

I do agree that there are some concerns with how 'battle tested' it is, but
not sure I believe this about "audits" since, I mean, the entire world was
using OpenSSL to build the entire internet for ages and we just found out it
was one guy scraping through the bug tracker for far too long.

The model of mosh is more secure than SSH, though its' session resumption
could potentially expose a hole if someone has your token and session keys,
they can resume your session.

------
drewr
autossh + tmux still. How are people getting around the lack of SSH agent
forwarding?

~~~
geofft
I think "Not wanting to use SSH agent forwarding" is the answer. I don't want
every single machine I use to be able to authenticate as me to anyone else. If
I actually want to be able to connect to a third machine, I'll have an SSH key
on the second machine. For instance, my phone has an SSH key to SSH/mosh to my
VPS, and my VPS has a different SSH key that can authenticate to GitHub. If I
suspect my VPS got compromised, I can kill its key on GitHub without having to
worry about whether my single, master, local key got compromised. Given that
ssh-keygen is so easy and basically every server I want to talk to supports
multiple authorized_keys, I haven't seen much use for agent forwarding.

Also, mosh was developed at MIT, where there's a good Kerberos setup for most
SSH-able machines. So if you really want forwarding, you can forward your
Kerberos ticket with the initial SSH connection. The mosh-server command on
Athena is actually a wrapper script that copies your Kerberos ticket (so it's
not destroyed when the SSH session exits) and sets up a Kerberos + AFS session
for the actual mosh-server to run inside:

[http://web.mit.edu/mosh_project/arch/amd64_deb60/bin/mosh-
se...](http://web.mit.edu/mosh_project/arch/amd64_deb60/bin/mosh-server)

There's little use for key-based authentication on Athena, let alone agent
forwarding, because if you _don 't_ forward Kerberos tickets, you don't have
access to your network home directory.

~~~
TimWolla
> I don't want every single machine I use to be able to authenticate as me to
> anyone else.

There is the `-c` option to `ssh-add` for that reason:

    
    
         -c      Indicates that added identities should be subject to confirmation
                 before being used for authentication.  Confirmation is performed
                 by ssh-askpass(1).  Successful confirmation is signaled by a zero
                 exit status from ssh-askpass(1), rather than text entered into
                 the requester.

~~~
cyphar
Security by policy is worse than security by design. Mosh doesn't have code
that implements agent forwarding, so there's no bugs in the policy code I have
to be worried about.

------
mlakkadshaw
This is amazing. I was very tired of SSH and something like this was really
needed.

------
fabrigm
Mobile shell but not mobile website...

------
mangix
no openwrt package unfortunately.

~~~
h4waii
I have packages for OpenWRT @ [https://laro.se/mosh-package-for-
openwrt/](https://laro.se/mosh-package-for-openwrt/)

Not tested on trunk, works for me on CC 15.05.

------
dingo_bat
No windows support but I wonder if this can run in Ubuntu on Windows 10.

------
astazangasta
>SSH waits for the server's reply before showing you your own typing. That can
make for a lousy user interface. Mosh is different: it gives an instant
response to typing, deleting, and line editing.

This seems asinine. If latency is an issue I want to know it, not be fooled
into thinking my input is being interpreted correctly by 'predictions'. Does
this mean when I hit 'jjjjjll' in vim, I'm going to see this underlined on-
screen in mosh in high-latency situations?

~~~
willglynn
Only if your recent keystrokes have been getting echoed, and if you haven't
done something that might disrupt echo.

> Predictions are done in epochs: when the user does something that might
> alter the echo behavior — like hit ESC or carriage return or an up- or down-
> arrow — Mosh goes back into making background predictions until a prediction
> from the new batch can be confirmed as correct.

~~~
astazangasta
Yeah, this offends me - I want my terminal to have simple, predictable
behavior, not be trying to reason about what the shell process is up to. If it
has some predictive model, I have to worry about my predictive model
(expectation of what happens when I hit a key) being in conflict.

~~~
fizzbatter
You really don't have to worry about that, imo. The predictive feature doesn't
overlap connectivity issues long enough for you to ever wonder "Am i connected
or not"?

Not to mention, it shows you in _two_ ways that you have connectivity issues.

1\. All echoing prints underlines, so you always know if it's predictive
output or not. 2\. Any prolonged connectivity issue displays a blue bar at the
top of the session, showing how long you've been disconnected for.

 __edit __: And of course, you can simply turn off predictive echo if it 's a
feature you hate. but man oh man, is it something to love, imo.

