Learn Remote Desktop - Basic VNC Security (Password & View-only)

#Introduction

So far you've focused on making VNC work. Starting with episode 12, we turn around: how to make VNC hard to compromise. Let's be honest — VNC's built-in authentication is weak. The password is short, the screen transfer isn't encrypted, and many implementations open themselves to the entire network by default.

This episode builds the first layer of defense: understanding the vncpasswd limitations, using view-only passwords, restricting access with -localhost and binding to specific interfaces, and configuring the firewall so only allowed client IPs can get in. Full encryption follows in episodes 13 and 14.

#vncpasswd and Its Limitations

#Creating and Storing Passwords

The main tool for VNC authentication is vncpasswd. It creates the password file the server reads to validate clients:

vncpasswd
vncpasswd -f > ~/.vnc/passwd

The vncpasswd command runs interactively and writes to ~/.vnc/passwd. The -f option allows the password to be read from a separate input — useful when creating passwords for several users in a script.

#The Weak 8-Character Limit

This is a fundamental weakness you must understand: classic VNC authentication only uses the first 8 characters of the password. The remaining characters are ignored, and verification uses DES with a derivation key that's already publicly known. The consequences:

• Passwords longer than 8 characters don't add security to classic VNC authentication.
• The DES key can be brute-forced offline if an attacker captures the handshake.
• Replace "long passwords" with a truly random combination in the first 8 characters.

x11vnc -storepasswd

Because of this limitation, never rely on a VNC password alone. The password is only the first layer; transport encryption (TLS/SSH) is the layer that closes the real gap, and it will be covered in episodes 13-14.

#View-Only Passwords

#Separating Access Rights

Some VNC implementations allow two classes of passwords: one for full control, another that can only view the screen. In x11vnc, use -viewpasswd:

x11vnc -display :0 -rfbauth /etc/x11vnc.pass -viewpasswd /etc/x11vnc-view.pass

The x11vnc -display :0 -rfbauth /etc/x11vnc.pass -viewpasswd /etc/x11vnc-view.pass command makes connections with the main password able to control the screen, while connections with the second password can only view — no typing or mouse movement.

This feature is ideal for presentation scenarios: participants can follow the screen, only one presenter controls it. Combine it with the clipboard restrictions discussed in episode 11 for a truly locked-down session.

#Access Control on the Server Side

#-localhost: Restrict to Loopback

The strictest way to restrict access is -localhost, which makes the server listen only on 127.0.0.1. No other machine on the network can connect directly:

x11vnc -display :0 -rfbauth /etc/x11vnc.pass -localhost
vncserver :1 -localhost -geometry 1920x1080

The vncserver :1 -localhost -geometry 1920x1080 command starts a virtual display that can only be accessed from the machine itself. This is the safest pattern: VNC stays dead to the network, and access is opened only through an SSH tunnel (episode 14).

#Binding to a Specific Interface

If the server has several network interfaces, you can bind VNC to only one internal interface with the -listen option in x11vnc:

x11vnc -display :0 -rfbauth /etc/x11vnc.pass -listen 192.168.1.20

x11vnc -listen 192.168.1.20 makes the server listen only on the internal address, so VNC isn't visible from the public interface. Verify with ss:

ss -tulpn | grep 5900

#Firewall: Only Allow Client IPs

#ufw on Debian and Ubuntu

The firewall is the defense layer that governs who can reach the port. On Debian/Ubuntu with ufw, allow only one client IP to the VNC port:

sudo ufw allow from 192.168.1.100 to any port 5900 proto tcp
sudo ufw status verbose

The sudo ufw allow from 192.168.1.100 to any port 5900 proto tcp command creates a rule that opens port 5900 only for that IP — all other IPs are denied.

#firewalld on RHEL and Rocky

On the RHEL family, the same rule is written as a rich rule:

sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=192.168.1.100 port port=5900 protocol=tcp accept'
sudo firewall-cmd --reload

firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=192.168.1.100 port port=5900 protocol=tcp accept' stores a permanent rule that only accepts connections from 192.168.1.100. Change the address to match your client IP — don't spread access across the whole subnet.

#The Ideal Layered Pattern

Overall, basic VNC defense should ideally be layered:

• Layer 1: a strong random password in the first 8 characters.
• Layer 2: a view-only password for sessions that only display the screen.
• Layer 3: bind to an internal interface or -localhost.
• Layer 4: a firewall that only allows specific client IPs.

password  +  view-only  +  bind/interface  +  firewall  ->  secure VNC server

#Conclusion

Episode 12 built the first line of defense: understanding the weak 8-character VNC password, separating control rights with view-only passwords, restricting access via -localhost and interface binding, and closing the port with a firewall that only allows client IPs.

Key takeaways:

• Classic VNC authentication only uses the first 8 characters of the password.
• VNC passwords are weak by design — never make them your only defense.
• -viewpasswd creates connections that can only view the screen.
• -localhost and -listen restrict access on the server side.
• ufw and firewalld can allow only one client IP.
• Layer everything: password, view-only, bind, and firewall.

In the next episode, episode 13, we close VNC's biggest weakness: encryption — the plaintext VNC problem that can be sniffed, activating TLS/SSL in x11vnc and TigerVNC, and why an SSH tunnel is a mandatory encryption layer. See you there!