This is an old revision of the document!
Remote Desktop access
You can set up a remote desktop solution on a local network without having to deal with NAT and firewall/router matters. The VNC protocol is generally better facilitated by Unix/Linux than RDP. Some of the technologies discussed here deal with either protocol.
Notable tech:
• Krdb – Simple configuration by the non-root user, but no access control lists. • AnyDesk – Includes access control system and Windows support. • libvncserver – Long-term recommendation; library for a customized feature solution.
Short-term, the most viable solutions here for FreeBSD are Krfb and Anydesk. The instructions for installing these follow. These are demonstrated on the coco vm.
(Please note that for security reasons, the VNC/RDP ports used here for demonstration will be closed before long.)
Krfb Krfb is specific to KDE. The configuration is relatively straight forward.
In the KDE Application Launcher (lower left of the desktop), browse to Krfb.
Note that you should check the box called Enable Unattended Access if you want others to access the desktop when you are not present. If this is enabled, then also click on Change Unattended Password.
Note in the middle of that pop-up box the “Connection Details” with the IP address, port and password of the machine. That is the information that you give to someone to give them access to your machine.
Unless you explicitly shutdown Desktop Sharing keeps running. Merely closing the Desktop Sharing window does not stop Desktop Sharing.
To stop Desktop Sharing, browse to the Desktop Sharing icon in the system tray (lower right) and right-click the Desktop Sharing icon and select Quit.
To allow Desktop sharing to run at startup, in the KDE Application Launcher (lower left of the desktop), browse to Startup and Shutdown, then click the “+ add” button and enter krfb.
Under Internet, select Krfb.
The above screenshots are from the coco vm. That address resides on a particular local subnet. Substitute that information with what you have for H3 if you want to share it on H3’s subnet.
To test this method using the coco-vm desktop, use the following parameters in your VNC client:
Krfb login to goat’s desktop on coco at System Goats:
Address: coco.systemgoats.com Port: 5900 Unattended Password: (see text message)
This was tested with three concurrent connections, two of which were remote.
Krfb references: https://docs.kde.org/stable5/en/krfb/krfb/krfb-configuration.html https://docs.kde.org/stable5/en/krfb/krfb/index.html
Anydesk For better Windows client accommodations, including multi-user concurrency, chat, access controls, Android support, and file transfer, Anydesk is a worthy consideration.
While installing Anydesk on FreeBSD may be considered a chore, Linux and Windows installations are relatively passive.
What follows are the FreeBSD installation instructions for Anydesk.
First of all, note that Anydesk’s FreeBSD package listing at (https://www.freshports.org/deskutils/anydesk is a mere placeholder. The pkg tool will not actually install Anydesk. However, the package may become available sometime later, so for good measure give pkg a try (as root).
pkg install anydesk
If no installation took place, then proceed to install Anydesk from the ports/source tree as follows:
cd /usr/ports/deskutils/anydesk/ && make install clean
Scroll through the terms of the license and accept it if OK. This software is mostly FOSS with some proprietary tech. It is free for private use, such as non-billable and evaluation uses.
During the installation you will have to approve a few dependencies. If any of these fail to install due to some error, then try installing them separately from their respective port, in /usr/ports.
After the installation completes, the compiled (runnable) binary should reside at /usr/local/bin/anydesk.
Next, the /proc directory needs to be mounted. Do this manually at first:
mount -t procfs proc /proc
To ensure the /proc mount persists after reboot, append to /etc/fstab the following:
proc /proc procfs rw 0 0
The remainder of the configuration is done as the non-root user who wants to share their desktop, in the user’s graphical login environment.
As a non-root user, start Anydesk from the KDE application launcher. (Alternatively, invoke Anydesk from the user’s command-line terminal by entering anydesk). The following graphical window will display:
Configure Anydesk. Click on Unattended Password. Set user login credentials and other parameters as needed. For example, you may want to enable the file manager for remote users. For that, you may also want to enable your machine to be discoverable on then local network.
Given multiple machines with Anydesk, each can operate both as client and server. This provides more features than using another VNC client. For example, you can use two way audio.
Connect one machine to the other by adding it to the address book. Select Address Book in the lower left of the Anydesk window and add the address of a machine, such as the 1 360 326 507 shown in the above screenshot.
Depending on the memory available on the client machine, it may take a minute of two to load the system before its displays.
To allow Anydesktop to run at startup, as with Krfb, in the KDE Application Launcher (lower left of the desktop), browse to Startup and Shutdown, then click the “+ add” button and enter Anydesk.
The above screenshots are from the coco vm here at Systemgoats. You may test this same connection by using a VNC client. Both the Remina and Anydesk clients worked here.
Anydesk login parameters for goat’s desktop on coco at System Goats:
Address: coco.systemgoats.com Port: 7070 Unattended Password: (see text message)
Anydesk references: https://anydesk.com/en/features#access-control https://www.freshports.org/deskutils/anydesk
XRDP xrdp uses Xvnc or X11rdp to interact with the MS RDP protocol. By default, xrdp allows one session per Linux user account, preventing two or more simultaneous logins. There are straight forward workarounds for Linux. (On FreeBSD a connection to xrdp conflicts with Anydesk; stop the process or use different ports.)
Xrdp server installation (as root):
pkg install xrdp
Or build it from its port:
cd /usr/ports/net/xrdp/ && make install clean
Append to /etc/rc.conf the following:
xrdp_enable="YES" xrdp_sesman_enable="YES"
Because xrdp has a default X window desktop environment, such as Gnome, change that to KDE if needed. To do so, edit /usr/local/etc/xrdp/startwm.sh. Note in the configuration for the coco vm these commented and uncommented lines:
#### start desktop environment # exec gnome-session # exec mate-session # exec start-lumina-desktop # exec startxfce4 # exec xterm # exec startplasma-xll exec ck-launch-session startplasma-x11
Configure xrdp for multiple users. Edit the xrdp connection parameters in /usr/local/etc/xrdp/xrdp.ini and define connections such as:
[xrdp1] name=xrdp-session1 lib=libvnc.so username=ask password=ask ip=127.0.0.1 port=-1 delay_ms=2000
[xrdp2] name=xrdp-session2 lib=libvnc.so username=ask password=ask ip=127.0.0.1 port=-1 delay_ms=2000
Install D-Bus (about: https://dbus.freedesktop.org/doc/dbus-launch.1.html ). The software for dbus-x11 was possibly installed already as a dependency. Check:
pkg info -r dbus
Or
pkg install dbus
Append to /etc/rc.conf the following:
dbus_enable="YES"
Start or restart xrdp:
/usr/local/etc/rc.d/xrdp restart
Test the xrdp server using a remote RDP client. Alternatively, in Windows search for “Remote Desktop” and enter the necessary connection parameters.
xrdp login parameters for goat’s desktop on coco at System Goats:
Address: coco.systemgoats.com User: goat Port: 3389
Here is the connection using the Remina client:
Making the second connection…
Xrdp references: https://www.freshports.org/net/xrdp
Security A VPN can afford a common localization of server and client machines. However, this is generally known to be slower for graphical desktops.
Longer term, the network of the VPN should be an isolated subnet if you are issuing login credentials to potentially untrusted clients.
Subnetting should be done internally apart from Zerotier’s emulation, unless you run your own Zerotier nodes. Unless you own and control your nodes, you are using a shared WAN IP address, which makes it more of a hacker target. Additionally, by delegating to an uncontrolled Zerotier node, you authorize a third-party determine what devices can join your network, for better or worse.
The less risky solution, longer term, is to use locally installed VPN software, such as the well known ipSec, OpenVPN, or WireGuard.
Related VPNs on pfsense: https://docs.netgate.com/pfsense/en/latest/vpn/index.html Using ipSec on pfsense: https://www.ceos3c.com/pfsense/pfsense-site-to-site-vpn
VNC clients Krdc: https://apps.kde.org/krdc/ Remina: https://remmina.org/ https://github.com/jose1711/remmina-plugin-anydesk
Other remote desktop solutions libvnc-server: good if you are intent to write your own vnc server. This provides flexibility for unlimited and unusual features. The cost is development time. A complimentary project is called libvnc-client. Given the time commitment, libvnc may be preferable to hacking feature workarounds in other software.
Libvnc-server references: https://www.freshports.org/net/libvncserver/ https://libvnc.github.io/index.html
x11vnc: A libvnc-server derivative. Using here for many years. Accepts multiple simultaneously local clients. Needs polish and a fix for stability issues. More: https://man.freebsd.org/cgi/man.cgi?query=x11vnc&sektion=&manpath=freebsd-release-ports http://www.freebsddiary.org/tightvnc.php https://github.com/LibVNC/x11vnc
x2go: https://wiki.x2go.org – “Multiple users/clients can access a single X2Go Server at the same time, with each user/client having an individual Desktop session by default - however, Desktop sharing (Remote Assistance) is possible, too.” Unlike the client, the server does not appear to have a FreeBSD package or port. Source code here: https://wiki.x2go.org/doku.php/download:source-tarballs
FreeRDP: https://www.freshports.org/net/freerdp
A curiosity – MeshCentral: https://www.meshcommander.com/meshcentral2