Linux-Fu: Applications on the Web

Did you know you can run remote Linux GUI programs in a browser with HTML5 support? It’s even secure because you can use SSH tunneling and little trick that means you don’t even need to open additional ports. If this sounds like gibberish, read on, it’s actually pretty easy to get up and running.

I recently was a guest on a Houston-based podcast, and the hosts asked me if the best thing about writing for Hackaday was getting to work with the other Hackaday staff. I told them that was really good, but what I like best was interacting with people (well, most people) in the comments. That sometimes you’d post an article and someone would bring a topic up in comments that would really knock your socks off. This is how I wound up with this nearly ideal remote access solution, that requires nothing on the remote side but a web browser.

A while back I posted about keeping programs running after log off on a Linux box. The post was mostly about non-GUI programs but you could use NX or VNC to handle it. In the comments, someone mentioned how unhappy they’d been with recent copies of NX and another commentor called [Screen for X11] posted about a tool called xpra.

I had never heard of it, so I went to check it out. I was impressed. You could remote single applications (almost like doing an ssh -X; really nice if you are trying to use a little netbook into your massive desktop computer). You can also get a shadow copy of your normal desktop or create a new desktop. Performance was good and you could connect via ssh (or not), do certificate-based authentication, and more. Like many other similar solutions, you can exit and pick back up where you left off.

As I was reading the documentation, though, something caught my eye. There is actually an HTML5 client and web server built in. That means you can export applications from a Linux box to a web browser. This isn’t unique. There’s an Apache project called Guacamole that will sort of do the same thing, but it requires a lot of overhead including a JSP server and performance wasn’t that great last time I tried it. Google has a remote desktop solution that uses Chrome, too. However, the xpra solution is pretty snappy and very flexible. You can see a screencast of me using xpra to a remote server in the video below. Here is a screenshot of a shell and a clock running inside Google chrome on a remote computer.

Without the Browser

The main emphasis seems to be using xpra as both a server and a client. You can find many examples of common usage on the project’s wiki. That’s a good place to start because the man page reveals an enormous number of options. You can provide read-only access, export sound, share printers, link clipboards, scale video, and more — if you have the patience to wade through the documentation.

There are versions for several operating systems, so even if you aren’t using Linux everywhere, you can still try it (honestly, though, I had some trouble getting the Windows GUI to work, although the command line was fine). I did find a version of xpra in the Ubuntu repositories, but it was out of date and didn’t want to work. It was much better to install from the project’s repositories.

Security

The biggest concern, of course, is security. You can set up xpra to use SSL authentication or passwords. You could also use a wrapper or port knocking to control access to a port. I decided to go a different route. I always have a firewall blocking ports that I don’t expect open on my Linux boxes. That way if something does try to open up a port I am not aware of it, it should break and in the process of fixing it, I will know what’s exposed to the outside world.

What I did was let the xpra server run on an unused port locally, but I did not open the firewall for that port. In theory, then, anyone who could log into the machine could access the remote applications, but given this is a server with just a small number of administrators, they could all get into anything, anyway. Of course, remote access only on the same machine isn’t the point, right? That’s why I use an ssh tunnel to get to that remote port. Granted, that makes the convenience of the browser-based client a bit less, but then again, ssh clients that can create tunnels are widely available, so for my case that was acceptable and it seems relatively secure. If someone breaks into the server, they will have access to everything anyway so the remote access won’t really expose anything new.

You can see how I do the ssh tunnel in the video below. You can set up xpra to provide a login screen that (with a bit of configuration) will even work with SSL. The problem is, the web interface puts the password into the URL which means your passwords will be floating around in your browser history. Probably not a good idea.

There’s not a one-size-fits-all solution to security. Before you expose your Linux box to the world, be sure you understand how someone could break into it and take steps to protect yourself.

In Use

It wouldn’t be hard to use this to provide read-only access in a web browser to an application running on a Raspberry Pi. This wouldn’t need to be read only, either if you were sure of your security. A common fallacy is to think you don’t care about security because your Raspberry Pi just does something simple. But if it is on the Internet, people may want to take it over as a platform to launch attacks on other people using your hardware and Internet connection. Don’t ignore any connected device, no matter how trivial, when it comes to security.

Filed under: Featured, linux hacks, Skills