So you’ve spun up a fresh Linux Workspace and discovered in short order that it is ugly as sin. Fret not, this is as configurable a Linux machine as any — but in different ways than you might be used to.

Enable SSH

Fortunately, Linux WorkSpaces run sshd by default. However, there’s no way to get to it from the Internet.

This is worth fixing up sooner rather than later, as you may run into a problem in the future with your workspace becoming Unhealthy. An Unhealthy WorkSpace is a WorkSpace that AWS can’t reach, usually caused by networking problems. You won’t be able to connect to an Unhealthy WorkSpace through the WorkSpaces client, so it’s good to have SSH handy for debugging.

Before exposing port 22 to the Internet, edit /etc/ssh/sshd_config and tighten up the security a little bit: set ChallengeResponseAuthentication to no. This prevents password logins and allows only key-based authentication. An exposed SSH port in an AWS IP block is a massive target for brute-force attacks; no sense in letting anyone try.

Now, sudo systemctl restart sshd. Verify it’s running. Add your public key(s) to ~/.ssh/authorized_keys. Once you’ve done that, open up the AWS Console.

The WorkSpace itself isn’t visible in the EC2 console, but the network interface attached to it is. Visit “Network Interfaces” and select the ENI “Created by Amazon WorkSpaces.” While you’re here, by the way, I highly recommend registering the Elastic IP attached to your WorkSpace ENI with some kind of DNS. It’s a lot more convenient to access later, and the Elastic IP won’t change.

Edit the ENI’s security group. Add TCP port 22 from “Anywhere” and save. Your WorkSpace is now SSHable! tail -f /var/log/secure for a good laugh.

Note that if you’re SSHing from a shell, you’ll need to escape the backslash that separates your AD domain from your username, i.e. CORP\\bob rather than CORP\bob.

Disable sudo password prompts

What’s the point of authenticating twice with the same password? Edit /etc/sudoers.d/01-ws-admin-user and change the final ALL to NOPASSWD:ALL.

Enable EPEL

Use amazon-linux-extras to enable EPEL.

sudo amazon-linux-extras install epel

Pull in CentOS repositories

The easiest way to do this is to install docker. Don’t forget to add yourself to the Docker group with usermod -a -G docker $USER. Then copy the CentOS repository files to your WorkSpace.

centos=$(docker run --rm -di centos:7 cat)
sudo docker cp $centos:/etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo
sudo sed -i 's/\$releasever/7/g' /etc/yum.repos.d/CentOS-Base.repo
sudo sed -i 's/\]$/\]\nenabled=0/' /etc/yum.repos.d/CentOS-Base.repo
sudo docker cp $centos:/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 
docker rm -f $centos

Some explanation: $releasever of Amazon Linux is 2, but the compatible CentOS repositories are CentOS 7. So $releasever needs to be hardcoded to 7 in CentOS-Base.repo in order to work.

We also leave these repositories disabled by default to minimize conflicts with Amazon’s own packages. Use them only when you need them by adding --enablerepo= when installing a package, i.e. yum install --enablerepo=extras. Some packages require more obscure dependencies than others, so it's worth having the CentOS repositories handy.

Change your desktop environment

Personally, I find adding xfce and the Numix theme works wonders for making your WorkSpace more pleasing to the eye with very little effort. If you do run xfce with a custom GTK theme like I do, don’t forget to set the theme style under both Settings Manager > Appearance > Style and Settings Manager > Window Manager > Style > Theme.

sudo yum groupinstall -y xfce
sudo yum install -y numix-gtk-theme numix-icon-theme-circle

To switch window managers, edit /etc/pcoip-agent/pcoip-agent.conf and change pcoip.desktop_session from mate to xfce. If you’ve installed a different desktop environment and are wondering what keyword belongs here, check /usr/share/xsessions:

ls /usr/share/xsessions/*.desktop # List available desktop sessions.

Reboot your WorkSpace and you’ll be in your preferred desktop session.

Change your shell

chsh doesn’t work in this realm because of Active Directory. Instead, add yourself to /etc/passwd and modify your shell the good old-fashioned way.

getent passwd $USER | sudo tee -a /etc/passwd

Then edit /etc/passwd and change your shell to your liking.

Set a monospace font

This isn’t really WorkSpace specific, but I came across this issue while configuring my WorkSpace, so here it is anyway.

Not all desktop environments expose the ability to modify your system’s monospace font. In case you have this issue too, create a ~/.fonts.conf with the following XML format, replacing Terminus with the monospace font of your choice.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<match target="pattern">
  <test qual="any" name="family">
    <string>monospace</string>
  </test>
  <edit name="family" mode="assign">
    <string>Terminus</string>
  </edit>
</match>
</fontconfig>

Why not just use EC2?

Your WorkSpace should now be every bit as comfy as a local VM. But you might be wondering why anyone would bother going through all this special configuration when you could just run your own EC2 instance.

The answer is simple: the WorkSpace is cheaper and Just Works. I run the cheapest Amazon WorkSpace, which is 1 vCPU, 2 GB of RAM, 80 GB of root storage and 10 GB of user storage. It runs me $21 a month. The equivalent EC2/EBS storage is $24.23 a month. Why bother?

As for it Just Working, I don’t have to bother with tuning or securing VNC. The WorkSpaces client is fast, secure, and runs on everything — even Linux, if you install it under WINE. The VirtualBox-like automatic desktop resizing is nice too, which is something even NoMachine struggles to pull off. Having messed with other remote clients in the past, I find the WorkSpaces client to be a more seamless and consistent user experience.

With that, hopefully your WorkSpace is set up the way you like it. Happy hacking!