Secure Remote Desktop Access on Linux Using TigerVNC, XFCE, and SSH Tunneling

Working remotely on Linux systems often means managing everything through the terminal. But what if you want a graphical interface without sacrificing security?

Let’s first discuss why TigerVNC and XFCE?

TigerVNC allows graphical remote access to Linux systems through the VNC (Virtual Network Computing) protocol. Virtual Network Computing (VNC) is a remote desktop sharing system based on the RFB protocol that allows a user to view and interact with a desktop environment remotely over a network connection.

XFCE is a lightweight desktop manager and are often stable with VNC connections rather than GNOME. It is fast and ideal for servers or low-resource environments.

SSH tunneling adds an encryption layer, securing your connection end-to-end.

What Happens When We Have TigerVNC but No XFCE?

Let’s suppose that TigerVNC is the projector, XFCE is the movie, and VNC client is the audience. TigerVNC shows the visuals on a screen so others can see them. XFCE is what the projector actually displays — the content(desktop, icons, menus). f the theater has a projector (TigerVNC) but no movie playing (XFCE), what do you see?

Just a blank screen.

That’s exactly what happens when you run TigerVNC without installing a desktop environment — it’s running fine, but there’s nothing graphical to show.

Note: In this tutorial, I have a Kali Lab inside my Virtual Machine to work as a VNC server. I will be remotely connecting from my Windows OS to VM within my laptop.

┌──(kali㉿kali)-[~] is a VNC server.

C:\Users\gtmsa> is a VNC client.

Step 1: Install XFCE and TigerVNC

Start by installing the necessary packages:

Fig 1. installing necessary packages

After installation, set a password for VNC access:

Fig 2. setting up vnc passwd

You’ll be asked to create a password of length 6 to 8 characters long. When prompted for a “view-only” password, choose no(n). When you entered “yes” during view-only password setup in vncpasswd, you created a separate password that allows users to view but not control the VNC session.

Step 2: Configure the VNC Server

During installation, a hidden folder ~/.vnc is created. But, in my case, I have to create myself through mkdir command. Inside this folder, create two files — one to define how the sessions starts, and another for display settings.

Fig 3. files for session start & display settings

Configure the Startup Script

You need to edit the xstartup file to tell VNC to lunch the XFCE desktop:

Fig 4. xstartup script

When you login into your desktop(say XFCE, GNOME, or KDE), something needs to start all the background programs, remember what windows you had open last time, handle things like “Shut down”. That “something” is basically known as the Session Manager. When you start a VNC desktop, you’re opening a separate graphical session. But your terminal(the one lunching vncserver)may still have the SESSION_MANAGER variable set from your main desktop login.

DBUS_SESSION_BUS_ADDRESS variable is a message bus system’s address or the address of a communication system used by applications to communicate in a desktop environment for coordinating tasks between programs. Every session has its own D-Bus “post office”. So, when an app starts, it looks at this variable to know where to send messages. When you start a VNC session, you’re creating a new desktop session — separate from the one on your physical monitor. But if DBUS_SESSION_BUS_ADDRESS is already set(from the main desktop), the new VNC apps will try to send their messsages to that old D-BUS(the one on your real monitor). This causes confusion.

When starting XFCE4 in a VNC session, the process typically works like this:

1. /usr/bin/startxfce4 starts the XFCE4 desktop environment.
2. The script checks if /etc/vnc/xstartup/ exists and is executable, If yes, run it.
3. The script then checks for the file /home/yourname/.Xresoures. If it exists and is readable, then settings in .Xresources are applied. The file configures X display settings such as fonts and colors.

Now, the components work together:

X11(or X) is the engine that handles rendering pixels, drawing windows, capturing mouse/keyboard input, and creating the graphical environment.

x-window-manager is a symbolic link to whichever window manager your system has installed. The window manager basically draws windows border, title bars, and buttons(close, minimize, etc). It also lets you move or resize, and also handle desktop layouts, workspaces, and sometimes wallpapers. As a whole, it provides UI controls.

XFCE Desktop is the full desktop environment, providing panels, menus, app launchers, and other features on top of X11 and the window manager.

