Frequently Asked Questions (FAQ)


How to secure a publicly reachable VM

MAKING THE VIRTUAL MACHINE ITSELF PUBLICLY AVAILABLE IS NOT OFFICIALLY RECOMMENDED.

This is rather atypical as we would have expected that all of you would either use a dedicated setup using only the scripts or the extremely convenient “Thin” server methodology.

What follows is only relevant if you are making our virtual machine image publicly reachable (usually through the “Bridged Adapter” setting in VirtualBox). If you are using a “Thin” server, the steps are still recommended, but not strictly necessary if you trust the “Thin” server operator.

If you use a dedicated setup with only the scripts, the steps are not required.

If you have initialized your virtual machine before April 22, 2020, 10:34 am GMT+2, please open the “Terminal Emulator” and execute the following to set a new password for the “lab” user:

sudo passwd lab

Please set a strong and secure password.

This prevents unwanted logins into the virtual machine using SSH. Please remember that you will have to use the new password everywhere you previously used the builtin standard password “lab”. So you will have to use the new password on the login screen, when using FileZilla, and so on.

Changing the root password is not required because our stock VM image already prohibits root logins.

If you do not wish to use FileZilla or SSH, please consider disabling sshd altogether:

sudo systemctl stop sshd
sudo systemctl disable sshd

On April 22, 2020, 10:34 am GMT+2, I introduced a change that forces users to change the password during the initialization: https://gitlab.com/cler1/ztree-unleashed/-/commit/d3ad254fcb55d93d87373752e66832d5ae718540

If you are the single person using the VM, please consider setting the password to something random and only use public key cryptography: https://debian-administration.org/article/530/SSH_with_authentication_key_instead_of_password

In any case, we recommend using

cd ztree-unleashed
git pull

to always use the latest version of z-Tree unleashed.



Is it possible to reduce the port range?

Yes, change ports3 in line 30 of the file scripts/generate_session.py to something like the following:

ports3 = random.sample(range(50000, 50200), k = n_clients)

Then, only ports 50000-50199 would have to be opened to the public.

Note that this makes port collisions a little bit more likely; but the worst thing that can happen is that you run into occasional difficulties when starting a session or reusing a sessionfile. Also, the ports will be more easily guessable. But that doesn’t matter because we still always have the VNC password (in the URL).

Only ports3 specifies publicly reachable ports. The other ports are all internal. Please do not change ports1 and ports2.



What to do if the browser screen stays black?

To be done.