Remote Desktop Access¶

You can monitor the VNC service with:

systemctl status vncserver

Although any VNC viewer will work, the latest official TigerVNC viewer can be downloaded here: https://sourceforge.net/projects/tigervnc/files/stable/

Connection Details¶

• To connect on the persistent VNC session on screen :1, add the screen index to your local IP or hostname, e.g. 192.168.0.100:1, which refers to port 5901.
• To connect to a shared desktop session, skip the screen index, e.g. 192.168.0.100, which refers to port 5900.
• Use the default dietpi-software password to authenticate. If you would like to change the password, run sudo tigervncpasswd from the console/terminal.

Shared desktop¶

The shared desktop mode is used to have more than one single VNC viewer connected to the same desktop session. To enable this mode, edit /boot/dietpi.txt, e.g. via nano /boot/dietpi.txt. Change to value 1 the following line:

SOFTWARE_VNCSERVER_SHARE_DESKTOP=1

A running desktop is required for this mode, therefore enable desktop autostart via dietpi-autostart 2, or assure that a local desktop session is active before starting TigerVNC manually.

Resolution settings¶

The following shows an example how to run VNC server on screen :1 by creating a new desktop with 1280x720 resolution by editing /boot/dietpi.txt:

nano /boot/dietpi.txt

and change the following settings:

SOFTWARE_VNCSERVER_WIDTH=1280
SOFTWARE_VNCSERVER_HEIGHT=720
SOFTWARE_VNCSERVER_DEPTH=32
SOFTWARE_VNCSERVER_DISPLAY_INDEX=1

At last restart the service to activate the new settings:

systemctl restart vncserver

TigerVNC is enabled by default to start automatically at boot. Run systemctl disable vncserver to disable this behaviour and systemctl start vncserver to start it manually from console.

To re-enabled TigerVNC autostart, run systemctl enable vncserver, to stop it manually systemctl stop vncserver can be used.

Basics¶

By default DietPi will start a virtual VNC session on boot at screen :1 for user root.
The screen index can be changed via SOFTWARE_VNCSERVER_DISPLAY_INDEX in /boot/dietpi.txt. Logs can be viewed via journalctl -t Xvnc:1 -t vncserver and in /root/.vnc/. When you logout (instead of only closing the VNC Viewer window), the session will exit. Restart it via systemctl restart vncserver.

Shared desktop¶

If you set SOFTWARE_VNCSERVER_SHARE_DESKTOP=1 in /boot/dietpi.txt, RealVNC server will be started on boot in shared desktop mode, attaching to the first found local desktop session.
Run dietpi-autostart 2 to start a local desktop session automatically on boot, which RealVNC can connect to.

RealVNC enterprise subscription¶

If you have an enterprise subscription on RealVNC, you can have virtual VNC sessions spawning automatically on demand per-client connection and closing once the client disconnects. That way no resource-intense X11/desktop session needs to be persistently active on the server to allow VNC connections.
To enable this, after adding your enterprise subscription credentials, do the following:

• systemctl disable --now vncserver disables the persistent virtual VNC session on screen :1.
• systemctl enable --now vncserver-virtuald enables the on demand VNC session daemon.

Although any VNC viewer will work, the latest official RealVNC viewer can be downloaded here: https://www.realvnc.com/en/connect/download/viewer/

Connection details¶

• To connect on the persistent VNC session on screen :1, add the screen index to your local IP or hostname, e.g. 192.168.0.100:1, which refers to port 5901.
• To connect to a shared desktop session, skip the screen index, e.g. 192.168.0.100, which refers to port 5900.
• Use the default dietpi-software password to authenticate. If you would like to change the password, run these commands from the console/terminal:

sudo vncpasswd -virtual
sudo vncpasswd -service

Download the NoMachine client software from:

• URL = https://www.nomachine.com

Once the NoMachine client is installed, and running on your system, you should see a device named DietPi. Execute the following steps:

1. Double click it.
2. Select Yes for Remote host identification has changed.
3. Select Yes for Verify host authenticity.
4. Enter the username root and password dietpi.
5. Select Yes for Do you want NoMachine to create a new display.

You will now be connected to your device.

While the DietPi-Software installation run, if not done yet, you may create an account at the Remote.It web portal: https://app.remote.it/

After the DietPi-Software installation finished, you can register the device at your Remote.It desktop application. For this, retrieve your claim code via:

mawk -F\" '/claim/{print $4}' /etc/remoteit/config.json

