
Mosh - luu
https://www.jefftk.com/p/mosh
======
kbumsik
The article misses the other great feature of Mosh: It never get disconnected,
regardless of the client's state (IP address change, or device sleep mode),
and you will never loose terminal sessions.

When this is not so appealing to desktop users, it is a godsend feature for
laptop/mobile users. Especially, if you are an iPad user you should try Blink
shell app [1] with Mosh. This combination turns the iPad your favorite
portable terminal machine.

[1] [https://blink.sh/](https://blink.sh/)

~~~
bpizzi
> The article misses the other great feature of Mosh: It never get
> disconnected, regardless of the client's state (IP address change, or device
> sleep mode), and you will never loose terminal sessions.

I almost switched to mosh in the past while searching for this kind of
solution to short-living ssh connections.

But I've finally never made the jump, re-launching ssh/tmux being four
keystrokes only (up+enter x2). Not justifying changing the whole paradigm.
Plus you get the additional bonus with tmux to be able to recover the same
remote terminal sessions when switching computers (leave stuff in place at
work, go home, continue on the same stuff at home).

Edit: maybe it's the time for jumping ships!

~~~
tyingq
Does the keepalive functionality in ssh help here? Like:

ssh -o ServerAliveInterval=5 -o ServerAliveCountMax=1 $HOST

~~~
kstrauser
There’s one place where it doesn’t (and can’t) help at all: when your address
is changing frequently.

Suppose I’m doing some remote debugging stuff on my way to work. I have one IP
on my home Wi-Fi. As I walk to my bus stop, it switches to LTE. As my bus
drives through the city, I periodically jump to different addresses. I grab a
coffee on my walk to the office and end up on the coffee shop’s Wi-Fi with
their address. I leave and hop back to LTE, until I get to work and connect to
its Wi-Fi.

With SSH, every one of those changes means reconnecting. With Mosh, it means
that everything pauses for an instant and then resumes as if nothing ever
happened.

------
polote
As someone who codes on a remote server the whole day, mosh is absolutely
necessary and it is fantastic

Advantages:

\- you dont see any lag when you type, it is exactly as if you were on your
local machine

\- when network disconnect, the terminal freeze and when network is up again,
the terminal becomes interactive again preserving everything in between

\- connection is preserved as long as the terminal is open, so even after
hibernation your session is preserved

Drawbacks:

\- you can't scroll , but if you use tmux then it is possible . I've tried
using Eternal terminal, as it allows to scroll but it doesn't perform well at
all on laggy connections

\- You can't detach and re attach mosh connections (same for ET)

\- I'm not sure it is possible to preserve middle-click copy/paste (at least
I've not managed to make it work)

\- time to connect is a bit longer than normal ssh

~~~
clarry
Why do you code on a remote server?

~~~
MereInterest
Pretty common for physics experiments. My computer has neither direct access
to the data being collected, nor the processing power to deal with it. Sure, I
could code locally, push to a repo, and then test remotely, but the additional
turnaround would be obnoxious. Far easier to open up a terminal and run emacs
remotely.

~~~
rkangel
I am a former Emacs user and now a VSCode user. VSCode has great 'remote SSH'
capability - running a whole session locally on a codebase that is remote.
Everything works seamlessly - find in files, code navigation etc.

~~~
grogenaut
That doesnt answer why. I have a table saw that works really well, doesn't
mean I use it all day every day.

~~~
rkangel
That's a good point that I didn't make clear, in my head it was implied from
context.

Using VSCode in this way makes you much less dependent on good SSH. When using
emacs in a terminal over SSH, your whole UI is being rendered over SSH and any
latency or packet loss is going to affect UI feedback and rendering.

If you use VSCode Remote-SSH, you UI is rendered locally, so typing and
editing work smoothly, and you don't really notice a bit of network latency on
a request to "find in files" for instance.

Running your emacs locally and then using Tramp to edit remote files (as
suggested elsewhere) gives you some of that benefit but is a much more limited
development experience, and (in my experience) flakier.

~~~
grogenaut
why do you work remotely at all instead of just doing it all on your pc?

~~~
rkangel
There are a number of situations where you don't want to compile or run code
on the same machine that you develop on. Use of containers or VMs can mitigate
a lot of them (differing environment or platform), but not all. I have 3
different causes at different times:

Developing a python framework for running system tests on hardware. This can
only be run on the machine that is in the lab connected to the hardware. For
various reasons related to the network latency of being at home, the easiest
way to iterate on that is to checkout and develop on the machine itself.

Developing on Linux, from home. My work laptop is a (small) Windows machine.
Normally it doesn't get heavy use - some presentations and email reading when
I travel. Now I'm WfH it's my primary machine. By SSHing to my Linux desktop
at work (for terminal and for VSCode), I get the development experience of
Linux on my Windows machine (there are some other benefits to do with that
machine being on the right network and close to the stuff it needs to talk to
a lot).

