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.
I was already using tmux for session persistence, so the local echo and handling of congested networks were the two features that made me wish I'd switched to mosh earlier.
mosh does persistence better, if you're connected to tmux over SSH it'll still disconnect as your IP changes on a roaming connection (like it does on my daily commute on the train). mosh does not, it stays no matter what. Also no need for autossh or similar to reconnect when you unsuspend your computer.
Of course there’s also the big problem of lack of scroll back in mosh as mosh actually handles the terminal emulation. I suppose this would be especially bad on an iPad with an on-screen keyboard, as the number of lines would be severely limited. How does Blink handle this problem?
(I use Prompt 2 on my 12.9’’ iPad Pro which doesn’t support mosh. I only use mosh on computers with very high latency servers.)
Yeah, Blinks doesn't handle the scrollback problem neither. I always use a bluetooth keyboard when I connect the shell so I launch tmux inside of it, so I use tmux's scrollback feature. Besides I don't much need scrollback when I use iPad anyway.
I have to admit that terminal is inherently not suited for touchscreen. Here I am suggesting iPad Pro a laptop alternative for a dedicated terminal use, where you use a physical keyboard.
No particular reason, I picked it at first (when the iPad Pro 12.9'' came out in 2018, which incidentally was my first iPad) and it's been working okay for me, so not much of an incentive to shell out $20 for another terminal emulator. Also Panic is one of the more trustworthy shops out there (one of the reasons I picked it at first).
You should anyway run mosh+tmux. Not sure about this though, ssh still disconnects and you have to reconnect and then launch tmux attach again. I agree it doesn’t seem like much, but just opening any device and continue from where you left off without any extra interaction feels great. It is kinda like auto save on iOS, you could argue that pressing the save and open button isn’t that big of a deal, but once you experience it the experience changes completely.
Any reasonable ssh client should be able to reconnect to a tmux session without any interaction. The benefit of it being instant is certainly nice, but I'd still classify it as minor, especially since forced disconnects are only really a problem that way on iOS.
> 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).
Exactly. Close the laptop, connect to another network... as soon as you connect the network again you’re still on the server and your long running process still runs there.
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.
Not really, one of the greatest things about mosh is it's ability to restore connections, even if you put your host to sleep, have a network outage, switch from wired to wireless, and the like. The connection just comes back like magic.
Yes. I run a small Ultima Online custom server and it runs on a Debian box in a datacenter. My primary development machine is my macbook, and mosh-ing to my server is flawless, even from congested coffee shop wifi. The best part is I can use juicessh to mosh in from my phone if I need/want to as well!
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)
But you do see lag - if you have auto/tab-complete, history search, command suggestions, etc, those all will still lag because they are waiting for a response from the server.
The lag that is eliminated is the local echo of characters as you type, as mosh is sending those asynchronously in the background. If you have fancy, more interactive prompt/cmdline on the remote server then you'll still see the issue.
Ditto if you run tmux on the remote server. I really wanted to like/use mosh, but there's too many issues of reality that it can't gloss over.
If you're just maintaining basic SSH sessions into remote servers, then it's great. But if you have a nice, interactive remote development environment then you still get the same lag and latency issues.
But what’s the alternative? Local development with syncing back to a server?
The lag is something that I can deal with. For me, the killer feature is the automatic reconnects. I usually only use mosh when I’m traveling and at conferences. In that scenario, I’m either using my iPad (with keyboard) where the client might be killed anytime I switch apps or I’m using the conference WiFi, with is always spotty. In either case, using a mosh client makes me less likely to throw my laptop or iPad down in anger every 5 minutes.
>But what’s the alternative? Local development with syncing back to a server?
I'd say this is a perfectly fine solution for a lot of cases. Not all, of course, like your iPad one sounds a great fit for mosh (and I'm gonna try it out!) But even a RaspberryPi can power a really powerful terminal.
You can use sshfs[0] to mount a remote drive over ssh. Obviously there will still be some lag - `ls` will require a round trip - but your local terminal will be much snappier.
How is mouse support in Blink? I've been searching online and can't find a good answer. I regularly use the mouse in Terminal.app to manipulate Tmux windows and move around in the Micro text editor. I am curious about Blink, but hesitant to drop $20 if it turns out it doesn't work the way I need it to for terminal usage.
It isn’t great at the moment. Something broke in the recent update to break text selection, which is what I was trying to use a mouse for. But, the author is working on a fix. I don’t know how good the mouse works uses other than selection, but mouse support in general isn’t great at the moment.
But Blink is the app I use for SSH/mosh on the iPad too.
I used to use mosh fairly extensively and only really had two problems I wanted solved. I didn't care enough to learn to code them myself so I called it good enough.
Because my local server is my laptop at home with cheap ISP bandwidth; my remote server is in a data center with high-speed bandwidth and much more CPU/RAM/SSD than my laptop.
Why do you suffer to use a local server/internet for development? I've been using the "laptop is a dumb terminal" paradigm for many, many years and I've avoided a lot of headache that I've seen in others trying to get everything to work "locally".
Yes, this means I need to be online to work, but almost nobody works offline anymore - between googling issues, downloading/updating dependencies, and browsing while compiling, having an internet connection is assumed.
For me the axis is not computer quality, it's IDE quality. My productivity in a large codebase jumped 10x when I switched from emacs to IntelliJ (for Java). Going back would be like blindfolding myself after I grew up blind and got my eyesight restored once.
Remote development is tricky indeed. Many people run the IDE locally and use its remote development functionality. I run it remotely over VNC.
I've been wanting to try out remote developing for multiple years now, it would allow me to get an iPad with a perfect battery life or an Macbook Air that would tag along all day without charging. But because I cannot work with vim/emacs and my IDEs (IntelliJ) do not support anything like remote development I am stuck with a huge Macbook Pro including a battery draining IDE that cannot be ran remotely. VNC added too much lag for me to use all day.
Latency is a problem indeed, I am lucky to be close to work and have massive bandwidth all the way to my dev box. Without that the experience is pretty poor, and I used to make it work by dropping bit depth to the minimum bearable level.
Space? Performance? Builds typically perform best directly adjacent to storage, and if you're working with a large project syncing that back and forth may be slow.
As someone who’s been fairly mobile/nomadic most of my career, I have always enjoyed the thin client approach.
I can get many more years of service from my client hardware when offloading the bulk of compute, storage, and stable bandwidth needs to beefy servers.
I’ve found that it’s just generally more economical and efficient this way.
Plus, the few times I’ve had laptops die, get stolen, damaged etc to have a much lower impact when they don’t have anything all that important on them.
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.
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.
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.
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).
I usually don't even have a PC when remote, it's an Android phone. And when I do, it's a ~2005 x86 netbook - good enough for a thin client, not powerful enough to run the dev stack (which is x64 anyway).
If you're using emacs, you may be able to use Tramp to remotely access the file. It depends on how IDE-ish you've got your emacs set up. As long as you've got reasonable latency I find that much nicer.
(If you already know, well, I'm sure someone else just learned something today.)
Oh absolutely. I like using tramp to edit individual config files remotely. If there is one particular data acquisition computer that is performing incorrectly, I can quickly open up that file to compare, without needing to leave the editor.
The issue I ran into with editing code through tramp is the integration with make. I use `M-x compile` to compile from emacs, with a few modifications to find the appropriate makefile depending on which project I am working on. If I try to compile locally based on remote files, my compile times go through the roof. I suppose I could have opened an ssh session in which to run make, but it was easier to open emacs remotely.
The other advantage is that I could use tmux+emacs to have everything remote, and to connect to that same session from multiple computers. A typical day during an experiment might have me start in an office, later head to an experiment monitoring room, and later head down to the experiment vault to see if an issue is being caused by hardware. With remote editing, I could have the the entire session, including any files that I have already opened, no matter where I am physically located.
Ooh, nice. I'll have to take a look at it again. That may be something that I accidentally broke in customizing my environment. I bound `C-c C-c` to look for either a Makefile or a SConstruct in the current directory, walking upwards up the hierarchy until one is found, then to launch either make or scons depending on which one is found. That may have been the source of my remote issues.
- If you're walking the filesystem, make sure you start from the "default-directory" variable.
- If you call other programs, make sure you use "process-file" (for synchronous processes) or "start-file-process" (for async). Using "call-process" or "start-process" unfortunately won't do the right thing, but the two functions I mentioned are mostly drop-in replacements.
Those sound pretty useful, and I will need to try those out. I used (file-name-directory buffer-file-name) as the base for walking the filesystem, which may have caused some issues. I also have a cd in the shell command passed to compile, which probably doesn't play nicely.
Unfortunately, my current job doesn't use Linux as much, and so it has been too long since I've spent time improving my .emacs file, as it is only home projects at this point.
This is actually the root of my italicized "may"; I've seen Tramp do surprising miracles in terms of working remotely with things like this, but I've also seen other things not work because of the various complexities involved. It's at least worth a try, but I've never actually learned elisp to speak of so I have no idea how hard it would be to fix any issues you may find.
I coded PHP like that a long time ago. There was a great editor, maybe called E or something to that tune that would made it seem as if your files were right there locally.
Since no one has put this reason out there: to have one's development OS mirror production[1]. IME, the "develop on Mac, break on Linux" problem is not uncommon, even with high level abstractions. Plus, things like docker are native.
This can be all done in a VM, of course. I personally like the remote server, especially since they can be spun up so easily with cloud services now.
[1] - Though sometimes that's impossible. I.e. embedded.
My work prefers their IP be kept inside their network, so to speak. Yes, nothing really prevents me from cloning my work git over the VPN and doing the work locally, except for norms and limited local disk space.
Because I can literally walk away in the middle of a debugging session, grab any random notebook in the house, travel to Djibouti and resume exactly where I left off (ok, replace Djibouti with a random coffee shop). It has completely changed how I work and I love it (mosh + tmux = <3).
ADD: I do switch frequently between my desktop and multiple notebooks. Working this way means I can have a beefy/noisy development server and a light & quiet notebook which just needs mosh.
mosh is very useful for intermittent connectivity. Anytime I had to rely on spotty 2G/3G/wifi, the usual workflow "work locally ; git push" failed, as it's TLS/TCP and not resumable. Had to autossh+rsync the diffs out onto a stable host in the cloud, and then essentially worked from there.
Also, I have a mosh client on my smartphone; setting up the dev environment there would be a bear. Essentially the mainframe model ;)
And most of them either rely on SSH+rsync, syncthing, or something along those lines - in other words, tools that will sync the files reliably, even on bad links...eventually. Never have I seen a backend that's built for editing...the remote-mount abstraction mostly works, but leaks specifically in these edge cases.
ET uses a layer above TCP to make connections persistent, while mosh uses UDP which is better for high-latency or flaky connections (like 4G or wifi). For the use case in the original post with a congested wifi network, mosh is probably going to provide a better experience.
I use Blink on my iPad, as it supports mosh for ssh connections. As iPadOS sets limits for background execution and quickly kills apps, it is great to be able to reconnect to your running session.
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.
The lack of scrollback is what stopped me from using mosh before. I never knew about Eternal Terminal, but I've just installed it and it seems to work well (my issue is unreliable connections, rather than latency, so the lack of prediction doesn't affect me as much)
ET has the somewhat undesirable characteristic that if you cat /dev/random or some other large file, you're going to have to kill the ET process if you want your terminal back. Mosh does not suffer from that
Having extremely little knowledge of how these things work and thus a strong personal resistance to them (I only started using tmux recently, and exclusively with iTerm’s integration for its “control center” mode, just so I don’t lose sessions if my SSH disconnects), I’m seeing a lot of setup and caveats and am a bit scared off by these. This one looks nice because it has scrollback (essential) but it seems to require a bunch of installation on the remote? I have SSH on all my machines already; is there not something that can bootstrap a session from just that?
There are moments that tmux's persist session won't work well such as opening nested SSH sessions to another machine with nested tmux to keep the session. Also, tmux does not handle SSH sessions, so if a SSH session disconnected (e.g. WiFi signal lost, your macBook gets sleep mode), you need to manually restart the SSH session and run tmux again, whereas Blink and ET never disconnects the SSH session.
On top of that, I use both tmux and Mosh at the same time. You don't need to use tmux exclusively.
I meant, you don't need to get scared. Both ET and Mosh built on top of SSH and there never be critical errors when dealing with their shell. Though both of them requires installations on the remote but they are a single zero-config packages: just install a package (not "a bunch of") and that's it. No config needed, even no background systemd services needed.
Right, I see how it can be more convenient but I also see caveats so I’m not sure if I should bother. I’m not really a fan of installing much, either: often I don’t really want to do a whole install to get into a machine (some random AWS for instance) or I just can’t (not my machine, no admin privileges, paltry package manager, …)
> There are moments that tmux's persist session won't work well such as opening nested SSH sessions to another machine with nested tmux to keep the session.
what difficulties are you facing there? i use tmux deeply nested without problems. one trick i use is to change the tmux command key to be something different on each nesting level.
If you just want a persistent connection, you never have to press the command key or even acknowledge it exists, do you? And you didn't answer what difficulties you've personally faced.
If I just want a persistent connection, then the nested tmux that takes 2+ useless lines in the bottom already falls into the "it doesn't work well" category.
And I what I said that the problem was the moment I have to have different tmux config for every machine, just like she/he is doing.
I guess I just don't understand why you need the tmux command key at all. If you pretended it didn't exist, what feature would you be losing out on that mosh has?
And when you're setting up a server it's easy to turn off the tmux status bar.
indeed. the only thing i need to do is copy a config file to set up the command key. the main use of the command key is to switch terminals and to access scrollback. beyond that, the key is rarely needed. working in any terminal is the same no matter how deep the nesting. i don't notice it.
the multiple toolbars don't bother me either. they can serve as a visual aid to recognize where i am. each terminal looks different. but in reality i don't pay much attention to them.
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].
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.
EternalTerminal[1] was mentioned in a comment below. It supports port forwarding, and other goodies like native scrollback, at the cost of latency on laggy connections (because it doesn't do full terminal emulation). If that tradeoff sounds good to you, try it!
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.
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)
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.
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".
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.
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.
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.
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.
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.
The main trouble with using screen for scrollback is it introduces latency when I need to scroll, and that's exactly the problem I was trying to solve when using mosh in the first place! Maybe I could completely change the way I work, but for now I'll continue to put up with typing latency and other problems with ssh.
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.
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.
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.
Would running screen inside fix the scrollback problem for you? Like in
alias server='mosh server -- screen -xRR -D'
I recently switched to st from suckless-tools which does not have scrollback at all, and I start screen for every st window, so my scrollback experience is consistent between remote connections and local terminals.
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".
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.
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?
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'.
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.
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.
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!
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.
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.
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).
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.
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.
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.
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.
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/