# Remote control on Linux ## Console For console control of a Linux machine `ssh` is **the** way to go. This is what we've been using up until now and should be self evident to you. To be able to multi task and have long running processes on a remote server you can use `tmux` or `screen`. Again, nothing new here but let's try the following. I installed a Debian 11 machine with graphical environment and I can log in over `ssh` as follows. It shows a running `X11` session which is the desktop environment I'm using on the virtual machine. ```bash ➜ ~ git:(master) ✗ ssh waldek@192.168.0.195 waldek@192.168.0.195's password: Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Mon Sep 13 15:11:41 2021 from 192.168.0.16 waldek@debian:~$ ps a PID TTY STAT TIME COMMAND 611 tty1 Ss+ 0:00 /sbin/agetty -o -p -- \u --noclear tty1 linux 1142 tty7 Ssl+ 0:07 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitc 1459 pts/1 Ss+ 0:00 bash 2259 pts/0 Ss 0:00 -bash 2262 pts/0 R+ 0:00 ps a waldek@debian:~$ ``` We can use all console applications we know, such as `htop` and `vim` but what about the *graphical* ones? Let's try and see what we can do. `firefox` is installed on the remote machine so I *should* be able to launch it. ```bash waldek@debian:~$ firefox (firefox-esr:2275): Gtk-WARNING **: 15:14:42.460: Locale not supported by C library. Using the fallback 'C' locale. Error: no DISPLAY environment variable specified waldek@debian:~$ ``` What is this `DISPLAY` variable? On the ssh connection we can have a look at how it's set with the following command. It seems to be *empty* ```bash waldek@debian:~$ echo $DISPLAY waldek@debian:~$ ``` On the graphical session we do the same and get the following. ```bash waldek@debian:~$ echo $DISPLAY :0 waldek@debian:~$ ``` OK, there seems to a difference between both terminals here. What would happen if we manually set the `DISPLAY` in the `ssh` connection? Let's try this out. ```bash waldek@debian:~$ export DISPLAY=:0 waldek@debian:~$ firefox (firefox-esr:2298): Gtk-WARNING **: 15:19:37.681: Locale not supported by C library. Using the fallback 'C' locale. (/usr/lib/firefox-esr/firefox-esr:2348): Gtk-WARNING **: 15:19:38.329: Locale not supported by C library. Using the fallback 'C' locale. (/usr/lib/firefox-esr/firefox-esr:2391): Gtk-WARNING **: 15:19:38.818: Locale not supported by C library. Using the fallback 'C' locale. (/usr/lib/firefox-esr/firefox-esr:2414): Gtk-WARNING **: 15:19:39.103: Locale not supported by C library. Using the fallback 'C' locale. ``` You should see `firefox` open up on the graphical desktop! The `man X` pages explain this variable as follows: ```bash DISPLAY NAMES From the user's perspective, every X server has a display name of the form: hostname:displaynumber.screennumber This information is used by the application to determine how it should connect to the server and which screen it should use by default (on displays with multiple monitors): hostname The hostname specifies the name of the machine to which the display is physically connected. If the hostname is not given, the most efficient way of communicating to a server on the same machine will be used. displaynumber The phrase "display" is usually used to refer to a collection of monitors that share a common set of input devices (keyboard, mouse, tablet, etc.). Most workstations tend to only have one display. Larger, multi-user systems, however, frequently have several displays so that more than one person can be doing graphics work at once. To avoid confusion, each display on a machine is assigned a display number (beginning at 0) when the X server for that display is started. The display number must always be given in a display name. screennumber Some displays share their input devices among two or more monitors. These may be configured as a sin- gle logical screen, which allows windows to move across screens, or as individual screens, each with their own set of windows. If configured such that each monitor has its own set of windows, each screen is assigned a screen number (beginning at 0) when the X server for that display is started. If the screen number is not given, screen 0 will be used. ``` ## X11 over SSH While opening up a graphical program onto the remote screen can be handy, most often you'll want to actually interact with the program on your local screen. This can be achieved via *Xforwarding* over `ssh`. Let's dive into the trusty `man sshd_config` pages and look for all stuff related to `X11`. ```bash X11DisplayOffset Specifies the first display number available for sshd(8)'s X11 forwarding. This prevents sshd from in- terfering with real X11 servers. The default is 10. X11Forwarding Specifies whether X11 forwarding is permitted. The argument must be yes or no. The default is no. When X11 forwarding is enabled, there may be additional exposure to the server and to client displays if the sshd(8) proxy display is configured to listen on the wildcard address (see X11UseLocalhost), though this is not the default. Additionally, the authentication spoofing and authentication data verification and substitution occur on the client side. The security risk of using X11 forwarding is that the client's X11 display server may be exposed to attack when the SSH client requests forwarding (see the warnings for ForwardX11 in ssh_config(5)). A system administrator may have a stance in which they want to protect clients that may expose themselves to attack by unwittingly requesting X11 forwarding, which can warrant a no setting. Note that disabling X11 forwarding does not prevent users from forwarding X11 traffic, as users can al- ways install their own forwarders. X11UseLocalhost Specifies whether sshd(8) should bind the X11 forwarding server to the loopback address or to the wild- card address. By default, sshd binds the forwarding server to the loopback address and sets the hostname part of the DISPLAY environment variable to localhost. This prevents remote hosts from connecting to the proxy display. However, some older X11 clients may not function with this configuration. X11UseLocalhost may be set to no to specify that the forwarding server should be bound to the wildcard address. The argument must be yes or no. The default is yes. XAuthLocation Specifies the full pathname of the xauth(1) program, or none to not use one. The default is /usr/bin/xauth. ``` We'll need to make sure a few setting are set in remote servers sshd configuration file, restart the server and try to launch a graphical application. ```bash waldek@debian:~$ grep "X11" /etc/ssh/sshd_config X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes # X11Forwarding no waldek@debian:~$ ``` By default the forwarding seems to be on so why can't we see the firefox locally? Turn out that the ssh *client* needs to ask for a fowarded connection to have it work out of the box. A quick read of the `man ssh` pages gives us this explication. ```bash -X Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file. X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user's X authorization database) can access the local X11 display through the for- warded connection. An attacker may then be able to perform activities such as keystroke monitoring. For this reason, X11 forwarding is subjected to X11 SECURITY extension restrictions by default. Please refer to the ssh -Y option and the ForwardX11Trusted directive in ssh_config(5) for more information. (Debian-specific: X11 forwarding is not subjected to X11 SECURITY extension restrictions by default, be- cause too many programs currently crash in this mode. Set the ForwardX11Trusted option to "no" to re- store the upstream behaviour. This may change in future depending on client-side improvements.) -x Disables X11 forwarding. -Y Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls. (Debian-specific: In the default configuration, this option is equivalent to -X, since ForwardX11Trusted defaults to "yes" as described above. Set the ForwardX11Trusted option to "no" to restore the upstream behaviour. This may change in future depending on client-side improvements.) ``` Let's add the `-X` flag and see how it behaves now. A firefox window should open up on your local screen! ```bash ➜ ~ git:(master) ✗ ssh -X waldek@192.168.0.195 waldek@192.168.0.195's password: Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Mon Sep 13 15:29:56 2021 from 192.168.0.16 waldek@debian:~$ echo $DISPLAY localhost:10.0 waldek@debian:~$ firefox (firefox-esr:3415): Gtk-WARNING **: 15:48:38.880: Locale not supported by C library. Using the fallback 'C' locale. (/usr/lib/firefox-esr/firefox-esr:3461): Gtk-WARNING **: 15:48:39.464: Locale not supported by C library. Using the fallback 'C' locale. (/usr/lib/firefox-esr/firefox-esr:3508): Gtk-WARNING **: 15:48:40.522: Locale not supported by C library. Using the fallback 'C' locale. (/usr/lib/firefox-esr/firefox-esr:3540): Gtk-WARNING **: 15:48:41.772: Locale not supported by C library. Using the fallback 'C' locale. ``` ## RDP While Xforwarding over `ssh` is super handy for single applications, it becomes tricky to expose a full desktop environment over it. A great alternative is the [Remote Desktop Protocol](https://en.wikipedia.org/wiki/Remote_Desktop_Protocol) which is a proprietary protocol by Microsoft. There are open source alternatives but RDP works pretty well out of the box on Linux and Windows 10 comes with a client installed by default. This makes it a good go to candidate for quick connections. On a clean Debian you install the `xrdp` package. ``` waldek@debian:~$ sudo apt install xrdp Reading package lists... Done Building dependency tree... Done Reading state information... Done xrdp is already the newest version (0.9.12-1.1). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. waldek@debian:~$ sudo systemctl status xrdp --no-pager ● xrdp.service - xrdp daemon Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2021-09-13 15:34:13 CEST; 37min ago Docs: man:xrdp(8) man:xrdp.ini(5) Main PID: 7020 (xrdp) Tasks: 1 (limit: 4577) Memory: 816.0K CPU: 3.542s CGroup: /system.slice/xrdp.service └─7020 /usr/sbin/xrdp Sep 13 16:03:52 debian xrdp[20045]: (20045)(140028929824576)[INFO ] xrdp_wm_log_msg: login successful for display 11 Sep 13 16:03:52 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] xrdp_wm_log_msg: started connecting Sep 13 16:03:52 debian xrdp[20045]: (20045)(140028929824576)[INFO ] lib_mod_log_peer: xrdp_pid=20045 connected to…rt=52421 Sep 13 16:03:52 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] xrdp_wm_log_msg: connected ok Sep 13 16:03:52 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] xrdp_mm_connect_chansrv: chansrv connect successful Sep 13 16:03:52 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] Closed socket 16 (AF_INET6 ::1 port 55722) Sep 13 16:09:25 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] Closed socket 12 (AF_INET6 ::ffff:192.168.0.2…rt 3389) Sep 13 16:09:25 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] xrdp_mm_module_cleanup Sep 13 16:09:25 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] Closed socket 17 (AF_UNIX) Sep 13 16:09:25 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] Closed socket 18 (AF_UNIX) Hint: Some lines were ellipsized, use -l to show in full. waldek@debian:~$ ``` On your Windows client you can connect to machine and start a session. ![RDP client windows](./assets/rdp_windows.png) On Linux `remmina` is a good all around client for `RDP`, `ssh` and `VNC` connections. If you're running `GNOME` there is a high chance you'll get the following message. ![gnome error](./assets/gnome_error.png) There is not much you can do about this and your best bet is to move to `xfce4` as desktop environment. You can install both side by side and use gnome when sitting at the physical machine, and xfce4 over RDP. The easiest way to *add* xfce4 to an existing installation is via `sudo tasksel`. To set your default session you can do the following (tab complete works here!). ```bash waldek@debianremote:~$ sudo update-alternatives --config x-session-manager There are 3 choices for the alternative x-session-manager (providing /usr/bin/x-session-manager). Selection Path Priority Status ------------------------------------------------------------ 0 /usr/bin/gnome-session 50 auto mode * 1 /usr/bin/gnome-session 50 manual mode 2 /usr/bin/startxfce4 50 manual mode 3 /usr/bin/xfce4-session 40 manual mode Press to keep the current choice[*], or type selection number: 2 update-alternatives: using /usr/bin/startxfce4 to provide /usr/bin/x-session-manager (x-session-manager) in manual mode waldek@debianremote:~$ sudo systemctl restart lightdm.service waldek@debianremote:~$ ``` Try to get an RDP session going and once you're logged in, try to run a parallel session via the lightdm display manager. You'll log in but will get *kicked out* almost immediately. This is because by default you can't have two sessions running at the same time on the same computer. Try to connect from a different station to the same session again over RDP. You'll get to log in, but the original one will be cut off. This is the expected behavior, so not a bug, more of a feature! Your session will stay running so you can disconnect and reconnect from a different location later. ## VNC ### Remote helping via x11vnc If we need to connect to an running session to help out, or take over, the control of a Linux machine we can use `x11vnc` to do this. This is a program that can expose *any* running screen over vnc, with or without a password! In a terminal either via the virtual machine, or via ssh, you execute the following commands. A vnc server is now running and you can connect to it with remmina or vncviewer. As long as this x11vnc process is running we can connect to it. ```bash waldek@debianremote:~$ sudo apt install x11vnc Reading package lists... Done Building dependency tree... Done Reading state information... Done x11vnc is already the newest version (0.9.16-7). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. waldek@debianremote:~$ x11vnc -display :0 ############################################################### #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@# #@ @# #@ ** WARNING ** WARNING ** WARNING ** WARNING ** @# #@ @# #@ YOU ARE RUNNING X11VNC WITHOUT A PASSWORD!! @# #@ @# #@ This means anyone with network access to this computer @# #@ may be able to view and control your desktop. @# #@ @# #@ >>> If you did not mean to do this Press CTRL-C now!! <<< @# #@ @# #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@# #@ @# #@ You can create an x11vnc password file by running: @# #@ @# #@ x11vnc -storepasswd password /path/to/passfile @# #@ or x11vnc -storepasswd /path/to/passfile @# #@ or x11vnc -storepasswd @# #@ @# #@ (the last one will use ~/.vnc/passwd) @# #@ @# #@ and then starting x11vnc via: @# #@ @# #@ x11vnc -rfbauth /path/to/passfile @# #@ @# #@ an existing ~/.vnc/passwd file from another VNC @# #@ application will work fine too. @# #@ @# #@ You can also use the -passwdfile or -passwd options. @# #@ (note -passwd is unsafe if local users are not trusted) @# #@ @# #@ Make sure any -rfbauth and -passwdfile password files @# #@ cannot be read by untrusted users. @# #@ @# #@ Use x11vnc -usepw to automatically use your @# #@ ~/.vnc/passwd or ~/.vnc/passwdfile password files. @# #@ (and prompt you to create ~/.vnc/passwd if neither @# #@ file exists.) Under -usepw, x11vnc will exit if it @# #@ cannot find a password to use. @# #@ @# #@ @# #@ Even with a password, the subsequent VNC traffic is @# #@ sent in the clear. Consider tunnelling via ssh(1): @# #@ @# #@ http://www.karlrunge.com/x11vnc/#tunnelling @# #@ @# #@ Or using the x11vnc SSL options: -ssl and -stunnel @# #@ @# #@ Please Read the documentation for more info about @# #@ passwords, security, and encryption. @# #@ @# #@ http://www.karlrunge.com/x11vnc/faq.html#faq-passwd @# #@ @# #@ To disable this warning use the -nopw option, or put @# #@ 'nopw' on a line in your ~/.x11vncrc file. @# #@ @# #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@# ############################################################### 13/09/2021 20:47:13 x11vnc version: 0.9.16 lastmod: 2019-01-05 pid: 14610 13/09/2021 20:47:13 Using X display :0 13/09/2021 20:47:13 rootwin: 0x532 reswin: 0x2e00001 dpy: 0xbfe738d0 13/09/2021 20:47:13 13/09/2021 20:47:13 ------------------ USEFUL INFORMATION ------------------ 13/09/2021 20:47:13 X DAMAGE available on display, using it for polling hints. 13/09/2021 20:47:13 To disable this behavior use: '-noxdamage' 13/09/2021 20:47:13 13/09/2021 20:47:13 Most compositing window managers like 'compiz' or 'beryl' 13/09/2021 20:47:13 cause X DAMAGE to fail, and so you may not see any screen 13/09/2021 20:47:13 updates via VNC. Either disable 'compiz' (recommended) or 13/09/2021 20:47:13 supply the x11vnc '-noxdamage' command line option. 13/09/2021 20:47:13 13/09/2021 20:47:13 Wireframing: -wireframe mode is in effect for window moves. 13/09/2021 20:47:13 If this yields undesired behavior (poor response, painting 13/09/2021 20:47:13 errors, etc) it may be disabled: 13/09/2021 20:47:13 - use '-nowf' to disable wireframing completely. 13/09/2021 20:47:13 - use '-nowcr' to disable the Copy Rectangle after the 13/09/2021 20:47:13 moved window is released in the new position. 13/09/2021 20:47:13 Also see the -help entry for tuning parameters. 13/09/2021 20:47:13 You can press 3 Alt_L's (Left "Alt" key) in a row to 13/09/2021 20:47:13 repaint the screen, also see the -fixscreen option for 13/09/2021 20:47:13 periodic repaints. 13/09/2021 20:47:13 13/09/2021 20:47:13 XFIXES available on display, resetting cursor mode 13/09/2021 20:47:13 to: '-cursor most'. 13/09/2021 20:47:13 to disable this behavior use: '-cursor arrow' 13/09/2021 20:47:13 or '-noxfixes'. 13/09/2021 20:47:13 using XFIXES for cursor drawing. 13/09/2021 20:47:13 GrabServer control via XTEST. 13/09/2021 20:47:13 13/09/2021 20:47:13 Scroll Detection: -scrollcopyrect mode is in effect to 13/09/2021 20:47:13 use RECORD extension to try to detect scrolling windows 13/09/2021 20:47:13 (induced by either user keystroke or mouse input). 13/09/2021 20:47:13 If this yields undesired behavior (poor response, painting 13/09/2021 20:47:13 errors, etc) it may be disabled via: '-noscr' 13/09/2021 20:47:13 Also see the -help entry for tuning parameters. 13/09/2021 20:47:13 You can press 3 Alt_L's (Left "Alt" key) in a row to 13/09/2021 20:47:13 repaint the screen, also see the -fixscreen option for 13/09/2021 20:47:13 periodic repaints. 13/09/2021 20:47:13 13/09/2021 20:47:13 XKEYBOARD: 13/09/2021 20:47:13 Switching to -xkb mode to recover these keysyms: 13/09/2021 20:47:13 xkb noxkb Keysym ("X" means present) 13/09/2021 20:47:13 --- ----- ----------------------------- 13/09/2021 20:47:13 X 0x40 at 13/09/2021 20:47:13 X 0x23 numbersign 13/09/2021 20:47:13 X 0x5b bracketleft 13/09/2021 20:47:13 X 0x5d bracketright 13/09/2021 20:47:13 X 0x7b braceleft 13/09/2021 20:47:13 X 0x7d braceright 13/09/2021 20:47:13 X 0x7c bar 13/09/2021 20:47:13 X 0x5c backslash 13/09/2021 20:47:13 13/09/2021 20:47:13 If this makes the key mapping worse you can 13/09/2021 20:47:13 disable it with the "-noxkb" option. 13/09/2021 20:47:13 13/09/2021 20:47:13 13/09/2021 20:47:13 X FBPM extension not supported. 13/09/2021 20:47:13 X display is capable of DPMS. 13/09/2021 20:47:13 -------------------------------------------------------- 13/09/2021 20:47:13 13/09/2021 20:47:13 Default visual ID: 0x21 13/09/2021 20:47:13 Read initial data from X display into framebuffer. 13/09/2021 20:47:13 initialize_screen: fb_depth/fb_bpp/fb_Bpl 24/32/3200 13/09/2021 20:47:13 13/09/2021 20:47:13 X display :0 is 32bpp depth=24 true color 13/09/2021 20:47:13 13/09/2021 20:47:13 Autoprobing TCP port 13/09/2021 20:47:13 Autoprobing selected TCP port 5901 13/09/2021 20:47:13 Autoprobing TCP6 port 13/09/2021 20:47:13 Autoprobing selected TCP6 port 5900 13/09/2021 20:47:13 Listening also on IPv6 port 5901 (socket 10) 13/09/2021 20:47:13 13/09/2021 20:47:13 Xinerama is present and active (e.g. multi-head). 13/09/2021 20:47:13 Xinerama: number of sub-screens: 1 13/09/2021 20:47:13 Xinerama: no blackouts needed (only one sub-screen) 13/09/2021 20:47:13 13/09/2021 20:47:13 fb read rate: 1355 MB/sec 13/09/2021 20:47:13 fast read: reset -wait ms to: 10 13/09/2021 20:47:13 fast read: reset -defer ms to: 10 13/09/2021 20:47:13 The X server says there are 10 mouse buttons. 13/09/2021 20:47:13 screen setup finished. 13/09/2021 20:47:13 13/09/2021 20:47:13 WARNING: You are running x11vnc WITHOUT a password. See 13/09/2021 20:47:13 WARNING: the warning message printed above for more info. 13/09/2021 20:47:13 The VNC desktop is: debianremote:1 PORT=5901 ****************************************************************************** Have you tried the x11vnc '-ncache' VNC client-side pixel caching feature yet? The scheme stores pixel data offscreen on the VNC viewer side for faster retrieval. It should work with any VNC viewer. Try it by running: x11vnc -ncache 10 ... One can also add -ncache_cr for smooth 'copyrect' window motion. More info: http://www.karlrunge.com/x11vnc/faq.html#faq-client-caching ``` You can combine both RDP and x11vnc as follows. First you have to find out how the display of RDP is referenced. The you create the x11vnc process and connect to it. ```bash waldek@debianremote:~$ ps aux | grep xorgxrdp waldek 3516 0.2 3.0 664264 118116 ? Sl 20:53 0:02 /usr/lib/xorg/Xorg :10 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log waldek 4333 0.0 0.0 6152 716 pts/0 S+ 21:11 0:00 grep xorgxrdp waldek@debianremote:~$ x11vnc -display :10 ``` On a different machine you run the following. ```bash vncviewer 192.168.0.239:0 ``` You probably realize this is super insecure so we should tunnel it over ssh! Luckily this is quite easy to do. We need to add `-allow localhost` to the `x11vnc` command, and then use the `-via` argument with `vncviewer`. Both lines are noted below. ```bash waldek@debianremote:~$ x11vnc -display :0 -allow localhost ``` ```bash vncviewer -via waldek@192.168.0.239 localhost:0 ``` ### Exposing the lightdm login screen We can expose the actual login screen of lightdm over vnc to offer RDP like functionality but without the restrictions. To do this we need to set the `-auth` flag of `x11vnc` to the `.Xauthority` file of `lightdm`. On most disto's this can be found at `/var/lib/lightdm/.Xauthority`. Because the login session runs as root we need to start the x11vnc as root as well. You should limit to localhost for security reasons! If you want the tunnel vnc process to keep running after you disconnect you should add the `-forever` argument together with the `-loop` one. If you want more than one client to connect you can add the `-shared` argument. Together with password for actual users and viewers the can become quite powerful! ```bash x11vnc -rfbauth /etc/vncpasswd -auth /var/lib/lightdm/.Xauthority -display :0 -allow localhost -forever -loop -shared ``` Multiple users can now connect to the same session and to control the session they need a password. This password can be set with the `vncpasswd` program. You can make this into a systemd service to start at boot if you want!