Hacker News new | ask | show | jobs
by kenrose 298 days ago
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.

4 comments

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.