Skip to main content

Mosh is still a bit of a pit

Some months ago I reviewed Mosh (mobile shell). At the time I wrote the article I was looking at the project as a user with a secure view of the world. Now, with the help of a troll, I have rediscovered Mosh, however, it is still "a bit of a pit". This time I have some new complaints.

There is a presentation on the Mosh site. The speaker knows the project and is probably the project owner or lead developer. I'm not certain. He tells the audience about what is wrong with standard terminal sessions and how they developed this mobile communication protocol that rides somewhere between the various layers of SSH and so on. Since the website touts that they are more secure... by inheritance they are as strong as the weakest link but this was an earlier argument.

Then he talks about predictive local echo. The idea here is that in a normal terminal session your keystrokes are not actually echoed on the terminal (unless you have local echo turned on) but represent the output of the server application whether it is a command shell, editor, curses app, or something else. Predictive local echo will echo the character to the local console with the expectation that 70% of the text is echoed by the server anyway... and then the PEL will clean things up.

Well, there are a number of problems with this. The first is that PEL really only works in the shell itself. Once you are in vi and changing modes it is impossible to echo properly... and that is why most terminal emulators default to local echo off. Many old-school applications screen scrape terminal sessions and would not be capable of dealing with PEL as it does not effect the byte stream so much as it does the representation in the terminal window. The demo that was presented was a command shell which is the easiest use-case but is by no means proof or substantive.

Next the presenter tweaks Google for doing an adequate job with mobile applications in that Gmail echos to the console. This argument also misrepresents the domain of webapps, network capable apps, and probably MIT's position on computing all in one statement. SSP is not going to help Gmail be a better app. SSP is not going to make my mobile browser better as I leave my home's hotspot and head into the wilds of 3G/4G. Re-establishing my mobile session is no different than any network disaster recovery plan within the enterprise.

The only thing that might be interesting about SSP is that the important bits about the connection are being moved from one layer of the OSI to another. (I do not know which is which anymore).

**I went back to the Mosh site to get some more details. Sure Mosh is all about the shell but what about the app? They state that the Mosh server is actually a terminal emulator of sorts and that's how they get the delta of screen changes to the local console. It's not until version 1.3 that they implement larger screen buffers... meaning that you're back to tmux or screen for that.

The big issue for me is the firewall issue plus UDP plus roaming connections. This makes hijacking or sniffing more likely once you break the encryption. And if you can get past all that... it only solves one use-case.



Popular posts from this blog

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

UPDATE 2017-10-30: With gratitude the CoreOS team has provided updated information on their pricing, however, I stand by my conclusion that the effective cost is lower when you deploy monster machines. The cost per node of my 1 CPU Intel NUC is the same as a 96 CPU server when you get beyond 10 nodes. I'll also reiterate that while my pricing notes are not currently…

eGalax touch on default Ubuntu 14.04.2 LTS

I have not had success with the touch drivers as yet.  The touch works and evtest also seems to report events, however, I have noticed that the button click is not working and no matter what I do xinput refuses to configure the buttons correctly.  When I downgraded to ubuntu 10.04 LTS everything sort of worked... there must have been something in the kermel as 10.04 was in the 2.6 kernel and 4.04 is in the 3.x branch.

One thing ... all of the documentation pointed to the wrong website or one in Taiwanese. I was finally able to locate the drivers again: (it would have been nice if they provided the install instructions in text rather than PDF)
Please open the document "EETI_eGTouch_Programming_Guide" under the Guide directory, and follow the Guidline to install driver.
download the appropriate versionunzip the fileread the programming manual And from that I'm distilling to the following: execute the answer all of the questio…

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).


I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…