Realvnc Wiki

[Kassim Bisaillon]

I have realvnc-vnc-server installed on both the Pi and the Laptop. Both are the same version (though I understand that one is a .deb package - though looking at the PKGBUILD on Arch, it uses the .deb package anyway).

The connection to my laptop insists on a home subscription, which only provides a cloud connection. Not ideal for a home network. However, a direct connection with the AUR package requires the enterprise license (attempting to connect via the IP address results in a connection refused message).

Now, on the Pi I had to manually enable the vnc server using raspi-config, which suggests that some other configuration (firewall etc) is being modified, but I have no idea what and my GoogleFu isn't helping on this.

I prefer not to switch from realvnc since it is working sweet on the Pi, and I prefer not to have different viewers. I tried tigervnc server with realvnc viewer (this was a while ago) and had no joy at all.

EDIT: The only difference I can see between the Pi and the Laptop is the blue banner at the bottom of the server window. On the Pi it states "Non-commercial use only. Download VNC Viewer and get connected", whilst on the laptop it says "Non-commercial use only. Find out more about commercial subscriptions"

I'd suggest that you start by comparing the installed package versions on your laptop and desktop, from there check for any changes in configuration files that might be places in /etc and from there any configuration files in your home directory.

Edit2:
You might also want to list all files owned by the package in the RPi and see if there is any extra file that might resemble a license or agreement or something that will allow a bit more functionality for personal use.

That said, unless you really require some functionality provided by realvnc I'd say do give tigervnc a new try, recent versions have been working very smoothly for me, at least on x86, and you will not have the licensing headaches of realvnc.

As it happens, I've returned to tigervnc, and whilst i haven't got it working properly yet, I do have it working'ish as a server on both the laptop and the pi. It needs configuring on both (hence the "'ish") to launch an xsession, but progress has been made, thank you.

I tried with tigervnc first. TigerVNC - ArchWiki
IIRC I ONLY ran this (arch wiki) first and actually got it to work (I connected and got to the sddm login screen, sharing the screen with my actual monitor), but I cant remember HOW, because after I did that I followed this Install VNC on Manjaro for Remote Access and that screwed everything up. Sure, I can log in with a vlc client, but when I try to physically log in to my computer, the loading screen freezes and I have to disable the vncserver service and reboot my computer.

yeah, my bad, but I have tried that too, I edited my above answer but its prob better to reply here. I tried changing the :1=USERNAME to :2=USERNAME but if I do that, the computer freezes when I try to log in physically.

On the system (where you created the ssh-keyfile - your workstation) connect to the system using ssh and supply the identify file to be used - and specify the port mapping between your system and the remote system

I wrote this before seeing your latest post. Thank you so much for taking your time helping me, I really appreciate it and will deep dive into what you are typing. I think I have tried everything except creating a key, I was going to do that further down the line after deciding what to use. But still THANK YOU!

With this, you can boot the computer and access with a vnc-viewer getting the sddm login screen. You will take over the session at your computer so if you are already logged in, your vnc-viewer will log in to exactly that, while you still can control your computer physically ofc, you just see what the vnc session is doing live on the screen.
Naturally you can have it sleeping just like we discussed earlier, connecting with ssh, enabling the service, vnc:ing and then disabling the service again.
But this is the only way I found not interfering with your ability to log in physically to your computer while having vncserver running simultaniously.

Since the VNC Server (TigerVNC) configuration is the same on most Linux distributions and only the installation method differ, this wiki is targeting: OpenSUSE, Fedora, CentOS, RHEL, Debian, Mageia, Void Linux, Arch Linux, Manjaro and FreeBSD (in order to be useful for more people)

On Linux (on a classic machine or a screen less server) there are multiple (opensource) possibility for a VNC server such as TightVNC, TigerVNC and TurboVNC (this is a non exhaustive list, this guide will be using the native version of TigerVNC):

VNC server can be started/stopped with the following commands; After starting it you can connect to your server with any VNC client to server-ip:used-port (note that you may probably need to open the used port on the firewall)

OpenSSL and GnuTLS are two main application/library of most Linux system, updating them manually may introduce security issues as they will not be updated automatically anymore, we can limit that side negative effect by using a custom version just for our purpose (TigerVNC).

While using KDE with TigerVNC server; when stopping/starting the server several times, some X applications remain running, probably related to this systemd issue, to fix that the following script can be used to stop the server (can be used on the systemd service config file as well), and ps aux sort grep USER-NAME grep -v '\[' command can be used to check if something is still running after stopping the server.

If the server needs to be exposed to the internet, note that VNC Server can be easily discovered with an nmap scan (nmap -sV -sC TARGET-IP), VNC protocol need to announce itself and thus without creating a custom version of the server and client there is not much than can be done to obfuscate a VNC server in the case of a global internet exposure.

First switch the zone config ( wiki.ipfire.org - Zone Configuration ) for the zone that you want use in the vm to bridge. (This will enable the ability to add a virtiual nic from qemu to this zone via virtmanager.)
After this run virtmanager and connect to the IPFire to create/manage virtal machines.

I have set up a connection from desktop to IPFire, but when I try adding a virtual NIC, I get a message, to the effect, that it is not supported by the connection. Uncertain whether that constraint is in openSUSE or IPFire.

But in my opinion you should focus on the solution suggested by arne_f.
That syntax only works well for me on an emulated 32-bit operating system, has many limitations and is complicated to adapt to your needs.
I abandoned her. The system suggested by arne_f looks great to me. The machines you create with libvirt remain fully installed in IpFire and you can launch them from the IpFire shell with

There appear to be too many configuration differences for virtualisation between openSUSE and IPFire. It is not worth my time sorting it out. Reinstallation of IPFire is on my agenda, for a later date.

Remote administration of any system should be considered a potential anonymity hazard, since it is not under the user's physical protection and could be compromised. All activities, all programs, everything should be assumed to be monitored by the host of the server (VPS, dedicated server, etc.).

The Tor software does not support UDP. The feature request UDP over Tor was created in 2013 and closed as won't fix by upstream, The Tor Project in 2018. It is therefore highly unlikely that the UDP over Tor feature will ever be implemented. This is unspecific to Whonix.

It is possible to remotely administer any operating system with GNU/Linux by using the Remmina desktop client. Remmina supports multiple network protocols, including RDP, VNC, SPICE, NX, XDMCP, SSH and EXEC. For an overview of Remmina features, see here.

Note: If Tor does not connect after completing all these steps, then a user mistake is the most likely explanation. Recheck /usr/local/etc/torrc.d/50_user.conf and repeat the steps outlined in the sections above. If Tor then connects successfully, all the necessary changes have been made.

Note: If no changes have yet been made to Whonix Firewall Settings, then the Whonix User Firewall Settings File /etc/whonix_firewall.d/50_user.conf appears empty (because it does not exist). This is expected.

The Whonix Global Firewall Settings File /etc/whonix_firewall.d/30_whonix_workstation_default.conf contains default settings and explanatory comments about their purpose. By default, the file is opened read-only and is not meant to be directly edited. Below, it is recommended to open the file without root rights. The file contains an explanatory comment on how to change firewall settings.

This is because x2go uses SSH. x2go might be incompatible with SSH hardening. It has been reported that x2go is incompatible with password protected SSH keys but this was not investigated further or reported upstream.

The design requires explicit connection initiation by the user (no any open ports, extra network connections etc before that point). And when the user initiate the connection, it requires sharing a code word with the remote party to be able to connect.

c80f0f1006