Sometimes I find myself wishing that I have a Linux desktop that I can access remotely. Whilst having a cloud-based desktop is not new, it is, however, a bit expensive when used sparingly. If, however, you prefer working on the cloud-based desktop most of the time, then it becomes affordable (Shells.com offer one at $4.95/mo for 10 hours of use, Microsoft and Amazon have similar products, though not sure of their pricing).
Ponying up $4.95/mo for 10 hours of use for a single purpose subscription is not really an option for me. I do have Linux servers running 24x7 for the same price — currently have one running the kids’ Minecraft server and works as WireGuard VPN server at the same time. Heck, I have another server on Oracle that is on the free-tier, but this one is exclusively running WireGuard VPN.
I decided to give VNC on the Minecraft server a try and see if it’ll work. So I went off armed with the guide, “How to Install and Configure VNC on Ubuntu 20.04”, written by Mark Drake. It does not take you long to do the install and configuration.
With the Minecraft server now running VNC, the next step is to test it. On the iPad Pro, I use Screens as my Remote Desktop app. I use it to access my Raspberry Pi desktop when I need to run SD Copier to clone the main system. I also use it when rclone.org requires a browser to generate the access tokens.
The guide protects the VNC by limiting access to localhost, i.e., you cannot connect directly to the server from the internet (besides, the ports are also blocked). First, I tried connecting to the server via the WireGuard VPN and then get Screens to connect, but that failed. Yeah, I know this was not part of Mark’s guide — tried it, even with the firewall deactivated. No dice.
With the firewall up and ports blocked again, I configured Screens to establish an SSH tunnel (as written on Mark’s guide) and then connect VNC. Copying the SSH keys from the MacBook Pro and setting Screens to connect to localhost got it working. The desktop appeared on my iPad Pro! Not bad.
A quick install of a lightweight browser, Midori, completed the exercise. A couple of reboots made sure that everything is automatically launched on boot. Now my cloud desktop is up and running.
Anyway, I prefer working locally, i.e., not on the cloud (yeah, I don’t like using online productivity suites like Google Docs or Office365), and on the device (not a fan of Chromebooks, too). When your internet connection is expensive and unreliable, then you’d understand.