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 that little trick 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 commenter 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.

xpralogin.pngYou 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.

35 thoughts on “Linux-Fu: Applications on the Web

    1. I’ve used X2Go and NX and both are good, but I don’t think either is workable in a browser with no software on the remote side. I wish I could come up with a sufficient security solution that you could hit it without even SSH. But I have been too lazy to put up an SSL proxy in front of it (like nginx).

      1. You are right that x2go needs a viewer, but there is a portable executable which can run without administrator access. Can you comment on the relative performance (in particular in regards to latency when using poor internet connections) of nx/x2go vs xpra?

        1. I had been using OpenNX for years, or the version 3.5 clients from NoMachine, but moved to x2go recently. I’m not totally happy with the move, since I’ve had it crap out and crash on my muiltiple times, and the GUI client is both verbose, not detailed enough, and takes up way too much screen realestate for such a simple mission. Yes, I need to try and setup phyoca client and use that… but haven’t had a chance yet.

          In my case, the ideal is that I fire up a desktop session on a server on a UPS, then connect using the client from a plain stupid simple desktop dumb client, or from windows, etc. Let’s me use my desktop from where ever. Just like screen, tmux or other CLI solutions.

          I wish I was a more focused programmer so I could contribute more to this project (x2go) to make it better.

  1. I can’t get my PI to install xpra. Does anyone have a solid set of instructions to do so? The list of dependencies is vague, and when I try to install 2.0, it tells me I need a version of Python that supports SSL or something. I already did an update and upgrade, and I installed some dependencies I found elsewhere, but still no go.

    1. There is a link to Guacamole in the post. However, I always found running that much server infrastructure to share my desktop on occasion was a bad trade. Now, granted, I have not looked at it for awhile.

  2. xpra is an EXTREMELY underrated program. I have been using it for a while now on my laptop connecting to the desktop from either within the house or across the country. It’s VNC in crack. By far the best part (besides the screen-like functionality) is that it’s also hardware accelerated using cuda (nvidia). Very very very low latency, it’s damn close to using the app natively.

  3. As it turns out I am now hooked in. The old os’s are at this point obsolete and I was hoping I could be steered into the proper/improper direction. I’m almost a smuck for taking on the unknown so I may need some assistance. I do however know a few tricks or treats so it won’t be from ground up exactly.

  4. xpra maintainer here.
    The issues you pointed out have been fixed:
    * the window title bar no longer wraps (fixed in 2.0.1)
    * the password is no longer found in the URL (will be in 2.1 – the fix can be deployed separately)
    Thanks for pointing that out.

  5. Perhaps a bit naieve, but could this work with applications that use opengl semi smoothly? Thinking about using it to control my 3d printer with whatever slicer/software I choose.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s