The flow of control looks like this:

VNC Client → VNC Server → X11 → Window Manager → XFCE Desktop

Fig 5. making xstartup executable

Configure Display Settings

The following command appends custom display settings to your VNC server config file so that every time start VNC, it uses:

1920x1080 resolution 96 DPI

Fig 6. vnc config file

Step 3: Start the VNC Server

The command vncserver starts the TigerVNC server process. It creates a virtual display(like a “fake monitor”) on your machine to access it remotely using a VNC viewer. The flag -xstartup ~/.vnc/xstartup tells the VNC server what desktokp environment to lunch when it starts. Normally, VNC looks for a system default script(like /etc/X11/Xtigervnc-session). But, in my case, that default was failing, so we manually provided our own script. :1 means to create a new session on display 1 and listen for VNC connections on TCP port 5901.

Fig 7. starting vncserver with manaul scripts

Step 4: Secure the Connection with SSH Tunneling

By default, VNC traffic isn’t encrypted — anyone intercepting your connection could see your session data. We fix that by creating an SSH tunnel, which encrypts the communication between your local system and server.

At this moment, there are few important things to do before SSH:

a. Installation of SSH and It’s Configuration

Before using VNC securely, confirm that the SSH service is active on your server. You can take help from this article regarding SSH: (https://medium.com/@safalgautam/configuring-and-debugging-ssh-for-remote-access-def0a0a85b26.)

Make sure these settings are applied for better security:

PermitRootLogin no PasswordAuthentication yes Port 22

This settings disables the ability for the root user to log in directly via SSH, enables SSH password authentication for allowing users to login using passwords, and sets the SSH server to listen on the default port 22.

Fig 8. SSH configuration and status

Note: Key-Based Authentication uses a private-public key pair for secure SSH login without passwords. We can configure it for offering stronger protection than traditional password authentication.

b. Set Up a VNC User and Configure Permissions(Optional)

You should run VNC under a normal user(not root). If you don’t have one:

Fig 9. adding a vncuser

This practice will ensure security isolation and avoids privilege misuse.

c. Ports Forwarding from Virtual Box and SSH Tunneling

When you choose NAT mode for your VirtualBox network adapter, it behaves like this:

Fig 10. VM NAT workflow

Windows or any other machine cannot directly access the guest VM as the guest is hidden behind VirtualBox’s NAT gateway. When you try to connect from Windows to Kali(inside VirtualBox) like:

ssh -p 22 kali@127.0.0.1

you are connecting to Windows itself, not the VM.

Hence, the connection fails.

The solution is port forwarding, which tells Virtual Box’s NAT engine that when traffic comes to my host(Windows) on port X, please send it inside the VM to port Y. You can set up port forwarding rules like:

Fig 11. port forwarding rules

This defines the path as: Windows Host(localhost: 22) → Port forwarding rule → VirtualBox NAT → Kali VM(IPaddr:22) that can defined in Guest IP.

Fig 12. successful SSH connection

When we use only port forwarding(No SSH Tunnel), sometimes connection drops or “connection closed” errors can occur.

On our local machine, run:

Fig 13. VNC client succeed

This creates a secure, encrypted tunnel where host port 15901 is linked to Kali’s 127.0.0.1:5901 through SSH. It also tells SSH not to execute any remote command(just forward traffic). It runs SSH in the background and specifies the remote user as kali. The <server-ip> is the important part you shouldn’t mess up. Since we are in the same machine, we are SSHing to localhost. That effectively forwards local port 15901 to local port 5901 through an SSH loopback — useful for testing or when you're SSHing into a container/VM bound to the loopback on the same host.

If your intention was to reach a remote Kali VM at 10.0.0.5, you would replace localhost with that IP:

ssh -v -L 15901:127.0.0.1:5901 -N -f -l kali -p 22 10.0.0.5

Step 5: Connecting through TightVNC Viewer

Now, you can install TightVNC Viewer and open it:

Fig 14. connecting through TightVNC Viewer

Fig 15. authentication with vncpasswd

Fig 16. VNC-client

Whether you’re managing servers or working from afar, this setup keeps you in control without slowing you down.