When mosh came out back in 2013, it solved a pretty real problem of ssh crapping out when you changed networks (like moving from in-office to home). It solves it at the app layer and uses UDP and is designed to work in high loss / latency environments. Very cool.
At the same time, in recent years, I've found that ssh running on top of Wireguard / Tailscale is way more usable than 2013 days. Those latter tools address the roaming IP issues directly at the network layer.
So while there are still issues with ssh / TCP if you're on a really crappy network (heavy packet loss, satellite link, etc), those have been less common in my experience compared to IP changes.
The “killer use case” for Mosh feels a lot less killer now.
The killer use case was roaming IPs, but I'd say the killer use case today is battling latency. A lot more people are computing remotely now, even on their phones. Even with 5Guw, I still get bursts of crappy latency. And now some people are using 5G as their home internet.
It definitely solves problems when traveling and dealing with crappy airport/hotel/AirBnB/conference wifi that is slow or overloaded.
I used to use mosh when riding Amtrak and using the free wifi. Without it, I rarely could even stay connected long enough to run more than a command or two, but using mosh completely solved it. I had no idea people considered handling changes in the IP to be the primary use case.
Even my home wifi sometimes has enough packet loss to kill SSH connections. And if my computer sleeps for a even a quarter-second, yeah, connection dead.
Mosh means a lot less, "Sigh..." up-arrow, enter. A small thing, but why live with it when you can just not?
I feel a bit silly for not noticing this before. Over the last year or so I've often wondered when ssh added protocol-level support for session resume. I'd open my laptop on a new network and everything would be ready to go. But of course, it's nothing to do with ssh, it's just that I started using tailscale.
And really they didn't even do anything special. This was a killer reason we loved Wireguard at our company and pitched heavily to keep it around to he company who acquired us and wanted us to switch to their VPN Appliance instead.
The main thing a big company IT admin wants is control over the users. At a previous company, they would ship really crappy software, by our own admission, to "enterprise" customers and all we had to do to keep them happy was to give a fancy control-panel that make then feel like king.
Yes, flattery works, pandering-to-ego works. Too bad, you can only push it so far...at some point, CTO/CEO notices.
Agreed. In this company the IT team was being spread thin without their budget being increased so Tailscale was the obvious solution here, but a non-starter for them. "We already pay for a VPN. Let's just use that."
We managed to survive with our solution for a while thanks to it being super simple and "free" besides the instance running wireguard. Last I heard (I left), they shut that all down a few years ago.
1. whether your IP is persistent (ie you can reuse the same socket)
2. your SSH keep alive settings
3. and how quickly your OS can wake up it’s network stack
If the socket persists, then it should be possible to allow SSH to survive longer periods of network inactivity given the right keep alive settings.
When I used to work with on prem systems, I’d run non-standard ssh keep alive so I could bounce network switches without losing access to servers sat in between.
mosh is neat, but I've mostly switched back to good'ol SSH over Tailscale due to various rendering bugs caused by client-server mismatches as well as the lack of port forwarding.
Basically mosh attempts to synchronize the state of the terminal which is made up of character cells. It sounds simple until you realize that unicode and fancy escape sequences exist, and the behavior of the client and the server must match otherwise you get weird misalignments that are difficult to debug:
You really need those patches to have a good experience, and popular mosh clients like Blink on iOS incorporate them in their builds. However, things look wonky if you don't use the corresponding server builds, and you don't want to dig through layers of abstractions to find out why selecting lines in a specific file in neovim causes everything to become a jumbled mess every so often.
There is no end in sight for those patched to be merged upstream, no end in sight for distros to ship new versions, and no end in sight for protocol changes to make state synchronization more resilient. So, back to SSH we go...
Edit: Fixed wrong link for underline/undercurl patch
I used to use this but ran into too many small issues that ended up outweighing the benefit compared to a plain-old ssh connection. Personally, I'm hoping for a QUIC-based alternative that reaps the benefits of being able to change IP addresses and recover from intermittent connection loss without any of the typing prediction stuff from mosh.
This is going back around 8 years so my memories aren't perfect and the issues could have been fixed by now. IIRC my biggest gripes were:
1. There was no scroll-back so you could only see 1 terminal screen of output. If you scrolled back, the text would be wrong or truncated or something like that. We would work around this by launching a tmux session and using that for scroll-back, but tmux scroll-back over a remote connection is so much clunkier than scrolling back in your local terminal emulator. If I'm already launching a tmux session, then I don't need mosh's ability to recover from broken connections because I can re-attach to tmux.
2. I found the typing prediction to be more annoying than it is worth. It worked great in bash but interactive apps (like those based on ncurses), the app would often end up a distorted mess until the round-trip to the server got back the real/correct rendering from the server. If I'm waiting for a round-trip from the server then I'm not getting any benefit from mosh's predictive typing.
3. It was only a remote terminal replacement. If you're doing anything more over ssh (port forwards, x11 forwarding, etc) then you're going to run into all the normal ssh issues anyway.
4. You had to run a 3rd party script to kill old abandoned mosh sessions. This is a consequence of being able to re-attach after a broken connection: the mosh server has no idea if you're coming back or not, so it leaves your session there. At least with tmux I can list the active sessions, re-attach to them, see what they're doing, and destroy them at will. With mosh, you could only reconnect to an old session if you hadn't closed mosh on your laptop. If your laptop powered off (intentionally or not) then you could either play "guess which mosh pid to kill" or leave your mosh session running long enough for the mosh killer script to get it.
Also there was the issue of popularity/network effects. ssh is everywhere, mosh is not, and its hard to argue that mosh should be everywhere when I was getting only slight benefit from it. This isn't mosh's fault, any ssh competitor that isn't upstreamed into openssh is going to run into the same exact problem.
With my hypothetical ssh-over-QUIC I'm hoping for just plain-old ssh with all the normal features, just using QUIC instead of TCP. Ideally upstreaming into openssh. I know there are a bunch of projects out there attempting something like ssh-over-QUIC but I think it has to be upstreamed and a drop-in replacement to overcome the popularity moat regular ssh has built.
Great list that sparked my memory. The tmux scroll back issue was very frustrating for me, and ultimately what made me stop using it. What got me hooked on trying to use it - I do remember being amazed I could close my laptop, go home, and just reopen my laptop and immediately start typing away on my remote terminal without issue most of the time.
A few other issues I do remember running into (probably 10 years ago?):
1. Because it was udp, sometimes a captive portal, work, or hotel firewall blocked it.
2. It was also not installed by default anywhere, so sometimes sysadmins at work were unwilling to install it for me.
3. I sometimes ran into issues with color handling and utf8. I honestly don't remember if it was mosh or my terminal, though. It seemed to happen more often when I used mosh, but I could be misremembering.
I tried mosh years ago, but ended up settling on "ShellFish" by the same guy who wrote "Working Copy". It can reconnect if you use a tmux session, and it has the ability to preview remote files and interact with the Files application on iOS (presenting the remote filesystem in Files).
I used to heavily use Blink Shell, but a combination of changes to their application and also that ShellFish + Tailscale is so easy and reliable made me switch entirely to ShellFish as well.
I also enjoy the ability to quickly launch/manage Digital Ocean instances useful sometimes as well.
It's a great project. I remember years ago, I suffered from intermittent SSH issues when using Vagrant with AWS, and I ended up writing a plugin[1] to replace `vagrant ssh` with `vagrant mosh`, which fixed most of my disconnects. It's a pity Mosh is not supported widely!
Hey all, I’ve been working on an open source rust-based alternative to mosh that solves some of the key issues like scroll back and using WebRTC instead of bootstrapping udp over ssh (which doesn’t work on firewalled networks). Would love any feedback on which features you’d like to see!
> Would love any feedback on which features you’d like to see!
Not leaving pull requests for over half a decade fixing critical issues with not even bothering to comment on them would probably be a massive advantage over Mosh.
the two big features i am missing are port forwarding and sshfs. port forwarding would really be great, because it would allow making stable connections over instable networks.
one thing to consider though is how a large download over an ssh tunnel effectively prevents any other connection through the same tunnel from working.
to fix that possibly sshuttle can provide some inspiration. they solved that problem.
sshfs may be tricky, because it could lead to locked/hanging file access that never comes back if the server goes away. i don't know what the best approach here is. maybe some sort of timeouts, or maybe do let it hang but provide diagnostics with a command that can tell you what the status of the mount is, and force an unmount or restart of the connection if the user knows that the server went away.
aside from that it would just be nice if i would not have to manually remount every time the ssh connection drops.
another feature that i wish mosh had is to be able to reconnect to an existing session even with a restarted client. i don't know what it takes to do that. perhaps you need to store the keys that were used last time on disk which could lead to some concerns, but maybe that file on disk can be protected, or maybe that is not even necessary. i can attach to an existing tmux session, so if the mosh session is treated like that, it would work too?
Hello, very interested in the scrollback! I've used mosh for 10+ years and it still runs my 100+ opened terminals to this day !
Would love to try your alternative
Not yet, but hope to have something up in September! It’s unfortunately not most compatible - I thought about that but didn’t see a lot of value and there were some downsides like re-implementing an encryption layer that doesn’t make sense if you use WebRTC. Just curious, what’s your use case for mosh compatibility?
I used to use mosh, tmux before but always got annoyed how they broke scrolling , searching etc.. Especially when yakuake already provides half the functionality i used to rely on tmux for..
I absolutely love mosh! I use mosh to connect to my tmux server at work, so I don't need to worry about connection drops. Once I was in Europe editing a file, then came home, connected to my work VPN, and was right back in the same vim session.
I found the "lets pretend like there is no input latency" thing to be more distracting than useful. As soon as something does not work as expected the illusion is broken. It made me more grumpy than not having it on in the first place.
I had the opposite experience. I have worked remotely without mosh. The choppiness of responses was more distracting than pretending that the network will always be reliable.
I used ET but it requires a server process also. Some machines are too locked down to allow this. Wish there was a way to kick start the server on demand.
Well yes, but mosh starts its server over an initial SSH connection used for setup, so you only need the binary to exist in PATH of the remote host and you're done. It's more difficult to arrange a service to be running; sometimes more so if you don't have root.
Sure. I guess caveat I haven't used Mosh in a while, so maybe things have changed.
Mosh paints the screen, meaning no native scrollback. You have to use a multiplexer like tmux to get it. But ET has native scrollback. This is the biggest one for me.
Couple years ago I was on a more limited network that constrained usage of UDP which Mosh uses. ET uses TCP.
Mosh buffers inputs locally first which gives it the appearance of low latency but that illusion breaks when there are network issues. I prefer ET, even tho it can appear slower, since network issues are more obvious and I can troubleshoot them. But on a good connection, they're indistinguishable to me.
Those are three. There may be more. Honestly they are probably still more or less interchangeable for most. No reason to switch if you love Mosh.
When doing sysadmin or neteng tasks in remote areas and sometimes on crappy lossy internet, I wish this was on every device. I haven't touched mosh in at least 10 years. JuiceSSH is still my go-to android ssh/mosh client.
I'm a heavy user of mosh on both iOS and Android using Termius (or JuiceSSH) as the client.
It's terrific for making high latency connections feel like a normal one, roaming between WiFi, cellular, and different VPNs without skipping a beat. Even in 2025 it is very useful.
Mosh is excellent, but I've mostly switched to wezterm for similar functionality. It doesn't really persist as well over network changes, but it does allow reconnecting to a terminal session on another box, and it gives some of the type-ahead functionality. What I really like about it is the reconnect and that I have remote, first-class terminal experience, compared to tmux/screen.
Funny sidenote: The mobile client for "Magic: the Gathering - Arena" does not even support "roaming" for your phones connection: If you for example turn off wifi during a match, it looses (and can not reestablish) the full connection even though your phone easily switches to mobile data.
Interesting that it can’t reestablish the connection, as the application level protocol should support it just fine. The client should notice the GRE (game rules engine) TCP socket is broken, and reset everything. When you reconnect, the front door service should notify you to a GRE session still in progress, and the client should be able to rejoin that. At least, that’s how it works on desktop.
My guess is that they get the parameters for the current connection from the phone context and then use a nonstandard library to establish the connection for maybe performance reasons. But then I think they did not bother to implement a mechanism for reconnecting.
Don't know the context for that snippet you're sharing, but the issue for OSC 52 support for clipboard syncing is marked as `Open` in the Mosh repo https://github.com/mobile-shell/mosh/issues/637
To be fair I haven't tested mosh without tmux, I always have tmux running. So I guess the situation is that it's possible to make it work with tmux, but maybe mosh on its own doesn't support OSC52. Which for me is good enough.
A small but noticeable qol improvement when managing servers on the other side of the world. Reliable but fundamentally high latency connection made for annoying ssh, while mosh made it feel like localhost.
Doesn't SSH drop if the connection drops? I keep my connections with Mosh/Eternal Terminal open for weeks or even months at a time, when devices are going in and out connectivity many times.
Eh, "git" is an unpleasant or contemptible person. "mercurial" is subject to sudden or unpredictable changes of mood or mind. Neither of them ran into any issues due to their names. I think it's really only a problem if a word is offensive/inappropriate enough that people would hesitate to say it in a work conference room. For example, the GNU Image Manipulation Program is something I would hesitate to name depending on how senior the leadership is in the room.
The world of screenshot utilities in Linux also has some weird names, with "scrot" being widely used until it was surpassed by "maim" and "slop" on X and "grim" on wayland.
When mosh came out back in 2013, it solved a pretty real problem of ssh crapping out when you changed networks (like moving from in-office to home). It solves it at the app layer and uses UDP and is designed to work in high loss / latency environments. Very cool.
At the same time, in recent years, I've found that ssh running on top of Wireguard / Tailscale is way more usable than 2013 days. Those latter tools address the roaming IP issues directly at the network layer.
So while there are still issues with ssh / TCP if you're on a really crappy network (heavy packet loss, satellite link, etc), those have been less common in my experience compared to IP changes.
The “killer use case” for Mosh feels a lot less killer now.
The killer use case was roaming IPs, but I'd say the killer use case today is battling latency. A lot more people are computing remotely now, even on their phones. Even with 5Guw, I still get bursts of crappy latency. And now some people are using 5G as their home internet.
It definitely solves problems when traveling and dealing with crappy airport/hotel/AirBnB/conference wifi that is slow or overloaded.
I used to use mosh when riding Amtrak and using the free wifi. Without it, I rarely could even stay connected long enough to run more than a command or two, but using mosh completely solved it. I had no idea people considered handling changes in the IP to be the primary use case.
Even my home wifi sometimes has enough packet loss to kill SSH connections. And if my computer sleeps for a even a quarter-second, yeah, connection dead.
Mosh means a lot less, "Sigh..." up-arrow, enter. A small thing, but why live with it when you can just not?
I feel a bit silly for not noticing this before. Over the last year or so I've often wondered when ssh added protocol-level support for session resume. I'd open my laptop on a new network and everything would be ready to go. But of course, it's nothing to do with ssh, it's just that I started using tailscale.
And really they didn't even do anything special. This was a killer reason we loved Wireguard at our company and pitched heavily to keep it around to he company who acquired us and wanted us to switch to their VPN Appliance instead.
The main thing a big company IT admin wants is control over the users. At a previous company, they would ship really crappy software, by our own admission, to "enterprise" customers and all we had to do to keep them happy was to give a fancy control-panel that make then feel like king.
Yes, flattery works, pandering-to-ego works. Too bad, you can only push it so far...at some point, CTO/CEO notices.
Agreed. In this company the IT team was being spread thin without their budget being increased so Tailscale was the obvious solution here, but a non-starter for them. "We already pay for a VPN. Let's just use that."
We managed to survive with our solution for a while thanks to it being super simple and "free" besides the instance running wireguard. Last I heard (I left), they shut that all down a few years ago.
You still need something like mosh if you are going to sleep your machine and expect to reopen an active ssh/tmux session remotely.
That depends on:
1. whether your IP is persistent (ie you can reuse the same socket)
2. your SSH keep alive settings
3. and how quickly your OS can wake up it’s network stack
If the socket persists, then it should be possible to allow SSH to survive longer periods of network inactivity given the right keep alive settings.
When I used to work with on prem systems, I’d run non-standard ssh keep alive so I could bounce network switches without losing access to servers sat in between.
It still improves the latency situation.
mosh is neat, but I've mostly switched back to good'ol SSH over Tailscale due to various rendering bugs caused by client-server mismatches as well as the lack of port forwarding.
Basically mosh attempts to synchronize the state of the terminal which is made up of character cells. It sounds simple until you realize that unicode and fancy escape sequences exist, and the behavior of the client and the server must match otherwise you get weird misalignments that are difficult to debug:
- Unicode 9+ changed character width computation a lot, but macOS `wcwidth` still follows the old algorithm. Let's patch it: https://github.com/mobile-shell/mosh/pull/1289
- There is no support for strike-through and dimmed styles. Let's patch it: https://github.com/mobile-shell/mosh/pull/1059
- What about underline/undercurl? Let's patch it: https://github.com/jdrouhard/mosh/commit/aff5e1c3db9f061deb2...
- Some emojis don't take up two cells as expected? Again, let's patch it: https://github.com/jdrouhard/mosh/commit/b31161ab311c7b6e306...
- ...
You really need those patches to have a good experience, and popular mosh clients like Blink on iOS incorporate them in their builds. However, things look wonky if you don't use the corresponding server builds, and you don't want to dig through layers of abstractions to find out why selecting lines in a specific file in neovim causes everything to become a jumbled mess every so often.
There is no end in sight for those patched to be merged upstream, no end in sight for distros to ship new versions, and no end in sight for protocol changes to make state synchronization more resilient. So, back to SSH we go...
Edit: Fixed wrong link for underline/undercurl patch
I used to use this but ran into too many small issues that ended up outweighing the benefit compared to a plain-old ssh connection. Personally, I'm hoping for a QUIC-based alternative that reaps the benefits of being able to change IP addresses and recover from intermittent connection loss without any of the typing prediction stuff from mosh.
https://github.com/francoismichel/ssh3
What sorts of issues?
This is going back around 8 years so my memories aren't perfect and the issues could have been fixed by now. IIRC my biggest gripes were:
1. There was no scroll-back so you could only see 1 terminal screen of output. If you scrolled back, the text would be wrong or truncated or something like that. We would work around this by launching a tmux session and using that for scroll-back, but tmux scroll-back over a remote connection is so much clunkier than scrolling back in your local terminal emulator. If I'm already launching a tmux session, then I don't need mosh's ability to recover from broken connections because I can re-attach to tmux.
2. I found the typing prediction to be more annoying than it is worth. It worked great in bash but interactive apps (like those based on ncurses), the app would often end up a distorted mess until the round-trip to the server got back the real/correct rendering from the server. If I'm waiting for a round-trip from the server then I'm not getting any benefit from mosh's predictive typing.
3. It was only a remote terminal replacement. If you're doing anything more over ssh (port forwards, x11 forwarding, etc) then you're going to run into all the normal ssh issues anyway.
4. You had to run a 3rd party script to kill old abandoned mosh sessions. This is a consequence of being able to re-attach after a broken connection: the mosh server has no idea if you're coming back or not, so it leaves your session there. At least with tmux I can list the active sessions, re-attach to them, see what they're doing, and destroy them at will. With mosh, you could only reconnect to an old session if you hadn't closed mosh on your laptop. If your laptop powered off (intentionally or not) then you could either play "guess which mosh pid to kill" or leave your mosh session running long enough for the mosh killer script to get it.
Also there was the issue of popularity/network effects. ssh is everywhere, mosh is not, and its hard to argue that mosh should be everywhere when I was getting only slight benefit from it. This isn't mosh's fault, any ssh competitor that isn't upstreamed into openssh is going to run into the same exact problem.
With my hypothetical ssh-over-QUIC I'm hoping for just plain-old ssh with all the normal features, just using QUIC instead of TCP. Ideally upstreaming into openssh. I know there are a bunch of projects out there attempting something like ssh-over-QUIC but I think it has to be upstreamed and a drop-in replacement to overcome the popularity moat regular ssh has built.
Great list that sparked my memory. The tmux scroll back issue was very frustrating for me, and ultimately what made me stop using it. What got me hooked on trying to use it - I do remember being amazed I could close my laptop, go home, and just reopen my laptop and immediately start typing away on my remote terminal without issue most of the time.
A few other issues I do remember running into (probably 10 years ago?):
1. Because it was udp, sometimes a captive portal, work, or hotel firewall blocked it.
2. It was also not installed by default anywhere, so sometimes sysadmins at work were unwilling to install it for me.
3. I sometimes ran into issues with color handling and utf8. I honestly don't remember if it was mosh or my terminal, though. It seemed to happen more often when I used mosh, but I could be misremembering.
For the missing scrollback feature, there is a patch in some forks. There is also C port somewhere.
Pls don't take away arguably the best feature! :-)
I tried mosh years ago, but ended up settling on "ShellFish" by the same guy who wrote "Working Copy". It can reconnect if you use a tmux session, and it has the ability to preview remote files and interact with the Files application on iOS (presenting the remote filesystem in Files).
I used to heavily use Blink Shell, but a combination of changes to their application and also that ShellFish + Tailscale is so easy and reliable made me switch entirely to ShellFish as well.
I also enjoy the ability to quickly launch/manage Digital Ocean instances useful sometimes as well.
It's a great project. I remember years ago, I suffered from intermittent SSH issues when using Vagrant with AWS, and I ended up writing a plugin[1] to replace `vagrant ssh` with `vagrant mosh`, which fixed most of my disconnects. It's a pity Mosh is not supported widely!
[1]: https://github.com/p0deje/vagrant-mosh
Hey all, I’ve been working on an open source rust-based alternative to mosh that solves some of the key issues like scroll back and using WebRTC instead of bootstrapping udp over ssh (which doesn’t work on firewalled networks). Would love any feedback on which features you’d like to see!
> Would love any feedback on which features you’d like to see!
Not leaving pull requests for over half a decade fixing critical issues with not even bothering to comment on them would probably be a massive advantage over Mosh.
Hah, I’ll aspire to do better!
the two big features i am missing are port forwarding and sshfs. port forwarding would really be great, because it would allow making stable connections over instable networks.
one thing to consider though is how a large download over an ssh tunnel effectively prevents any other connection through the same tunnel from working.
to fix that possibly sshuttle can provide some inspiration. they solved that problem.
sshfs may be tricky, because it could lead to locked/hanging file access that never comes back if the server goes away. i don't know what the best approach here is. maybe some sort of timeouts, or maybe do let it hang but provide diagnostics with a command that can tell you what the status of the mount is, and force an unmount or restart of the connection if the user knows that the server went away.
aside from that it would just be nice if i would not have to manually remount every time the ssh connection drops.
another feature that i wish mosh had is to be able to reconnect to an existing session even with a restarted client. i don't know what it takes to do that. perhaps you need to store the keys that were used last time on disk which could lead to some concerns, but maybe that file on disk can be protected, or maybe that is not even necessary. i can attach to an existing tmux session, so if the mosh session is treated like that, it would work too?
Hello, very interested in the scrollback! I've used mosh for 10+ years and it still runs my 100+ opened terminals to this day ! Would love to try your alternative
Awesome! I’ll post it to HN once I have the repo up and the code is in a halfway decent state. Look forward to your feedback!
Do you have a link to a GitHub repo for this? Also, will it be mosh compatible?
Not yet, but hope to have something up in September! It’s unfortunately not most compatible - I thought about that but didn’t see a lot of value and there were some downsides like re-implementing an encryption layer that doesn’t make sense if you use WebRTC. Just curious, what’s your use case for mosh compatibility?
These days i quite like using shpool: https://github.com/shell-pool/shpool
I used to use mosh, tmux before but always got annoyed how they broke scrolling , searching etc.. Especially when yakuake already provides half the functionality i used to rely on tmux for..
That shpool looks like a good idea.
Mosh is really great. When working on remote servers, I combine it with tmux.
Note: Mosh does not natively support agent forwarding similar to ssh. Creator of Mosh explained why in this comment https://github.com/mobile-shell/mosh/issues/120#issuecomment...
I absolutely love mosh! I use mosh to connect to my tmux server at work, so I don't need to worry about connection drops. Once I was in Europe editing a file, then came home, connected to my work VPN, and was right back in the same vim session.
I found the "lets pretend like there is no input latency" thing to be more distracting than useful. As soon as something does not work as expected the illusion is broken. It made me more grumpy than not having it on in the first place.
I had the opposite experience. I have worked remotely without mosh. The choppiness of responses was more distracting than pretending that the network will always be reliable.
Last commit to master was over two years ago, has mosh been replaced by something else or is the project just "complete"?
I have replaced it with Eternal Terminal: https://github.com/MisterTea/EternalTerminal
But I don't know how widespread that is.
I used ET but it requires a server process also. Some machines are too locked down to allow this. Wish there was a way to kick start the server on demand.
Uh, mosh needs to be installed to the server as well?
Well yes, but mosh starts its server over an initial SSH connection used for setup, so you only need the binary to exist in PATH of the remote host and you're done. It's more difficult to arrange a service to be running; sometimes more so if you don't have root.
Same here. I tried a while back and nearly immediate switched over to using it over Mosh, for the same reasons you gave.
Can you tell us why you made the switch?
Sure. I guess caveat I haven't used Mosh in a while, so maybe things have changed.
Mosh paints the screen, meaning no native scrollback. You have to use a multiplexer like tmux to get it. But ET has native scrollback. This is the biggest one for me.
Couple years ago I was on a more limited network that constrained usage of UDP which Mosh uses. ET uses TCP.
Mosh buffers inputs locally first which gives it the appearance of low latency but that illusion breaks when there are network issues. I prefer ET, even tho it can appear slower, since network issues are more obvious and I can troubleshoot them. But on a good connection, they're indistinguishable to me.
Those are three. There may be more. Honestly they are probably still more or less interchangeable for most. No reason to switch if you love Mosh.
I’m sold just hearing “native scrollback”.
Thanks for responding! :)
Why update if something is perfect? Like in the old days: final version :) wait for new one in few years :)
When doing sysadmin or neteng tasks in remote areas and sometimes on crappy lossy internet, I wish this was on every device. I haven't touched mosh in at least 10 years. JuiceSSH is still my go-to android ssh/mosh client.
Fond memories of moshing while ssh'ing into remote machines and tethering off my phone on the Caltrain. Great product
Same. Just substitute the Sounder a couple states up ;)
I'm a heavy user of mosh on both iOS and Android using Termius (or JuiceSSH) as the client.
It's terrific for making high latency connections feel like a normal one, roaming between WiFi, cellular, and different VPNs without skipping a beat. Even in 2025 it is very useful.
Mosh has been solid for so long. Love it.
I've tried mosh several times and always found it to be more annoying than tmux/screen + living with the reality of dropped connections on mobile.
Mosh is excellent, but I've mostly switched to wezterm for similar functionality. It doesn't really persist as well over network changes, but it does allow reconnecting to a terminal session on another box, and it gives some of the type-ahead functionality. What I really like about it is the reconnect and that I have remote, first-class terminal experience, compared to tmux/screen.
Funny sidenote: The mobile client for "Magic: the Gathering - Arena" does not even support "roaming" for your phones connection: If you for example turn off wifi during a match, it looses (and can not reestablish) the full connection even though your phone easily switches to mobile data.
Interesting that it can’t reestablish the connection, as the application level protocol should support it just fine. The client should notice the GRE (game rules engine) TCP socket is broken, and reset everything. When you reconnect, the front door service should notify you to a GRE session still in progress, and the client should be able to rejoin that. At least, that’s how it works on desktop.
My guess is that they get the parameters for the current connection from the phone context and then use a nonstandard library to establish the connection for maybe performance reasons. But then I think they did not bother to implement a mechanism for reconnecting.
Mosh is so good, but their unwillingness to implement OSC52 for copying to clipboard sent me back to tmux.
Eternal Terminal works as well as Mosh for me and supports OSC52. I switched to et in order to sync my remote tmux clipboard with my local clipboard.
I think this actually works now, I use both tmux and mosh and can copy things fine. See e.g. https://gist.github.com/yudai/95b20e3da66df1b066531997f982b5...
Don't know the context for that snippet you're sharing, but the issue for OSC 52 support for clipboard syncing is marked as `Open` in the Mosh repo https://github.com/mobile-shell/mosh/issues/637
To be fair I haven't tested mosh without tmux, I always have tmux running. So I guess the situation is that it's possible to make it work with tmux, but maybe mosh on its own doesn't support OSC52. Which for me is good enough.
I've tris Mosh several times and never found any tangible benefit in any scenario.
Close laptop and it's fine. Open laptop next day at work and your session is still there, it just reconnects itself. It's quite satisfying.
A small but noticeable qol improvement when managing servers on the other side of the world. Reliable but fundamentally high latency connection made for annoying ssh, while mosh made it feel like localhost.
Doesn't SSH drop if the connection drops? I keep my connections with Mosh/Eternal Terminal open for weeks or even months at a time, when devices are going in and out connectivity many times.
Working on servers via ssh over mobile hotspot
Mosh is a lifesaver
It's great for SSH from my phone. The connection is just there whenever I unlock my phone.
Yes, but I've also found that I can have ssh open from phone for days to my home computer, if I've established it over a VPN (in my case wireshark).
I suppose this didn't always use to be the case, though.
I often use jump hosts in SSH, but is the only way to do this in mosh to mosh into the relay and then mosh again?
Mosh + GNU screen: persistent auto-reconnecting terminal sessions
Eternal Terminal is just… better
Related. Others?
How ‘Mosh’ Rescued Me from Connection Hell: A Remote Work Story - https://news.ycombinator.com/item?id=35639011 - April 2023 (2 comments)
Mosh: An Interactive Remote Shell for Mobile Clients (2012) [pdf] - https://news.ycombinator.com/item?id=33717028 - Nov 2022 (37 comments)
Mosh 1.4.0 Released - https://news.ycombinator.com/item?id=33439542 - Nov 2022 (12 comments)
Mosh's tolerance for high packet loss helps a guy escape from an elevator - https://news.ycombinator.com/item?id=28157117 - Aug 2021 (34 comments)
Mosh: The Mobile Shell - https://news.ycombinator.com/item?id=28150287 - Aug 2021 (153 comments)
Mosh - https://news.ycombinator.com/item?id=22810589 - April 2020 (148 comments)
Mosh - https://news.ycombinator.com/item?id=18692618 - Dec 2018 (9 comments)
Mosh v1.3 Released - https://news.ycombinator.com/item?id=14228591 - April 2017 (69 comments)
ASK HN: How does mosh shell use UDP but provide reliability like TCP? - https://news.ycombinator.com/item?id=12519557 - Sept 2016 (1 comment)
Mosh: the mobile shell - https://news.ycombinator.com/item?id=12429203 - Sept 2016 (49 comments)
Mosh: the mobile shell - https://news.ycombinator.com/item?id=11572146 - April 2016 (147 comments)
Mosh, the SSH Alternative Option for System Administration - https://news.ycombinator.com/item?id=11208757 - March 2016 (2 comments)
Mosh – a robust, responsive replacement for SSH - https://news.ycombinator.com/item?id=8928506 - Jan 2015 (45 comments)
Mosh: A replacement for SSH - https://news.ycombinator.com/item?id=8252093 - Sept 2014 (122 comments)
Mosh (mobile shell) - https://news.ycombinator.com/item?id=6321474 - Sept 2013 (6 comments)
Do you use Mosh? (SSH replacement) - https://news.ycombinator.com/item?id=5729004 - May 2013 (4 comments)
Mosh: the mobile shell - https://news.ycombinator.com/item?id=5016745 - Jan 2013 (89 comments)
Mosh: the mobile shell - https://news.ycombinator.com/item?id=4588239 - Sept 2012 (1 comment)
Mosh: SSH for 2012 - https://news.ycombinator.com/item?id=3819382 - April 2012 (193 comments)
Mosh: the mobile shell - https://news.ycombinator.com/item?id=3814589 - April 2012 (2 comments)
[dead]
Which app ppl use on iOS, the new Blink Shell? Is anyone directing Claude from the phone with it?
I switched from Blink to Prompt after many years.
I can't speak to Claude, but Emacs and Vim work well in it.
Unfortunate name. "Mosh" is pronounced exactly as "moche", the French word for "ugly".
Eh, "git" is an unpleasant or contemptible person. "mercurial" is subject to sudden or unpredictable changes of mood or mind. Neither of them ran into any issues due to their names. I think it's really only a problem if a word is offensive/inappropriate enough that people would hesitate to say it in a work conference room. For example, the GNU Image Manipulation Program is something I would hesitate to name depending on how senior the leadership is in the room.
Let's not forget https://github.com/cocaine/cocaine-core
The world of screenshot utilities in Linux also has some weird names, with "scrot" being widely used until it was surpassed by "maim" and "slop" on X and "grim" on wayland.