Mitigating security risks with mosh

Mosh is a clever ssh replacement that looks like it would be extremely useful for the typical devops person.  However, it is a brand new tool using a brand new protocol, and as such, it has not suffered the intense scrutiny that ssh/sshd have over the years, and thus it is an unknown risk to deploy it in your infrastructure, no matter how useful it is.  However, with CloudPassage’s GhostPorts, you can largely mitigate those risks, and thus allow you to bring this tool into your world.


Mosh is essentially a stateless replacement for ssh.  So you can mosh into your server instead of ssh, and your connection remains encrypted and working even though you change IP addresses, fall off the net, or close your laptop for a significant amount of time.  If you have many terminal windows open to various servers, you know how tedious it is to re-ssh into all the hosts you were logged into, even with tools like screen and tmux to help.  With mosh, your shell sessions need never drop because your child closed your laptop or you hopped on the train to get home.

But there’s a catch.  The encrypted mosh protocol is UDP based, and it lives on a specific port range by default (60000-61000).  And this protocol, while written by some smart people, has definitely not been audited by the cold, hard world yet.  Nobody has found anything seriously wrong, but there’s been one authenticated DOS vulnerability found already, and it’s almost certain that more will be coming.  Thus, security-minded people are rightfully slow to start using this tool because of the unknown level of risk, just as they are slow to adopt new crypto algorithms, webservers, or new operating systems.


There is a way to have your cake and eat it too!  There are two kinds of risks that mosh presents:

  1. Somebody listening to your session might be able to decrypt or spoof the protocol because of a weakness in it’s crypto or protocol.
  2. An attacker might be able to exploit a vulnerability in a running mosh server to get in your system.

The set of attackers for #1 is pretty small.  People would have to both know a weakness and be in a position to sniff your packets.  Governments and ISPs are likely able to do these kinds of attacks, as well as motivated attackers (like APTs) who are able to spend enough resources to exploit other systems in your home or coffee shop or wherever you work, but your garden-variety hacker will have a very difficult time mounting this attack.

The set of attackers for #2 is pretty big, on the other hand.  Anybody on the internet with an exploit could start poking around on ports 60000-61000 and hit paydirt, just like they did with sshd exploits and port 22 back in the day.

This is where ghostports comes in!  We can mitigate risk #2 by putting UDP port 60000-61000 behind a firewall rule that only allows ghostported users in.  We’ve now limited the scope of the attackers from everybody on the Internet to just those people who can sniff our packets.  In many cases, this level of risk reduction may be enough to allow the use of this tool in your environment.

How to do it!

So let’s show an example.  First, get the CloudPassage Halo daemon installed on your system, and get Ghostports working.

Next, get mosh installed on a system.  There are excellent instructions on, so go there and follow them for your your system.  In my case, it was as simple as saying “yum -y install mosh” on my server and “port install mosh” on my laptop.

Now put the host in a group and set up a firewall policy for that group that allows ghostported users in on UDP ports 60000-61000, and ssh in on port 22 like so:

Now, you should be able to ghostport in and then say “mosh” and authenticate like you normally do through ssh (in fact, mosh actually uses ssh to do the authentication, which is why you needed port 22 open).  Viola!  You now have a shell session that won’t die when you close your laptop or go home or to your local coffee shop, and random attackers cannot attack your mosh server!  All you have to do is re-ghostport whenever your IP changes, and your session will come back to life.


So this is an example where a tool that has some risks associated with it has been rendered much less risky through the use of CloudPassage GhostPorts.  Clearly, you need to make your own risk evaluation and measure that against your risk tolerance level, but for highly mobile administrators, this mitigation could let you bring this tool in and make their day.

Have fun!

Related Posts