Mosh: The Mobile Shell
mosh.org
mosh.org
I know people mention there are issues with some Unicode characters. Somehow I've never hit those issues, so I'm happy.
Specifically in the case of connecting to a server that typically has an old libc with old unicode information, from a desktop that has a much newer system, or in case of ambiguous characters, where libc will just give you one width that might not match what the terminal actually renders (and they frequently have configuration options to change it!).
So we've made something we call widecharwidth (https://github.com/ridiculousfish/widecharwidth), which is a python script that parses the unicode datafiles (UnicodeData.txt, emoji-data.txt and friends) and generates a header you can #include.
And someone's opened a PR to mosh to integrate it: https://github.com/mobile-shell/mosh/pull/1143
I think if we give up on libc, my "perfect" solution would probably be something like: (a) user runs a script that prints every single Unicode character in their local terminal and learns its width (probably we can do this in some smart way) (b) client somehow communicates this info to the server at runtime, over the protocol.
But that's a lot of protocol work and kind of annoying. The good-enough solution might be: (a) user runs a script that prints every single Unicode character in their local terminal and learns its width, or perhaps user just runs your script on the Unicode tables (+ user-supplied info about how their terminal handles ambiguous-width East Asian characters) (b) user is responsible for distributing this data file to every server they feel like connecting to and putting it in some well-known location in their homedir.
I think the current maintainership has their own idea of what they want to do that's not quite this either.
Just to be clear: It's not my PR. The person who made that must've just seen widecharwidth and thought it was a potential solution.
>do we then have to push a new Mosh release every time there's a Unicode update?
In theory, yes. In practice the new codepoints take long enough to be available anywhere and there are few enough of them that being a bit out of date isn't a problem.
(case in point widecharwidth is still on Unicode 12 apparently - I should update that)
>user runs a script that prints every single Unicode character in their local terminal and learns its width
And they would have to re-run that regularly, whenever the terminal updates or they switch.
>user is responsible for distributing this data file to every server they feel like connecting to and putting it in some well-known location in their homedir.
And they would have to do all that setup.
That's a lot of annoyance to put on your users when you can solve 99% of the problem by just incorporating a semi-up-to-date width table yourself.
The perfect is very much the enemy of the good here.
Funny that the volunteer open source maintainer is held to a higher standard than the trillion dollar company :-)
Something seems backwards about that…
I've held off finishing and releasing half a dozen projects over the last year because while I think they'd be useful I know I don't have bandwidth to support them.
Not looking forward to what the majority calls "normal"
Edit: I take that (assume) back and wonder if there’s other social benefits you’ve gotten from isolating regardless of work conditions. I also support that if so!
Mosh works as advertised and has never had a security hole -- we're pretty proud of that! We'll probably cut a release at some point to add those features (24-bit colors, the MacOS clock workaround) but I'm not feeling like it's urgent enough to upset what I had hoped was a transition plan.
It would feel arrogant to compare Mosh to TeX, but it doesn't seem that crazy to imagine that some software might reach a point where it has accomplished 95% of its goals, and the benefit from adding further features has to be weighed against the risk of introducing a security hole or other regression through further churn. If the TCP specification, or OpenSSH, or TeX, or GNU bash had canonical GitHub repositories, they would probably be full of a bunch of user support issues and inactive PRs too. :-)
Sorry if I mis-represented something.
I do wonder whether new releases are required to benefit from fixes and performance enhancements in libraries. Or is everything dynamically linked?
Hiding behind "well we don't want to compromise the core software" after stringing other contributors along for years doesn't pass the sniff test.
Also, I appreciate knowing you all are watching PRs and bug reports even if you don’t see the need to take action. Makes me feel the project is just dormant and not abandoned. If you care about continued use and adoption, you might consider posting an update to the website similar to this post you made here. If you aren’t worried about adoption, then no problem and thanks again for your effort.
We should call it "completed".
The ones where half of my keyboard shortcuts were acting funny (something like https://github.com/mobile-shell/mosh/issues/1147), or garbage left from some other screens/commands (https://github.com/mobile-shell/mosh/issues/1079).
Midnight Commander is also being drawn in a jumpy way.
Note that I'm not speaking about new emojis or some novel Unicode stuff, it's the same basic multilingual plane and line drawing characters we've had for decades now.
Paintings, books, movies... are finished with the bugs in.
Vulnerabilities need rapid fixes.
Every other bugfix requires additional effort and comes with the risk of introducing vulnerabilities or other bugs.
At some point 99.9% of the users are happy and the benefit of fixing another bug becomes marginal.
With all due respect, you pride on this matter should be no bigger than your userbase is.
A lot of Unix tools are like that. They do what they were written to do and that's the scope they're sticking with. It's fine if, maybe once in five or ten years, some support is added for a thing that grew outside the tool itself, such as interfacing a new system component. This conservative development might be a trait of the less-flashy command-line world.
In contrast, the desktop is full of programs that were in that good phase once but then development continued further, adding satellite features that just make the program worse until it's unusable even for the original purpose. Why not write another program to do the new things then, instead of packing everything into a single package? I don't know.
I like the philosophy here, if the software is “done” and there is no immediate need for security fixes, don’t touch it.
Maybe issue a point release where the only change is updating the documentation (man page, output of --version, ...) to state that it is 2021 and you are still here, stable, free of security issues, but not adding/updating features ATM. Then the project doesn't look dead (which can be a security concern) when it is in fact just quietly carrying on with achieving its goals without the need for changes.
The difference that I think makes this comparison invalid is that Mosh is a communication tool, whereas Tex is running locally on files. We (as a community) have learned that any software with a networked attack surface slowly gets less secure over time - you (almost always) need to provide ongoing security fixes to maintain the desired level of security.
To be clear - I'm not saying you're wrong. I'm an intermittent user of Mosh and I can believe that no holes have been found that need patching (and that the team would in short order if necessary). It is, however, a signal that users of software look for. I like the idea in a sibling comment of the "documentation" commit just saying "we're still here" to reassure people.
I think a lot of users look at the release history and cadence as a sort of heartbeat; in order to tell if a project is still being maintained. That can be a problem when a program reaches a mature state.
I can appreciate that, but what do you say to e.g. the contributor that added true color support nearly 4 years ago?
cgull also hasn't authored or committed anything in mosh in more than two years, so his inactivity predates the pandemic by quite a bit.
Everyone loves your software, and that's the reason they want to see another release with the many improvements already in git, most for multiple years. I really don't think you're going to step on any toes by making a new release.
Pretty please?
1) Has there ever been a full security audit?
2) if not and I run it inside a VPN (wireguard) doesn't that remove most of the benefits?
KISS all the way!
Not saying money would solve the challenges the maintainer faces but there might be things it eases. With a tool this popular I expect it wouldn't struggle to raise a fair bit.
There are two really annoying niggles that I have with it, but both I have solved by using a Screen session on the server:
- Scrolling turns out to be very important to most workflows. The choice to start mosh in Append mode (with chance of output corruption) rather than replace mode would be a cool thing.
- There is no easy way to pick up a session again when the client dies. I understand that this is an intended security "feature" though.
But beyond this it is a truly fabulous tool that has saved me many many hours of frustration.
Blink Mobile Shell for iOS (Mosh Based) - https://news.ycombinator.com/item?id=18370348 - Nov 2018 (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 (148 comments)
Mosh – a robust, responsive replacement for SSH - https://news.ycombinator.com/item?id=8928506 - Jan 2015 (45 comments)
Ask HN: Anyone using Mosh? Seems development has stalled since January - https://news.ycombinator.com/item?id=8556680 - Nov 2014 (1 comment)
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)
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)
It reconnects immediately over any connection and works so well you can miss 15% packet loss. SSH feels so brittle next to it.
With mosh, I could start dd, close my laptop, move to a cafe, open up my laptop, and know for certain I'll re-establish the connection when I'm back online.
Personally I use both - mosh (or et) for the seamless automatic-reconnect, and tmux as a console window-manager.
In what way are they more complicated? Granted screen is legacy, but tmux is just an executable on the server with sane defaults that Just Works OOTB.
When you change wifi networks you either have to remember to manually disconnect in advance, or wait for ssh to time-out the connection, then you have to create a new ssh connection, then you have to run an extra command to re-attach to the {screen/tmux} session you started earlier.
It’s not insurmountably difficult work - but for the specific use-case of roaming across wifi networks, “doing a small disconnect and reconnect dance” with tmux is way more complicated and annoying than “open your laptop and all your connections are still working” with mosh.
https://www.bountysource.com/issues/4471419-ssh-port-forward... https://github.com/mobile-shell/mosh/issues/337
you can compile them yourself or if you want to skip the step I recently set up GitHub actions to compile linux binaries of this [1][2], tested by a sample of 1 so no guarantees it works, was planning on doing a tap PR/tap of it at some point
also the official developers have been involved a project to solve this while improving the whole-agent approval things also https://github.com/StanfordSNR/guardian-agent , but I couldn't get it to work which is why I tried the fork and got that working
[1] https://github.com/gnyman/mosh/actions/runs/1068715036 [2] https://github.com/gnyman/mosh/actions/runs/1068715035
I'm confused. I read the whole thing but couldn't find the specific reason for why it's not been merged. But I assume it's because of the things that were pointed out in the code review comments?
Also, the issue you linked is about SSH Agent forwarding, not port forwarding.
There is another issue for port forwarding https://github.com/mobile-shell/mosh/issues/337 but no PR that I’m aware of.
Regarding why it hasn’t been merged, there is a comment on the port forwarding issue which sums it up quite well I think https://github.com/mobile-shell/mosh/issues/337#issuecomment...
My understanding is that the maintainers prefer doing one thing well (and securely). Which to be honest is something I really appreciate even if it means I might have to figure out some agent and port forwarding workaround :-/ at least I don’t have to worry about if my version of mosh will work with whatever the server runs
I run a Wireguard VPN on a VPS, and have machines connect to that VPN. This allows me to reach the machines on the VPN from almost anywhere in the world. Recently I changed the port that Wireguard is listening on to port 443 UDP, which also allows me to connect to my VPN from a few public WLANs that are very restrictive on which ports they allow outbound traffic to.
Wireguard is super easy to configure and run, and very secure.
Definitely give Wireguard a go. It's open source and awesome.
On short/medium trips I no longer bring a laptop. Just my phone and my bluetooth keyboard. I have successfully updated my rspamd DKIM signing config from a hotel lobby, among other things, with just those devices and mosh.
Mosh is great.
1. Log in
2. $ tmux a
3. Continue where I left off.
It's nice to have/annoying not to have more screen for doing real work. But if I'm traveling I'm not doing real work.
Then someone on another HN thread mentioned mosh. That was just what the doctor ordered. It's something I've wished I knew about years ago, given that it's also useful when Wi-Fi gets dodgy.
The latency hiding alone makes it worth it; SSH is miserable over links with any lag, mosh feels as responsive as typing locally until you get into hundreds of milliseconds of latency.
The main benefit for me is mobility, though, not the restore from sleep itself. When I started using this setup I was traveling quite a bit, including just locally (living in a downtown area, I'd start on something in the apartment, then decide to go to the coffee shop, or the growler place, and continue working). Not having to reestablish the connection (even using SSH certs that's still some friction) was very pleasant.
The second is when dealing with an unreliable network. Though this is less common these days, when I started with it I had a lot of issues in my apartment thanks to a neighbor with a noisy microwave oven.
I'd prefer a real IDE on a few occasions (work is C# and Java). Trying to do some side projects to relearn or expand my knowledge of them and their libraries was infeasible on the iPad alone.
In the end, my conclusion is that if you don't need an IDE and can use a CLI or git-based workflow, then the iPad is a fine tool for programming and writing in general. I'm not even stymied by the relatively small screen, it's still better than the monitors I grew up with. The fullscreen and split screen modes also work well with my particular manner of maintaining focus on tasks (I use fullscreen/split screen on my MBP almost exclusively as well).
Isn't that the point of mosh?
"Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes."
I started up mosh and it's been glorious! I used to have to reconnect every time my chromebook went to sleep for any length of time, but now I've had a single session open for ~6 weeks.
It has a nice banner when it loses connectivity, so I immediately know there are network/VPN issues. I don't love the "Control-^" escape key, because it interferes with "Last buffer" in vi, but otherwise it's worked flawlessly.
A decade or so ago I pointed a client at mosh, he had a rural property with satellite Internet and he managed a bunch of other peoples computers. He was overjoyed with mosh!
In case you didn't know, you can change the escape key to something that fits better for you. See the mosh man page (MOSH_ESCAPE_KEY).
So my idea is: nice for amateur small infrastructures, pretty useless for real world (cloud) infras. Maybe you can make mosh-reachable a bastion or two, but no more than that.
Nonetheless, i stress, it's a neat idea.
I imagine such a tool would emulate a terminal a la screen / tmux, and just print what you type until the underlying program outputs to stdout, at which point it undoes what you typed and replays the stdout? I realise I may be betraying a complete lack of understanding of how Unix terminals actually work :)
Is there a Unix utility that implements a local-echo wrapper?
I use it often for pentesting when getting a raw reverse shell. I'll get access to a remote bash session through netcat, and using rlwrap I can do the line editing locally and find the complex commands I've written before without copypaste.
It’s a bit like programming languages. So much cool stuff out there but it’s hard for me to leave Python. Like Bash, everything works with it.
I’m curious what people’s “killer apps” are for permanently changing shells.
Any tradeoffs?
I'd be curious about the trade offs too, I'll have to check it out.
1. et has scrolling support
2. et does not have local echo of your input like mosh does
Edit: The comments below do a very good job of explaining the differences. TIL.
For example eternal terminal has to send all of the bytes in order, so more output requires more bandwidth. Mosh only has to redraw bits of the frame that have changed, at a presumably adaptive rate -- you could scroll a hundred megabytes of text by really quickly, but only need to send a few screen-fulls of updates, which is of course why it doesn't allow for regular terminal scrollback.
No, it doesn’t. The best way I understand it is that mosh syncs a “view” of your current session, whereas et just sends everything. In practice, what this means is if I accidentally cat a 5GB file, mosh zips past as if I were working locally (and ^C works!) whereas et completely locks up until the file reaches its end. That said I still prefer and use et daily due to the scrollback and tmux -CC support.
Mosh really is an un-sung hero when it comes to software. Especially for those of us in the middle of nowhere :)
Otherwise it works decently well for what it does. For many screen and normal ssh will do the job.
If I could get paid to work on mosh I would.
Wait, does mosh have financial backing? Because I was only partly being facetious because I assumed it was an unsponsored project. I'll join IRC :)
For ssh-agent forwarding, most people are using https://github.com/StanfordSNR/guardian-agent which is more secure than traditional agent forwarding, and works with SSH or Mosh.