Entering the mosh pit

By Jonathan Corbet
May 16, 2017

For some years now, your editor has heard glowing reviews of Mosh — the "mobile shell" — as a replacement for SSH. The Mosh developers make a number of claims about its reconnection ability, performance, and security; at least some of those are relatively easily testable. After a bit of moshing, a few clear conclusions have come to the fore.

Mosh has been around since 2011 or so; the 1.3 release came out in March. It appears to be under active development and to be reasonably widely used. Mosh runs on just about any type of operating system one can imagine, and binary packages are readily available. Setup is nearly zero-effort, with one small exception noted below. In short, if Mosh meets your needs, there is little excuse for not using it.

Calling Mosh an "SSH replacement" (as the project's web site does) is not quite correct, though, for a couple of reasons. The first of those is that you still need SSH around to set up a Mosh connection. Mosh doesn't bother with little details like listening for new connections or authentication; it relies on SSH for those. Typing "mosh remote-host" will set up a connection but, behind the scenes, SSH will be used to make the initial connection to the remote host. Thus, one still has to go through the usual authentication dance — entering passwords, distributing public keys, etc. — before using Mosh. The good news being, of course, that one's existing SSH authentication setup will work unchanged with Mosh.

Once an SSH connection is established, though, the only thing Mosh uses it for is to start a mosh-server process at the remote end and to exchange keys with that process. Once that's going, the SSH link is closed and discarded; the client and server talk directly using a UDP-based protocol thereafter. That is one place where one can encounter minor setup difficulties. Installing Mosh itself can be an entirely unprivileged operation, but that may not be true of the task of ensuring that its UDP packets make it through any firewalls between the local and remote systems.

Each UDP packet is separately encrypted (using the OpenSSL AES implementation) before sending and authenticated on receipt; if all works well, that should make it impossible for an attacker to eavesdrop on the connection or inject packets into it. In theory, encryption at this level is more robust than the TCP-based encryption used by SSH; only the latter is subject to TCP reset attacks, for example. The protocol is designed with its own flow control that, among other things, is designed to avoid filling up network buffers along the path between the systems. Any longtime SSH user knows the annoyance that comes from interrupting a verbose command with ^C and having to sit through a long wait while all of the already-transmitted output makes its way across the link. Mosh claims to avoid that behavior — and your editor's tests suggest that the claim is warranted.

The actual protocol is called "state synchronization protocol" (SSP); it is built on the idea that the endpoints are maintaining copies of the same objects and communicating changes to the state of those objects. One object, maintained primarily on the client side, represents the keystrokes that the user has typed. The server end, instead, owns an object describing the state of the screen. The two ends exchange packets whenever the state of one of those objects changes, allowing the other end to update its idea of their state.

"TELNET", the project's web site proclaims, "had some good things going for it". One of those was local echo. Users typing over an SSH connection will not see their keystrokes until they are echoed by the remote end; on a flaky connection, that can make typing painful. Mosh, instead, has some tricky-seeming code in the client that can anticipate the changes in the state of the screen object and echo keystrokes ahead of the remote end. "Tricky" because the client has to figure out when not to echo — when a screen-mode application is running, say, or when a password is being typed. Your editor did not have access to a network slow enough to exercise this feature; it will be interesting to give it a try the next time it's necessary to try to get some work done over an airplane WiFi network.

Since UDP is connectionless, packets can come from anywhere. Mosh uses this feature to implement its reconnection mechanism. The Mosh "connection" exists for as long as the mosh-server process is running; the client, meanwhile, can disappear and reappear at will. So, for example, one's laptop can switch from one wireless network to another, getting a new IP address in the process. The Mosh server will notice that packets are now coming from a different address; if those packets authenticate properly, the server will start sending its own packets to that address. So the Mosh connection will persist, uninterrupted, possibly without the user even noticing.

Your editor ran some tests of this feature, switching the laptop between a local network and tethering via a phone handset. The Mosh client puts up a notification when connectivity goes away (it seems to notice before the laptop itself figures out that its WiFi access point has vanished); once the network returns, the Mosh connection is back up and running. If an output-producing command is running while the change happens, none of the output will be lost (modulo one detail).

Mosh tries to provide the best terminal experience it can. It seems that quite a bit of effort has, for example, gone into proper handling of UTF-8 character sequences and escape sequences. But there is an implication of the state synchronization protocol that affects the terminal experience in a significant way. Since Mosh models the entire state of the screen, it wants to be in control of that state, with the result that it overrides and changes the behavior of the terminal emulator that one might be running Mosh within.

This aspect of Mosh is perhaps most visible when it comes to scrolling back through the terminal output. The Mosh model of the screen encompasses the screen itself, but not anything that has scrolled off the top. When using gnome-terminal and SSH, for example, the mouse wheel can be used to move back through the output; that does not work with Mosh. Instead, the wheel moves through the command history. The gnome-terminal scrollbar becomes inoperable while Mosh is running as well. The problem was first reported in 2011 — it is issue #2 — but it remains unfixed. The workaround is to use a utility like tmux or screen.

Mosh's focus on the terminal experience also ties into the other reason why it is not truly an SSH replacement. It can be used to run an interactive shell on a remote system. It can also be used to run a command non-interactively, but only if the user doesn't care about seeing the result after Mosh exits and resets the screen. But it cannot be used for tasks like port forwarding. Those of us who use SSH as a sort of poor hacker's VPN will need to continue doing so.

Mosh, thus, is aimed at a fairly specific use case: users who engage in interactive terminal sessions with remote hosts over variable and possibly flaky network connections. That is a description that, for example, fits many attendees of Linux-oriented conferences. But, if the truth be told, Mosh is not a tool that will make a day-to-day difference in your editor's life. In a world where many resources are local and the rest are accessed via higher-level protocols, many of us probably do not need a highly optimized, extra-robust remote terminal emulator. For those situations where it is useful, though, it would seem that, as your editor has heard for years, there is nothing better.

to post comments

Entering the mosh pit

Posted May 17, 2017 1:29 UTC (Wed) by ast (subscriber, #100277) [Link]

Here is the hack to enable scrolling in mosh:
https://github.com/4ast/mosh/commit/b642df68efe1b437ceeb6...
It's a hack, but it mostly works despite some issues. Unfortunately no expectations that
it will ever be merged upstream, since it removes most 'cool' features of mosh like full
terminal emulation that allows mosh to send only visible bits between client and server.
This hack encrypts and sends every byte as-is from server to client and back, just like ssh does.

Entering the mosh pit

Posted May 17, 2017 3:49 UTC (Wed) by NightMonkey (subscriber, #23051) [Link]

Hmm. Yah, I'm a little ill from the hyperbole. Until Mosh can do what sshuttle can do... well, it's not an "SSH Replacement". I just don't have the problems that Mosh addresses, so I'll just keep going with SSH and tmux and (recently) sakura as my terminal.

https://github.com/apenwarr/sshuttle

Thank you for the review. Fine as always. :)

Lack of forwarding support (SSH agent; hopping between hosts)

Posted May 17, 2017 4:23 UTC (Wed) by grahame (guest, #5823) [Link]

I make a lot of use of SSH's ProxyCommand functionality to hop through gateway hosts into different environments that aren't directly internet accessible. Getting that to work with MOSH seems hard - the mosh server runs on the endpoint host, which in my use case doesn't have an internet accessible IP. So the whole setup process fails.

Additionally, the lack of support for forwarding an SSH agent is a pain - I sometimes need to forward my agent to bounce through between hosts, or to access private git repos on a remote host.

These days I just try to minimise the amount of work I actually do on remote hosts, and for the work I do need to do SSH is adequate.

Discussion of the SSH forwarding / gateway host seems to be happening in this issue:

https://github.com/mobile-shell/mosh/issues/120

Entering the mosh pit

Posted May 17, 2017 4:44 UTC (Wed) by hifi (guest, #109741) [Link]

I use Mosh exclusively for one persistent SSH connection to my remotely running irssi. My desktop goes to sleep multiple times per day and having my irssi session continue immediately when the network connection is back up is very handy.

Also, my primary connection is mobile broadband and it's fairly easy to get huge amount of input lag with it if you do something else simultaneously and Mosh really helps to cope with that. No lost keystrokes when the round-trip time is 900ms.

For improved typing experience on said irssi session I have the client running with --predict=experimental which removes the requirement to check the server if echo is on so typing will always start immediately regardless of connection state. This, of course, does not work with anything that doesn't use line input (like vi command mode) as it would echo all your typed characters first on the screen and then the server would correct it when the application does something else. It would also not work well for password input as any typed characters would be briefly visible on the screen.

+1 for Mosh but it's definitely not a replacement for SSH but more like an extension.

Instant update of typed characters

Posted May 17, 2017 6:12 UTC (Wed) by epa (subscriber, #39769) [Link] (3 responses)

Mosh's heuristic for displaying characters instantly sounds useful. But wouldn't it be more cleanly addressed by using the old-school "cooked mode" for terminal input? Where the terminal lets you type the whole line locally and sends a line at a time. The problem would be integrating that with tab-completion and other interactive features we nowadays expect from our shell.

Instant update of typed characters

Posted May 17, 2017 9:00 UTC (Wed) by smurf (subscriber, #17840) [Link]

Exacctly. Tab expansion doesn't work, it isn't configurable or extensible (word boundaries are language-specific, both human- and computer-), not to mention no command history.

Also, all this terminal and line discipline code inside the kernel is rather old and there's no longer much of a reason why it should be in the kernel in the first place.

Instant update of typed characters

Posted May 17, 2017 20:00 UTC (Wed) by cgull (guest, #115681) [Link] (1 responses)

And in particular, there are certain things that you do *not* want echoed even tentatively, such as the password you type at a password prompt. The two clever things about Mosh's predictive echo are that it won't echo until it sees some from the remote system, and that it cleans up errors in the echo once the real echo is received from the remote system.

Instant update of typed characters

Posted May 18, 2017 6:04 UTC (Thu) by epa (subscriber, #39769) [Link]

But the password prompt drops into raw mode. I mean that the shell would switch to cooked mode for ordinary command input. If only cooked mode were a little bit smarter so it had provision for flipping back and forth between cooked and raw in the same line of input, as when Tab is pressed...

None of this would help much if you are running some full-screen text program inside the mosh session (and perhaps your command prompt inside that, as Emacs's shell-mode). I guess the heuristic used by mosh is the best we can do -- and the older line disciplines, while cleaner in principle, are just too inflexible. It's like remote graphical sessions where (with the demise of X11) we no longer send primitives to draw individual lines and rectangles, or render a device-independent character glyph, but instead send the individual pixels with a moderately intelligent compression layer. A good example of "worse is better".

Entering the mosh pit

Posted May 17, 2017 6:51 UTC (Wed) by ekacnet (guest, #55471) [Link] (1 responses)

There is a new kid in this block Eternal Terminal (ET) https://mistertea.github.io/EternalTCP/
Not sure how it compares to mosh.

Entering the mosh pit

Posted May 17, 2017 15:32 UTC (Wed) by MatejLach (guest, #84942) [Link]

Just tried it and unlike mosh, it does support scrolling. On the other hand, typing is much more laggy than with 'mosh --predict=experimental', so I'd say it's a supplement to mosh, rather than a complete replacement, at least for now.

Entering the mosh pit

Posted May 17, 2017 7:46 UTC (Wed) by shx (subscriber, #105604) [Link]

I tried mosh over a satellite link with 900-1200ms of latency. It's still painful but at least it's useable compared to SSH. I would also not recommend it as a general SSH replacement, but for high latency links (satellite) and unreliable connections (like in a train or airplane) it's the best tool I currently know.

Entering the mosh pit

Posted May 17, 2017 8:28 UTC (Wed) by xyzzy (guest, #1984) [Link]

When you're a couple of hundred milliseconds from the USA, and even more from Europe, Mosh's latency-hiding local echo makes server administration feel much smoother. Try spinning up a cheap, faraway VPS with Vultr.com and see what the difference between SSH and Mosh is like.

Likewise, being able to have a bunch of terminal sessions open that remain persistent when you shut your laptop's lid, commute, and open it again, is brilliant. It means your remote terminal sessions are exactly where you were before -- and they work! The experience with SSH is going back to a terminal window with an SSH session that looks like it's still operative until you start typing, and it dies.

Entering the mosh pit

Posted May 17, 2017 9:28 UTC (Wed) by paulj (subscriber, #341) [Link] (12 responses)

“Each UDP packet is separately encrypted (using the OpenSSL AES implementation)”

That caught my eye.

Does that mean Mosh has hand-rolled its application crypto protocol (above the low-level encryption algorithm used)? Is it using some unchained, per-packet encryption? That could imply weaknesses, possibly significant.

That makes me want to read more about Mosh's security before trusting it...

Entering the mosh pit

Posted May 17, 2017 10:15 UTC (Wed) by flussence (guest, #85566) [Link] (2 responses)

It uses AES-OCB (https://tools.ietf.org/html/rfc7253) — this is the same encryption scheme Mumble uses for voice data, so I guess there's something to it that makes it good for interactive use.

Entering the mosh pit

Posted May 17, 2017 10:38 UTC (Wed) by HenrikH (subscriber, #31152) [Link]

The nonce in OCB mode needs not be secret and can thus be a counter which makes it work well for situations like this. So you simply use the packet-number as the nonce and thus it's no problem if packets are missing (the encryption is not chained) or are received out of order.

Entering the mosh pit

Posted May 17, 2017 20:29 UTC (Wed) by cgull (guest, #115681) [Link]

Mosh's crypto is pretty simple, it's just a textbook application of using OCB with a prearranged secret for sending messages back and forth (the secret is arranged over the initial SSH connection, so of course you must trust that).

There's nothing particularly special about OCB for interactive use, it has no particular advantage for that over any other AE mode.

Entering the mosh pit

Posted May 17, 2017 12:41 UTC (Wed) by epa (subscriber, #39769) [Link] (8 responses)

I was thinking you could generate a megabyte of random data, send it across the ssh link, and use it as a one-time pad. That would cut latency further since you just need to XOR the incoming bytes rather than run AES decryption. As long as any packets don't get lost, I suppose. When the one-time pad is about to run out you can make a new one and again send it via the open ssh connection.

Or am I worrying too much about the latency imposed by AES?

Entering the mosh pit

Posted May 17, 2017 12:53 UTC (Wed) by farnz (subscriber, #17727) [Link] (4 responses)

Bear in mind that modern CPUs have dedicated AES assist instructions - this set of slides suggests that you end up using around 2 clock cycles per byte with an optimal implementation, and a latency on the order of 10 clock cycles from first byte in to first byte out. Given the clock speeds on modern CPUs, I suspect that you're going to hit network limits before AES is too slow.

Entering the mosh pit

Posted May 17, 2017 15:59 UTC (Wed) by epa (subscriber, #39769) [Link] (3 responses)

Thanks. I am still living in the past, when I had to patch the openssh source code to add a 'no encryption' mode to get decent latency on my collection of ancient i386 machines...

Ten clock cycles (or even ten thousand) is plenty fast enough to display a keystroke instantly.

Entering the mosh pit

Posted May 17, 2017 16:07 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

Yeah - AES acceleration instructions mean that your latency is dominated by network latency, not compute latency, by a significant margin - a realistic implementation of AES decrypt using the acceleration instructions is going to add under a microsecond of latency, which is less than the minimum Ethernet latency you're going to see on a real 10G network.

Entering the mosh pit

Posted May 18, 2017 7:08 UTC (Thu) by luto (subscriber, #39314) [Link]

Even without AES acceleration, you're not going to notice the latency -- AES is quite fast even in software, and mosh is meant to be used by humans.

Entering the mosh pit

Posted May 18, 2017 15:30 UTC (Thu) by flussence (guest, #85566) [Link]

ChaCha20 is a bit faster than AES (4-15cpb), which is one of the reasons it's the default in OpenSSH now.

(Not fast enough to make me give up using HPN-SSH, mind you...)

Entering the mosh pit

Posted May 17, 2017 15:25 UTC (Wed) by itvirta (guest, #49997) [Link] (1 responses)

The possibility of packets getting lost is quite severe when the connection is done over UDP, _and_ when one of
the useful use-cases is that of roaming or sleeping laptop clients. Besides, what would you do when your megabyte runs out?
As for the latency of AES, that's what your SSH connections are encrypted with, too.

Entering the mosh pit

Posted May 17, 2017 15:55 UTC (Wed) by epa (subscriber, #39769) [Link]

Yes, the ssh connection is encrypted and has high latency. The one megabyte block of random data can be sent as a one-off on connection, and topped up in the 'background' when the terminal session is idle for a second or two. It doesn't matter that there is high latency for sending that data since it isn't needed immediately. This scheme would be inappropriate for a connection with lots of data going over it all the time, but it could work pretty well if what you are sending is tiny updates (individual keystrokes, or at most a screenful of text), which come at fairly infrequent intervals (human typing is slow), but they need to be processed with as little latency as possible when they do happen.

I suppose that if the UDP packets have a sequence number and a fixed length, you can still use the one-time pad to encrypt them (if a packet is lost, then that bit of the one-time pad is wasted too).

Others have pointed out how on modern CPUs AES is fast, so it may be a non-issue. (Although I would point out there is a difference between the average speed for decrypting a large block of data, and the speed if you are doing a single byte at a time. I doubt that decrypting just one byte on its own can be done in two clock cycles. But even if it takes a hundred thousand cycles that's still fast enough, on a modern CPU, to display the keystroke 'instantly' to a human user.)

Entering the mosh pit

Posted May 17, 2017 20:07 UTC (Wed) by cgull (guest, #115681) [Link]

You're worrying too much. Mosh's bandwidth needs are quite small, and even on a system without AES hardware, the crypto computation cost is pretty much in the noise compared to the virtual terminal emulation and state keeping. It's been a while since I benchmarked this, but I recall crypto being at most 2% of CPU usage in a profile.

Entering the mosh pit

Posted May 17, 2017 9:37 UTC (Wed) by obonaventure (guest, #108715) [Link] (10 responses)

Instead of changing the application to support mobility, another solution is to change the underlying transport protocol. When ssh is used over Multipath TCP, all the mobility features provided by mosh come for free thanks to the underlying Multipath TCP. All the features of ssh, including port forwarding, continue to work. If TCP reset attacks are a concern, Multipath TCP can cope with such attacks by recreating subflows and it would be possible to use ssh implementations to better interact with Multipath TCP. Patches are available for various versions of the Linux kernel from http://www.multipath-tcp.org

Entering the mosh pit

Posted May 17, 2017 12:30 UTC (Wed) by pabs (subscriber, #43278) [Link]

Have the patches been submitted for mainline Linux?

Entering the mosh pit

Posted May 17, 2017 12:42 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

Downside: the middleboxes presumably have to support MPTCP or at least not block it. The time before a random satellite Internet provider supports *that* is probably measured in the centuries :(

MPTCP

Posted May 17, 2017 13:03 UTC (Wed) by corbet (editor, #1) [Link]

MPTCP is rather carefully designed to sneak through middleboxes; that's where a lot of the complexity in the protocol comes from. Some details are in my 2013 article on the subject.

Unfortunately, the work to upstream this code seems to have stalled completely.

Entering the mosh pit

Posted May 20, 2017 7:54 UTC (Sat) by obonaventure (guest, #108715) [Link] (1 responses)

Apple has been using MPTCP for Siri on all iPhones, iPads and now MacOS devices without observing severe problems caused by middleboxes deployed on the Internet. MPTCP works well through those middleboxes.

Entering the mosh pit

Posted May 20, 2017 11:41 UTC (Sat) by nix (subscriber, #2304) [Link]

Oh, excellent! Now all we have to do is get it merged :)

Entering the mosh pit

Posted May 17, 2017 17:24 UTC (Wed) by shemminger (subscriber, #5739) [Link] (4 responses)

Using UDP and reinventing own flow control and retransmit is foolish.
"Those who do not understand TCP are doomed to reinvent it"

Entering the mosh pit

Posted May 17, 2017 21:24 UTC (Wed) by itvirta (guest, #49997) [Link]

> Using UDP and reinventing own flow control and retransmit is foolish.

Perhaps, but it does have the advantage that it works without any kernel support.
Which helps a lot in getting your software to work across different operating systems.

In mosh's case, it also has the upside that it knows more about the underlying data
than a general purpose stream transmission algorithm does. Namely, changes to the
screen can be mercilessly discarded when the client isn't looking.

Entering the mosh pit

Posted May 17, 2017 22:42 UTC (Wed) by renox (guest, #23785) [Link]

Your comment lacks substance, I could also say those who understand TCP try to replace it!
For example I hate having to type sleep 30 to prevent me from trying "too soon" to restart an application which then fail because the TCP connection fail.

Entering the mosh pit

Posted May 17, 2017 23:02 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> Using UDP and reinventing own flow control and retransmit is foolish.
Nope. Mosh is essentially a media application - it transmits the live video of the remote terminal.

So it's much better to transmit the whole screen state anew if an update packet is lost rather than wait for TCP retries to deliver all the intermediary packets.

For the same reason voice/video conferences use UDP - it's better to simply drop a small update to compensate for it later rather than cause the whole screen to stutter while the stream recovers.

>"Those who do not understand TCP are doomed to reinvent it"
Those who think that TCP is The Answer are foolish in the extreme.

Entering the mosh pit

Posted May 20, 2017 7:28 UTC (Sat) by niner (guest, #26151) [Link]

No idea if mosh does it, but since it transfers very little data and may be used over networks with large packet loss, it could even opportunistically retransmit. Just send each package twice or even more to increase the chance that at least one of them arrives.

Entering the mosh pit

Posted May 17, 2017 10:59 UTC (Wed) by 1ace (subscriber, #103978) [Link]

> Your editor did not have access to a network slow enough to exercise this feature

You can use Linux's `tc` (traffic control) to simulate any network condition, including latency, bandwidth, packet loss, etc.
See https://wiki.archlinux.org/index.php/Advanced_traffic_con... and http://lartc.org/lartc.html#LARTC.QDISC ("9.2.2.2. Sample configuration" in particular) for instructions.

Entering the mosh pit

Posted May 17, 2017 12:47 UTC (Wed) by smadu2 (guest, #54943) [Link]

I am eternally grateful for mosh, with out which I may not have had an opportunity to work remotely. Its not always possible/practical for a company to ship the infrastructure necessary to setup a dev environment to be able to work remotely. In such cases maintaining sane ssh sessions to your remote dev environment is God send. I have been working with mosh with latencies 300ms (on a good day) to ~1 sec with ~40% packet losses on worst days.

Entering the mosh pit

Posted May 17, 2017 13:57 UTC (Wed) by Felix.Braun (guest, #3032) [Link] (1 responses)

There is a fairly nice Android client for mosh (JuiceSSH) that makes remote administration even over EDGE connections quite bearable. I would not like to miss the possibility of accessing my server on the go with nothing more than my smart phone.

Entering the mosh pit

Posted May 17, 2017 21:00 UTC (Wed) by cgull (guest, #115681) [Link]

JuiceSSH is indeed fairly excellent, but there is an issue that causes screen corruption with a server running mosh 1.2.6 or 1.3.0. Fixed in Git master and the next release (coming soon), or you can fall back to mosh 1.2.5.

Entering the mosh pit

Posted May 17, 2017 16:16 UTC (Wed) by jengelh (subscriber, #33263) [Link]

>the client has to figure out when not to echo — when a screen-mode application is running, say, or when a password is being typed. Your editor did not have access to a network slow enough to exercise this feature;

Easy enough to fix that, without waiting for an airplane:

tc qdisc add dev lo root netem delay .3s

Entering the mosh pit

Posted May 17, 2017 19:53 UTC (Wed) by cgull (guest, #115681) [Link]

Nice article, thanks! I think you have a pretty good handle on what Mosh is good for.

Mosh is a virtual terminal emulator that runs on both server and client. It transmits terminal output from server to client by sending updates from a previous state of the terminal screen to a newer one. It fundamentally maintains a rectangle of character cells for you to look at, rather than sending the complete character stream to update a terminal emulator on the client. So an application can update the screen quickly between two client updates, and character output that would go into scrollback on a normal terminal is simply never sent by Mosh, only enough data to construct an accurate display as of the second update.

So that's the weakness and strength of Mosh-- you don't get the full stream of data that you would with SSH, but the state synchronization protocol allows Mosh to skip intermediate transmitted state and blithely function on astoundingly bad networks. The predictive local echo is also important here. I've used Mosh on wi-fi networks with 50% packet loss and it's been noticeable but entirely usable. (Of course, when a network is this bad, it's a pretty short and steep slope from there to a network that drops all packets. Not even Mosh can fix that.)

Entering the mosh pit

Posted May 18, 2017 9:09 UTC (Thu) by swmike (guest, #57335) [Link]

I love mosh. I have been using it for years, and I'm very happy with it.

The only thing lacking is proper IPv4/IPv6 dual stack support, so one can switch between address families seamlessly.

Entering the mosh pit

Posted May 18, 2017 14:49 UTC (Thu) by caliloo (subscriber, #50055) [Link]

I daily manage remote systems that are either 1 or 2 geostationnary satellite hops from where I sit. I commonly have latencies of 1-2 seconds and single digits % packet drop, doing any kind of work without mosh would be much harder. Keep up the good work :)

Entering the mosh pit

Posted May 18, 2017 16:37 UTC (Thu) by falstaff (guest, #92469) [Link]

I love mosh for its roaming capability: I can put my laptop into sleep at work, open at home and seamlessly continue working on the server. I had mosh sessions running for multiple weeks, even across continents! First, I almost stopped using mosh due to the scrollback issue, but it forced me to give tmux a try. Now that I use tmux to work around the scrollback issue, I also started making use of its muxing capabilities, so I only have to open one connection to the server. tmux furthermore helps when (involuntarily) rebooting the laptop since mosh is not able to reconnect to an existing session: Just create a new mosh session, kill the old mosh server and attach tmux again. I am really happy with this setup and don't look back to my old multiple gnome-terminal tabs with individual ssh sessions setup.

Entering the mosh pit

Posted May 20, 2017 15:41 UTC (Sat) by TRS-80 (guest, #1804) [Link] (3 responses)

I gave up on mosh once I realised it was eating eomji. The relevant bug report is long, but the problem is mostly to do with mosh having to know the width of every character, which is hard when you compare the speed of unicode to update latency of system libraries.

You may think this is a pretty ridiculous reason to stop using it, and I would agree with you, however when reading Twitter with oysttyer sadly emoji being silently removed has a significant impact on comprehension. Having to press up, enter, re-enter my password, then up and enter again (for screen -xU) is far less of a problem.

Entering the mosh pit

Posted May 22, 2017 1:55 UTC (Mon) by flussence (guest, #85566) [Link] (2 responses)

Bad Unicode support is one deal-breaker; another for me is that it doesn't recognise the Delete key (in $TERM=st — which I'm using because urxvt has similar unfixed Unicode problems :-/)

Entering the mosh pit

Posted May 22, 2017 3:36 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (1 responses)

I haven't noticed Unicode issues with urxvt (at least inside tmux). What have you seen?

Entering the mosh pit

Posted May 22, 2017 11:36 UTC (Mon) by flussence (guest, #85566) [Link]

Last time I used urxvt, any codepoint above 0xFFFF displayed as a missing character box. It's one of several bugs that the author acknowledged and refused to fix (interpreting 24-bit color escapes and outputting garbage instead of ignoring them is another); for a terminal with “unicode” in its name that was enough for me to go elsewhere.

Entering the mosh pit

Posted May 22, 2017 2:18 UTC (Mon) by rsidd (subscriber, #2582) [Link]

Other than the scroll thing, the annoying thing about mosh is if your client goes down (laptop reboot) you cannot reconnect to the server. Mosh is useful sometimes, eg if you're working from a laptop and frequently changing internet connections but your client machine will stay up for the not-too-long duration. But if I want a truly persistent session I use screen. (Sometimes mosh+screen.)