Warning: this post is intensely technical, bordering on arcane. It’s about improving your user-experience as a command-line user on remote Unix-like systems. As such, it’s probably not intended for you, but my hope is that someone else will find it useful. The usual geeky stuff (food, travel, language, etc.) will follow again soon.
If you ARE the someone else, score!
Ours is a pretty geeky apartment. But we don’t always just stay there at home; often our geekery needs to travel with us.
- I’ve got five computers running some flavor of Unix (I’m counting Macintosh computers among those) at home in the apartment, 2 of which can travel with us and three of which stay in the apartment (two desktops and a tiny fileserver/webserver/webproxy). Some of them stay running while we’re out traveling.
- I’ve got a mifi we can use while traveling inside of Germany.
- I’ve got web hosts which allow/require me to use the command line to make certain kinds of updates to the design and functionality of this site and others.
- Cellular coverage in Germany along the train lines (around here, anyways) is lousy, even on the major carriers like Telekom and Vodafone. Don’t get me started on O2‘s network coverage in Regensburg (seriously, I can’t believe that people actually give them money).
- Sarah and I both still use an old-school bulletin board system (perhaps partially for sentimental reasons) via the command line.
All of these things add up to annoyance with slow network speeds for command-line tasks. You type a character on the keyboard, and during the time it takes to register that input and show it to you on the screen, you’ve hit that key several more times. Or you’ve tappy-tap-tapped merrily away and spot the typo only after the big stream of text finally registers on the remote machine and is echoed back to you. Correcting that typo may not be feasible.
Oh crap, I meant "all good men" of course, but on this entirely pokeyyyy
connection via command line it’s too much of a PITA to bother trying
to correct it.
— INSERT — 1,14 All
Enter mosh, the mobile shell. It’s designed specifically to make slow internet connections on the command line less annoying, without sacrificing anything in terms of security. It features an intelligent local echo, meaning that it will detect when your connection has taken a snooze and show you the results of the keys you’ve pressed in the meantime. Apparently you can even put your computer to sleep and wake it up on another network later, and mosh resumes the connection where you left off. I haven’t tried that aspect of it, but I am looking forward to it.
- SSH: mosh runs on top of SSH, enhancing it and correcting known problems in it. But you can’t run mosh without it.
- UDP ports: at least one UDP port in your firewall, if you don’t have one you can use already available. Mosh expects to be able to use a random UDP port between 60000 and 61000 for each session by default, but you can make it work with an explicitly named UDP port via a command-line argument.
- UTF-8 locales: mixing 8-bit and multi-byte input can result in mild errors on fancy international characters (at best) or a bricked terminal window (at worst). Part of mosh’s approach to this is making sure all parties are on the same page, namely UTF-8. While getting it set up, this was the point that caused me the most hassle. In fact, I’m still not happy with changing my locale settings on the local machine to make mosh work with the remote machine. But it seems the developers are aware of this fly in the ointment.
- If you run SSH on a non-standard port (i.e., not on port 22), then you need the latest (as of this writing) version of mosh. The version in the Ubuntu repositories is 1.1.3-1; you’ll need to get version 1.2 or greater. I had to compile it from source, and THAT meant I had to install a few other packages, too.
Of particular note: mosh runs in user-space; you don’t have to set it up as a daemon or be root (you just have to make a UDP port available to it). That also means it’s not sitting around running on your server, waiting for you to use it. It only starts on the server when specifically called from the client. As such,you can run the mosh-server from your home directory or elsewhere if you don’t own the server machine, like this:
(In fact, I do own the server “bigmac,” but for whatever reason, installing the mosh package from macports.org put the mosh stuff in
/opt/local/bin instead of
/usr/local/bin — not sure if that’s supposed to be that way, or something that I caused when I installed macports. Either way, I can get around it with the client-side argument containing the path to the server-executable.)
It’s easy to tell mosh to use an arbitrary port for the SSH connection, too (starting with mosh version 1.2):
(And if you put a host-specific port parameter into your
~/.ssh/config file, mosh will use that port, thereby keeping mosh and SSH consistent in the way you start them.)
Most of the time these days, dev work on the go is doable via GUI tools running locally, and sychronize local changes with the remote machine for you in a batch. But sometimes, there’s no substitute for logging in at the server and looking around in the logs directly or tweaking a config file. SSH is already really good for that. By reducing the effects of the lag associated with high latency networks (like via your cellular modem or crappy hotel WLAN), mosh makes it even better.