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.
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
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.
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
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
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
$releasever of Amazon Linux is
2, but the compatible CentOS repositories are CentOS 7. So
$releasever needs to be hardcoded to
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
xfce. If you’ve installed a different desktop environment and are wondering what keyword belongs here, check
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
/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!