Then follow these instructions: https://docs.remote.it/software/device-package/installation#id-3.-claim-and-register-the-device

The VirtualHere server listens on the TCP port 7575 by default for client connections.

The configuration file can be found at:

/opt/virtualhere/config.ini

When doing changes, apply them by restart the service:

systemctl restart virtualhere

The service is started automatically at boot. As systemd service, it can be controlled with the following commands:

systemctl status virtualhere

systemctl start virtualhere

systemctl stop virtualhere

systemctl restart virtualhere

Since VirtualHere runs as systemd service, its logs can be viewed via:

journalctl -u virtualhere

When a new version is available, VirtualHere can be updated by simply reinstalling it:

dietpi-software reinstall 138

The configuration files

• signal.env (signaling server configuration, process name hbbs)
• relay.env (relay server configuration, process name hbbr)
• id_ed25519 (private key file)
• id_ed25519.pub (public key file)

can be found at:

/mnt/dietpi_userdata/rustdesk/

Typically, no changes are necessary within these files.
When doing changes, they are applied by restarting the RustDesk services:

systemctl restart rustdesksignal rustdeskrelay

A new key file pair (id_ed25519, id_ed25519.pub) can be generated via:

/opt/rustdesk/rustdesk-utils

Usage:
    rustdesk-util [command]

Available Commands:
    genkeypair                                   Generate a new keypair
    validatekeypair [public key] [secret key]    Validate an existing keypair
    doctor [rustdesk-server]                     Check for server connection problems

If a RustDesk Server shall be moved to a different system with keeping the original configuration, the following steps can be used:

1. Installation of RustDesk Server on the new system
2. Copying the directory /mnt/dietpi_userdata/rustdesk to the new system
3. Restart of the services or reboot

The services are started automatically at boot. As systemd service, they can be controlled with the following commands:

systemctl status rustdesksignal rustdeskrelay

systemctl start rustdesksignal rustdeskrelay

systemctl stop rustdesksignal rustdeskrelay

systemctl restart rustdesksignal rustdeskrelay

Since RustDesk runs as two systemd services, its logs can be viewed via:

journalctl -u rustdesksignal -u rustdeskrelay

When a new version is available, RustDesk Server can be updated by simply reinstalling it:

dietpi-software reinstall 12

The version info of the installed server versions can be displayed via

/opt/rustdesk/hbbr -V
/opt/rustdesk/hbbs -V

The client configuration is normally done completely in the client user interface and the user do not need to know where they reside.
For special cases the configuration files which the client user interface generates/modifies can be found at:

~/.config/rustdesk/

By default, RustDesk Client uses the public RustDesk server (rs-ny.rustdesk.com).
To use a self-hosted RustDesk Server instead, the server address can be changed via the client’s network settings, as described in the Client installation and setup section below.

When a new version is available, RustDesk Client can be updated by simply reinstalling it:

dietpi-software reinstall 13

The version info of the installed client can be displayed via:

rustdesk --version

By default, the RustDesk Client is configured to use the public RustDesk server. This is defined in the configuration file ~/.config/rustdesk/RustDesk2.toml:

rendezvous_server = 'rs-ny.rustdesk.com:21116'

With this default configuration, the RustDesk Client connects to the public RustDesk relay server on startup. The client ID displayed in the RustDesk window can be shared with others to allow them to connect to your DietPi device.

To connect to a self-hosted RustDesk Server instead of the public server, the client has to be configured to use the hostname resp. IP address of the RustDesk server. Open the RustDesk Client, go to Settings > Network and set the ID server to the hostname or IP address of your self-hosted RustDesk Server, and set the Key to the public key of your RustDesk server (e.g. contents of /mnt/dietpi_userdata/rustdesk/id_ed25519.pub in case of a self-hosted server installed via dietpi-software install 12):

With this configuration, the RustDesk Client attaches to the self-hosted RustDesk Server on startup.
In the case that the user wants to connect to another RustDesk client which is attached to the public RustDesk server, the ID of the other client has to be followed by @public:

Persistent background service

Optionally, the rustdesk systemd service can be enabled to keep a persistent background connection to the self-hosted RustDesk Server. This allows other clients to always initiate remote desktop connections to this DietPi device, even when the RustDesk Client GUI is not open. Note that this is only recommended with a self-hosted server.

systemctl enable --now rustdesk

The service can be controlled with the usual systemctl commands, and its logs can be viewed via:

systemctl status rustdesk
systemctl restart rustdesk
journalctl -u rustdesk