I’ve been very excited by the progress of the OnionJuggler project’s integration into Whonix, which makes administrating an Onion site accessible to individuals without sys admin experience through a TUI. @Patrick @nyxnor
The question remains - how does this user provision and configure Whonix on a VPS, in order to be able to use OnionJuggler? I have a proposal and would love feedback on the design before getting started. In addition to being useful for individuals lacking sys admin experience, the hope with this project is to also provide greater security by reducing user error through an “infrastructure as code” approach.
The first question is whether the VPS should use Qubes-Whonix or Whonix KVM. Any recommendations on this are greatly appreciated. Neither option is particularly documented. The following assumes Whonix KVM, based on this comment made in Nov '20:
Can Qubes-Whonix use it as server OS for hosting Tor onion hidden service?
If you mean through a remote server (VPS or root server): currently usability for this is still very lacking at time of writing.
- SSH into Qubes dom0 is hard
- no CLI version
- no documentation on how to use with CLI on a remote server as far as I am aware off
With the work on qubes-remote-support, does this change anything?
The User Experience I am looking for is something like this:
- Prior: use cryptocurrency to anonymously buy a VPS
- use GUI to provision Debian on the VPS
- use GUI to distromorph Debian to Kicksecure, then configure Whonix KVM on Kicksecure
- use GUI to launch the Onion Juggler TUI window
- use GUI to sync local static website with VPS
I envision a docs website that would guide the user through this process. Perhaps the best way of sharing the proposed design is a description of each envisioned button:
Button #1: Create VPS
‘Create VPS’ links to a documentation website, which provides a step by step guide to provision a Debian VPS at several cloud providers that accept cryptocurrencies, such as:
- RamNode costs about $5 a month for a server with 1GB of memory and two virtual CPU (vCPU) cores. Only accepts Bitcoin.
- NiceVPS costs about €14.99 a month for a server with 1GB of memory and one vCPU core. Accepts Monero and Zcash.
- Cinfu costs about $4.79 a month for a server with 2GB of memory and one vCPU core. Supports Monero and Zcash.
- PiVPS costs about $14.97 a month for a server with 1GB of memory and one vCPU core. Supports Monero and Zcash.
- SecureDragon costs about $4.99 a month for a server with 1GB of memory and two vCPU cores. Only accepts Bitcoin.
Ideally this button would actually do the provisioning with a technology like Terraform, though from what I can tell all of the Terraform Providers, which use the cloud provider API, don’t accept cryptocurrencies. All major cloud providers—AWS, Google Cloud, Microsoft Azure, Alibaba, and so on—require a credit card before approving your account. I haven’t looked into this closely.
Button #2: Configure Whonix
‘Configure Whonix’ takes a Debian VPS and uses configuration management technology to arrive at Kicksecure running Whonix via KVM.
I think that Ansible is the right choice for how this is implemented. It is trusted by the Freedom of Press Foundation (see their GitHub, as a new forum member I can’t hyperlink) for configuration management. In my view, the main benefit of Ansible (versus shell scripts) is that it can be ‘idempotent’ - it describes an end state of the system, so no matter how many times the user presses the GUI button, nothing changes if the VPS is already at the desired end state.
From “UNIX and Linux System Administration Handbook”:
The traditional approach to sysadmin automation is an intricate complex of home-grown shell scripts supplemented by ad hoc fire fighting when scripts fail. This scheme works about as well as you might expect. Over time, systems managed in this way usually degenerate into a chaotic wreckage of package versions and configurations that can’t be reliably reproduced. It’s sometimes called the snowflake model of system administration because no two systems are ever alike.
An Ansible Playbook would be maintained which
- Distromorphs Debian to Kicksecure
- Configures Whonix KVM as per the Wiki
- Configures an automated update mechanism
If Qubes-Whonix was the direction, this button would use Salt rather than Ansible.
The goal is that the user never needs to interact with a CLI in order for the VPS to be properly configured and up to date.
Button #3: Onion Juggler
‘Onion Juggler’ establishes an SSH connection and launches the Onion Juggler TUI in Whonix-Workstation.
Button #4: Sync Static Website
‘Sync Static Website’ will prompt the user for the directory location of the static website, establish an SSH connection, and syncs the local directory with the files served by Onion Juggler on the VPS.
The documentation also provides advice on how the user can create a static website. The most user friendly option is the desktop app Publii, though any Static Site Generator is possible of course.
Button #5: Settings
Any settings that need to be modified can be done in Settings: local SSH key location, local static website directory location, etc.
What do people think of a project like this? Is there a better approach? Any feedback is very appreciated!