Developing FPGA code. This requires a hugely powerful machine to compile on if
you want a reasonable compile speed. The Hardware group have a few specialised
machines for this that are shared, so that we can have laptops and get the
benefit (also means you can leave a synthesis going overnight/over the weekend
easily).

------
donatj
Eternal Terminal ‘et’ is like Mosh but functionally better. Doesn’t break
scrollback. Transparent to tmux control mode.

I switched from Mosh to et across 12ish servers around 6 months ago and am way
happier for it.

[https://eternalterminal.dev/](https://eternalterminal.dev/)

Previous conversation:

[https://news.ycombinator.com/item?id=21640200](https://news.ycombinator.com/item?id=21640200)

~~~
starfallg
Looking at Eternal Terminal, it doesn't have the same "local echo" feature
that minimises the effect of latency in a cli environment.

Thats the trade-off. The "local echo" feature is what I use mosh for as I deal
with system 8 to 10 timezones away. Doing this breaks scrollback.

I guess when mosh was first made, this was a problem with ssh shell sessions
over EDGE or 3G as well, although network latency is less of a concern these
days on 4G LTE or 5G mobile.

~~~
sam_lowry_
What about using GNU screen inside a mosh connection like that:

    
    
        mosh server -- screen -xRR -D
    

You then can use the scrollback buffer provided by screen with Ctrl-a, ESC and
then the usual Up/Down and PgUp/PgDown buttons.

~~~
starfallg
Yeah, I do something similar with tmux. You can even get mouse scrollback to
work properly by setting the option in the conf file.

Here some medium article about this -

[https://medium.com/@toja/tip-using-mosh-with-
scrollback-257a...](https://medium.com/@toja/tip-using-mosh-with-
scrollback-257a54a848b3)

~~~
londons_explore
For some reason scrollback mouse integration works well till one disconnects
and reconnects, and then suddenly it's broken.

------
nrmn
Mosh is great, but it does not support port forwarding. For some people,
including myself, this is a deal breaker. It has been an open issue/feature
request since 2012[1] and even has a ~600 USD bounty on it[2].

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

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

~~~
TTPrograms
I would also love this feature, but I understand the argument that it's major
feature-creep for this project - as I understand, with mosh as implemented it
would be difficult to integrate. IIRC they would have to roll some kind of TCP
over UDP? I'm not sure, it's been a while since I looked at it. I'm willing to
accept a good tool missing features over a poorly maintained tool that at some
point had all the features I care about.

And realistically $600 is a pittance compared to the long-term cost of
maintaining a feature that has the potential to dramatically increase the size
of the code base.

------
alexhutcheson
If you're an Emacs user (like the author apparently is), I would recommend
trying out TRAMP:
[https://www.gnu.org/software/tramp/#Overview](https://www.gnu.org/software/tramp/#Overview)

Emacs will transparently handle SSH connections and let you edit remote files
as if they are local. Just as importantly, if you run commands like M-x
compile or M-! (aka M-x shell-command) while you're looking at a remote file,
Emacs will "do the right thing" and run the process on the remote machine,
rather than on your local machine.

This gives you the benefits that the author mentions about mosh - characters
will appear as you type without waiting on a server round-trip. Additionally,
you also won't have to wait for a server round-trip to see your cursor jump to
the minibuffer, which the author mentions as a pain point.

If you need to run things at the command-line, you can do so in a "shell"
buffer via M-x shell (or M-x term if you need to run something curses-like).

The major downsides:

\- I/O operations (including opening and saving files) can be much slower than
if you were running Emacs in a terminal, because the bytes need to be sent
over SSH.

\- It's not always easy to keep track of which buffers are "remote" and which
are "local", so sometimes you'll run a command and it will run a process on a
different machine than you expected.

------
jwr
Mosh is fantastic. And as an old-timer I am rather amused how some good ideas
from a while back make its way into current hot tech again. After all, the IBM
3270 terminal was specifically designed to not transmit one character at a
time. Thanks to this, a 1970s-era IBM 3033 mainframe fitted with only 16 MB of
main memory was able to support up to 17,500 3270 terminals. (see
[https://en.wikipedia.org/wiki/IBM_3270](https://en.wikipedia.org/wiki/IBM_3270))

~~~
JdeBP
Terminals in mosh are still fundamentally character mode, though. That's a
fairly inescapable part of the POSIX general terminal interface. A better
analogue for something where there's a block-mode send of form data is,
ironically, a WWW browser and WWW pages with forms.

------
JdeBP
The problem with mosh from my perspective has always been this sentence in the
blurb:

> _This is accomplished using a new protocol called the State Synchronization
> Protocol, for which Mosh is the first application._

This protocol has never been documented, making it "only" rather than "first",
and once again putting the world in the position of one particular
implementation's foibles being the only "specification".

------
prussian
Last time I tried using things like this, it just ended becoming a VT layering
monstrosity where you had like 3-4 terminal emulators all interfering with how
you expect your keyboard and mouse interactions work. It's also why I gave up
trying to use tmux.

It's easier for me to just pick one terminal emulator I like and spawn
multiple windows of it, ssh about and deal with the woes of TCP than put up
with VT layering like mosh requires.

------
fooblat
I am also a fan of mosh.

I really like that I can close my laptop and put it into standby, take it
somewhere else with a different wifi network and just open it and get right
back to work. From a user perspective it appears as if mosh was never
disconnected.

~~~
amingilani
You can use tmux for persistence like that, and I use mosh in combination with
tmux just because it's so nice to get multiple windows and panes.

~~~
baq
tmux solves a different problem - your session persists across disconnects,
but you still have to reconnect and attach to the session manually.

mosh is for low bandwidth high latency but as a side effect it makes the
reconnect step transparent most of the time.

(for the record i also use both mosh and tmux)

------
steventhedev
I've used mosh extensively over the last few years with very few issues. It
composes well with tmux. The only barrier to me really advocating it is the
lack of support for bastion hosts and working around firewalls.

~~~
AnthonBerg
I’ve used ZeroTier to solve most of that sort of network issues.

------
globular-toast
I started using mosh a few weeks ago when I was working over ssh more. Even
for working over LAN it was attractive because I'm really sensitive to typing
latency. Don't be like the author and put off trying it, it's dead easy to
install and try. No setup and no commitment to keep using it.

However, I quickly ran into a problem which is that it breaks a scrollback.
This is the one big problem with mosh and will probably never be fixed. I
tried to find other ways but eventually decided I couldn't live with it.
Shame.

~~~
mprovost
Terminal emulators (xterm, iterm2 etc) are emulating something like a VT220
which were called "glass terminals" to differentiate them from earlier
terminals which were keyboards attached to printers. So there's still this
underlying concept of an endless spool of paper, and that's what you see when
you scroll back. A scroll is literally a long piece of paper.

Anyway that means if you cat some long file and then hit control-c, whatever
was output before you aborted still has to be sent to your terminal emulator
so it can write it to this paper (save it to the scrollback buffer). This
sucks on a slow connection. mosh is running the emulator on the remote side of
the connection and the client that you're interacting with locally just syncs
periodically to whatever is currently being shown on the screen. So it doesn't
have to send all of the output, which as you've seen, does break local
scrollback. But it's a great solution for the problem it was designed to solve
which is making terminals work over slow and/or unreliable network
connections.

If you pair it with gnu screen or tmux, then they become the terminal emulator
and maintain the scrollback buffer, so you can still scroll back and see all
of the paper. You just can't do it with the slider on your local window
because your local emulator doesn't have access to the full contents of the
buffer. I turn off scrollbars in rxvt and just rely on screen to maintain the
buffer and use command keys to go back when I need to.

~~~
Dylan16807
Mosh could easily load the skipped-over lines in the background. It's not
incompatible with the design. It just requires a developer to put in the
effort.

~~~
mprovost
Can it though? How can a program manipulate the scrollback buffer of the
terminal that it's running in? Other than by printing more output. But once
it's updated the current line, it can't go back and add more lines - those
lines have already been printed on the scroll.

~~~
Dylan16807
Even if it had no way to communicate the lines to the local terminal, it could
still load them and handle the scrollback itself, locally. I think that's what
the eventual plan is, too.

But it wouldn't be exceptionally difficult to figure out some way to stuff
lines into the scroll buffer. Especially if you got a mosh-aware terminal.

------
fluffything
You need to install a server in the server for this to work. That is, if you
are using SSH to log in to server farms as a "user" (as opposed to a server
farm admin), then you cannot just "use mosh".

~~~
maddyboo
When I first found out about mosh, I imagined it would work seamlessly even
with servers that don’t have the mosh server installed by auto-installing
itself.

If mosh could do this, I would `alias ssh=mosh` and use it all the time.

Otherwise I need to remember which servers have mosh installed, and for those
that don’t I need to ssh in, apt-get mosh, disconnect, and reconnect with
mosh.

I’d imagine it could either just scp a binary over to the target system (in
the case of insufficient privileges) or use the system package manager to
install itself.

~~~
fluffything
That's supposing that you can run mosh in the background while you are not
logged in.

------
trevyn
Mosh’s non-support of scrollback was always a deal-breaker for me.

iTerm2’s tmux integration is pretty nice, though.

Apparently there is iTerm2+tmux+mosh dark magic if one is into that kind of
thing: [https://www.gaeblogx.com/2017/10/09/Remote-Shell-Session-
Set...](https://www.gaeblogx.com/2017/10/09/Remote-Shell-Session-Setup/)

~~~
tasuki
Well, tmux supports scrollback with `prefix [`, then `j` and `k` and `C^u` and
`C^d` to move up and down, Enter to select and copy text. Not good enough?

------
rudiv
Mosh has been a godsend while working from home the last few weeks. Especially
because despite my company and all its employees being in India, we host all
our servers in the US to 'keep up appearances'.

------
opwieurposiu
VS code remote works pretty well for this. Lag-free local editing of files,
terminal is always there when you need it.

------
turdnagel
If you use a combo of iTerm on Mac + Mosh + tmux, I highly recommend
rebuilding mosh on client/server from this PR[1] which adds better support for
copy & paste. Also, if you use mosh without tmux, you're missing out -- learn
tmux.

[1] [https://github.com/mobile-
shell/mosh/pull/1054](https://github.com/mobile-shell/mosh/pull/1054)

~~~
robohoe
Mosh + tmux on an iPad Pro rocks. I can now select and copy/paste using
finters or Apple Pencil.

~~~
turdnagel
Are you using Blink? When you copy/paste, does that only work within the SSH
session or can you copy to the system pasteboard?

------
colbertw08
Is Mosh being maintained anymore? I remember giving it an install maybe a year
ago and remembering it didn't have any updates in quite some time.

~~~
doubleunplussed
It looks like there has been active development, but they haven't cut a new
release.

Reminds me of pyqtgraph, which gets commits most days last time I checked yet
hasn't released since 2016.

------
FPGAhacker
I use mosh in tandem with tmux.

About say 10% of my reconnects would fail with mosh, and the session would be
orphaned. But combining with tmux, even if I lost the mosh session I could
make a new one and reattach to tmux.

My use case was iPad/iPhone remote working. (Usually while visiting in-laws or
on a plane) Very intermittent connectivity.

I used the open source blink terminal for iOS (which I bought because it’s
great). It can use mosh.

------
neurostimulant
I've been using Mosh for years and it's one of the first things I install on
all servers I setup. I also install the client on my android phone via Termux
and it's absolutely great on laggy and unreliable mobile connection. My only
gripes are the lack of scrolling buffer (need to remember to use tmux) and the
lack of support on iTerm's fancy tmux integration. Other than that it's an
absolutely fantastic tool!

------
TickleSteve
Used mosh to access remote linux machines over a sub-GHz IPv6 mesh.

Since the mesh is UDP only, this provides a relatively normal shell experience
for this type of situation.

Works well.

------
opk
I mostly use mosh from my mobile for connections to home. It handles session
persistence nicely even while on the move.

It'd be great if I could use it now while working from home because my ssh
sessions keep dying. Unfortunately the work firewall won't allow this. So tmux
to preserve the sessions is the best I can do.

------
zxcvbn4038
Mosh is awesome! The biggest issue I ran into was it being UDP based - lots of
places lock down UDP even over VPNs - and if your client dies there is no way
to reconnect. However as long as the client is active it is pretty
bulletproof. Hopefully http/3 will cause people to loosen up UDP rules a bit.

------
blunte
tmux+mosh is a winning combination for working on remote servers.

If you spend any time using a terminal to remotely manage servers, it's worth
using at least tmux (and mosh because it provides a better experience with
imperfect connections).

------
okhan
I used to live in SE Asia and was regularly SSH-ing into servers running in
the US. The latency was awful. Mosh made everything far more pleasant. The
only downside is that you have to install extra software server-side.

------
anthony_barker
I used it for a while - but was worried about security. Is it as hardened as
ssh?

~~~
tialaramex
Mosh doesn't have to do the hard part.

The difficulty is key agreement and authentication, but both those happen in
SSH itself. So by the time Mosh is invoked you're definitely an authorised
user and you and the server share a secret, so Mosh is just moving encrypted
packets.

It uses authenticated encryption, and I don't know much about the specific
mode it apparently uses, OCB3, but in general there's just not that much to go
wrong over and above all the work still happening in SSH.

------
daveed
I'll just add that mosh is excellent. I started using it on a trip to the
other side of the world. The ssh latency was terrible, and mosh saved the day.

------
nightbrawler
Mosh is awesome! I use it all the time to connect to servers over a slow and
high latency satellite link. Highly recommend it for high latency connections.

------
larrywright
Mosh + Blink (iPadOS) is a great combination.

------
typon
Does anyone know how to get mosh to play well with emojis or Unicode strings?

------
Floegipoky
Big fan of mosh, I've used mosh + tmux + neovim for years

