Chrome Remote Desktop into a GCE Ubuntu VM

Warning: This post brought to you by the miracle that is in-flight WiFi. As such, it includes an uncomfortably high number of TODOs.

I think it would be awesome to have a one-click virtual (and potentially extremely powerful) workstation (Linux in this case, though other OSes would be nice as well) that offered easy-to-use remote desktop support from a lightweight client machine. I haven’t figured out how to get there in one click, but the steps below did get me to the point of being able to use Chrome Remote Desktop from my Chromebook to connect to an Ubuntu VM running on Google Compute Engine.

There are a lot of ways that this could be improved (e.g., via coding it up so that some or all of these explicit commands can be automated away), but I’ve deemed it coherent enough to write down as-is.

Prepare the client system (a Chromebook)

  1. Install the Chrome Remote Desktop extension
  2. Configure the Secure Shell client as described in a Previous Post
    • Note that the web-based SSH client integated with is not sufficient as we will be forwarding ports to setup a secure VNC connection to interact with Chrome on the server system. I would love to find a way to avoid the need for this.
  3. Install the Chrome VNC Client

Prepare the server system to be able to create a VNC-based desktop environment and run its own instance of Chrome (which will be the server in our ultimate Chrome Remote Desktop sessions)

  1. Add Google’s apt package signature verification public key
    wget -q -O - | sudo apt-key add -
    sudo sh -c 'echo "deb [arch=amd64] stable main" >> /etc/apt/sources.list.d/google.list'
  2. Install Chrome, a VNC server, a window manager (using xfce4 here), and the chrome-remote-desktop native Linux package
    sudo apt-get update
    sudo apt-get install google-chrome-stable tightvncserver psmisc xfce4
    # **TODO(jonmccune)**: Use gnome and not xfce4
    sudo apt-get install chrome-remote-desktop xvfb xbase-clients python-psutil    
  3. Open TCP ports 443 and 5222

    See this stack overflow post.

Establish a VNC-over-SSH connection to the server (this is intended to be one-time, since in the future we’ll use Chrome Remote Desktop)

  1. SSH to the VM using the Secure Shell extension, but include -L 5900:localhost:5900 in the SSH Arguments: field. The behavior of that argument is explained in another Previous Post.

  2. On the server, start a VNC server that only listens for connections from localhost: vncserver :1 -localhost. This prompts for a password, though we’re relying on SSH for our security. TODO(jonmccune): how to disable the VNC-specific password?

    • On your client device, open the VNC client and connect to localhost:5900. (You may be prompted for your VNC-specifc password.)

Continue setting up the server via the VNC connection

  1. Open Google Chrome, and sign in to the Google account that you plan to use for Chrome Remote Desktop.

  2. Install the Chrome Remote Desktop extension
    TODO(jonmccune): Enable sharing of the current machine, choose a PIN, etc.

    1. I ran into an issue where the option to enable sharing the current machine was not visible. Returning to the SSH connection, the following commands allowed me to make progress. I’m not sure if I somehow missed an installer step or if this is some quirk of using a particular Linux distro.
    sudo groupadd chrome-remote-desktop
    sudo usermod -a -G chrome-remote-desktop jonmccune
  3. Now open Chrome Remote Desktop on your client system (the Chromebook). If all has gone well, you’ll see your VM instance listed there. Victory!
    TODO(jonmccune): Will Chrome Remote Desktop auto-start when the VM is rebooted?

Using a dedicated Google account

My motivation for setting all of this up is in service of collaboration with others, and so I didn’t want to put my personal Google account credentials in the VM.

The steps above don’t make any mention of using multiple Google accounts, but in practice I’ve set this up using a shared Google account that is dedicated to the purpose of the collaboration. The most convenient approach for me turned out to be to add the collaborative Google account as another user on my Chromebook and take advantage of the multi-user sign-in abilities of ChromeOS. Beware that your collaborators may be able to cause the installation of arbitrary Chrome extensions, but that rathole goes down a long way and is a topic for another day.

Setting up SSH Keys with the Chrome OS Secure Shell Extension

For this exercise the client system is a Chromebook, and the server system is an Ubuntu VM running on Google Compute Engine.

The SSH client of choice on Chrome OS devices is Secure Shell. Per its own documentation, it is possible to use public key-based authentication with the Secure Shell client. However, Secure Shell cannot generate its own keys. My goal here is to be able to SSH into a Google Compute Engine VM running Ubuntu Linux, so I generated the keypair on the target Linux VM using the browser-based SSH client offered by, and then imported them into Secure Shell on my Chromebook. This is appealing because it avoids the need to configure passwords for SSH altogether.

Security note: Generating the keypair on the target machine into which possession of that keypair authorizes access is reasonable. If an attacker already has a foothold in that system, you already lose. However, once that keypair is imported into Secure Shell on one’s client device, it can be convenient to use that key for access to other systems. Consider how much you trust the VM image where ssh-keygen executes before deciding whether to use the same keypair to authorize access to any other systems. Also consider the note about HTML5 filesystems being a relatively young technology in the above link to the Secure Shell documentation about SSH keys. A topic for another day is how to integrate with a physical hardware token like a Yubikey, so that the private SSH key is never exposed to any client device software.

# don’t allow the private key to be written to disk
cd /dev/shm
# generate the actual keypair
ssh-keygen -f gce-instance-ssh
# to SSH into the system where keys are being generated,
# authorize the public key
cat >> ~/.ssh/authorized_keys

This creates files gce-instance-ssh and Both of these files need to be copied onto the Chromebook for importing into Secure Shell. I decided to do this using cat gce-instance-ssh and cat and then copy-pasting the contents of each. The destination was a Chrome extension that can create and edit plain text files. Secure Shell requires that both gce-instance-ssh and be available to import a keypair. I shift-clicked when selecting the files for the Import (to the right of the Identity: field in the Secure Shell connection dialog) dialog box. When selecting only the private key file, there seems to be little or no UI feedback that anything has happened at all.

If successful, the drop-down next to Identity: will have a new entry, whose name appears to be the basename of the imported key files. In this case, gce-instance-ssh.

Telling Ubuntu Network Manager to leave an interface alone

I wanted to assign a static IP address to a USB-to-Ethernet interface.  Edit /etc/network/interfaces… easy, right?  Then the NetworkManager starts to periodically get involved and make conflicting changes.  I’m not yet ready to embrace its GUIness, so I wanted to just disabled it.  

Turns out it’s easy if you know where to look:

sudo vi /etc/NetworkManager/NetworkManager.conf
# Add a line like this (comma-separated list of
# Ethernet MAC addresses of interfaces to ignore):

# Then restart NetworkManager
sudo service network-manager restart

It should then leave your interface(s) in peace.

Ubuntu Live CD with FOG 1.1.2

TL;DR: To do what the title says, get FOG working and then go to its admin page (http://MY-SERVER-IP/fog/management/index.php). Click the question-mark menu item (mouseover text “FOG Configuration”), then select “PXE Boot Menu” from the links on the left, and finally select “Advanced Configuration Options”. This produces a text box where a standalone iPXE script can be pasted in, which will be available from a magically appearing “Advanced” option at the end of the default list presented when your client system netboots. The script that did the trick for me is:

set arch i386
item fog.precise Run Ubuntu 12.04 LTS LiveCD (32 bit)
choose target && goto ${target}
# The kernel's path is relative to /var/www/fog/service/ipxe.
# The files at the nfsroot are a copy of the mounted contents of
# the ubuntu-12.04.4-desktop-i386.iso. Note that this 'kernel'
# line is one long line. ('nfsroot' is an argument to 'kernel'.)
kernel howtogeek/linux/ubuntu/precise/casper/vmlinuz boot=casper netboot=nfs nfsroot=MY-SERVER-IP:/tftpboot/howtogeek/linux/ubuntu/precise
# initrd should be on its own line so iPXE grabs it via HTTP,
# instead of requiring the kernel to grab via NFS
initrd howtogeek/linux/ubuntu/precise/casper/initrd.lz
boot || goto MENU

Mount an ISO persistently with a line like this in /etc/fstab:
/tftpboot/howtogeek/linux/ubuntu-12.04.4-desktop-i386.iso /tftpboot/howtogeek/linux/ubuntu/precise udf,iso9660 user,loop 0 0

The full version:

FOG is a really quick-and-easy way to setup a DHCP/TFTP/HTTP/NFS server which can be a lifesaver when doing low-level experiments using hardware that might not have a CD/DVD drive, bootable USB, etc. I’ve set this stuff up manually in the past and it is always very tedious. I feel compelled to mention that PXE is a completely insecure protocol. It downloads arbitrarily bytes from a cleartext network connection and executes them in CPU ring 0. Configurations like this are unsuitable for anything other than lab-style environments.

I stumbled upon all of this when I basically wanted to do exactly what this link suggests:, but unfortunately it’s for an earlier version of FOG, and rather than use the old version I thought I would see what I could do. This HOWTO suggests editing /tftpboot/howtogeek/menus/linux.cfg from a previous HOWTO, which all comes down to file /tftpboot/pxelinux.cfg/default, which no longer exists in FOG v1.1.2. The reason for this is that the PXE boot menu is dynamically generated on the server using PHP code and a database backend.

With the help of WireShark, I fairly quickly was able to figure out how FOG was working. The TFTP/PXE part was working just fine. The trick is to figure out how it gets the kernel, initrd, and root filesystem for the option it does end up booting. Basically all of the problems I had were with specifying the right access method and path to the kernel, initrd, and root filesystem.

One can pretend to be a client using curl (with its awesome-sauce support to trivially stick in POST arguments):

curl --data "mac0=aa%3Abb%3Acc%3Add%3Aee%3Aff&arch=i386" http://MY-SERVER-IP/fog/service/ipxe/boot.php##params

My apologies for forcing you to probably read the FOG wiki, two howtogeek articles with painfully low information density, and then this, but perhaps it will show up as a search result that can help people frustrated with instructions that apply to stale FOG versions.

How to get rid of Alt-Tab and Alt-` in Ubuntu 12.04 Unity

I was happy with the Alt-Tab behavior before Unity. I tend to switch windows very rapidly and the attempt to animate things, and I find the distinction between Alt-Tab and Alt-` to be very annoying, especially under certain circumstances when Alt-Tab actually does behave as Alt-` does.

Here are some instructions to fix this. I selected the Static Application Switcher. I have not tried the Shift Application Switcher.

OSXFuse + MacFUSE Compatibility Layer + Fuse-ext2 = ext[23] on OS X (ro)

I was hoping to be able to at least read (though writing is always nice) ext3 filesystems on external drives from OS X, without having to start up a virtual machine. This page suggested I use OSXFuse and Fuse-ext2.

It turns out OSXFuse is the actually-maintained descendent of MacFUSE, but that it includes a “MacFUSE Compatibility Layer” (just a checkbox during install; no need for a separate download) that can handle the Fuse-ext2 module (which apparently hasn’t been updated in several years). Nonetheless, these things worked pretty seamlessly for me. I installed OSXFuse, then installed Fuse-ext2, then rebooted. The next external USB storage device I connected with an ext3 filesystem was successfully mounted read-only. Various other places on the web suggest that really slow writing should be possible, but I have not explored that option.