When securing TigerVNC with SSH tunneling on RHEL/CentOS systems, many administrators notice an apparent redundancy: despite requiring successful SSH authentication, users must still set a VNC password via vncpasswd. This creates a dual-authentication layer that seems unnecessary at first glance.

The VNC password serves two critical purposes even with SSH tunneling:

• Session Isolation: SSH grants system access, while VNC passwords control desktop session access
• Multi-User Security: Prevents SSH-authenticated users from accessing other users' active VNC sessions
• Protocol-Level Requirement The RFB protocol (VNC's underlying protocol) mandates password authentication

While not recommended for production environments, you can bypass VNC password requirements through these methods:

Method 1: Empty Password Configuration

# Create empty password file
touch ~/.vnc/passwd
chmod 600 ~/.vnc/passwd

# Configure xstartup to skip password check
echo '#!/bin/sh
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc' > ~/.vnc/xstartup
chmod +x ~/.vnc/xstartup

Method 2: VNC Server Command-Line Parameters

vncserver :1 -SecurityTypes None -localhost -geometry 1920x1080

Key parameters:

• -SecurityTypes None: Disables all authentication
• -localhost: Restricts to SSH tunnel only

Method 3: Permanent Configuration via vncserver-config

# /etc/systemd/system/vncserver@.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/bin/vncserver %i -SecurityTypes None -localhost

Before disabling VNC passwords, consider these security implications:

• Any process on the SSH client machine could access the VNC session
• If SSH credentials are compromised, attackers gain direct VNC access
• No protection against insider threats between multiple users

For optimal security while reducing authentication friction:

vncserver :1 -SecurityTypes VncAuth -PasswordFile=/dev/null -localhost

This configuration:

• Maintains protocol compliance with RFB
• Works with standard VNC clients
• Still requires SSH tunneling
• Prevents password brute-force attacks

If you encounter problems after disabling passwords:

# Check authentication logs
journalctl -u vncserver@:1.service -f

# Verify SSH tunnel
netstat -tulpn | grep 5901

# Test raw connection (should fail without SSH)
telnet localhost 5901

---

When configuring TigerVNC to operate exclusively through SSH tunnels (typically on port 5901 or via ssh -L forwarding), many administrators notice an apparent redundancy: users must authenticate twice - first via SSH keys/passwords, then again with a VNC password. This dual authentication creates friction without clear security benefits when the VNC server only listens on localhost.

The VNC password requirement persists because:

1. TigerVNC's security model was designed for direct network exposure
2. The authentication layers operate independently (SSH at transport layer, VNC at application layer)
3. Multi-user systems may have different SSH and VNC permissions

# Current typical configuration in /etc/sysconfig/vncservers
VNCSERVERS="1:username"
VNCSERVERARGS[1]="-localhost -geometry 1024x768"

To eliminate the VNC password requirement while maintaining security:

# Step 1: Configure xstartup to bypass authentication
vim ~/.vnc/xstartup
----------------------------------
#!/bin/sh
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc
----------------------------------

# Step 2: Modify TigerVNC server arguments
vim /etc/sysconfig/vncservers
----------------------------------
VNCSERVERARGS[1]="-SecurityTypes None -localhost"

Critical security notes:

• Always keep -localhost restriction
• Combine with SSH AllowTcpForwarding yes
• Consider adding PermitOpen localhost:5901 in sshd_config

After restarting both services:

service vncserver restart
service sshd restart

# Test connection:
ssh -L 5901:localhost:5901 user@host
vncviewer localhost:5901

The session should connect without VNC password prompt while maintaining SSH encryption.

For systems requiring audit trails:

# Configure /etc/pam.d/vnc
auth sufficient pam_ssh_auth.so
auth required pam_permit.so

This maintains authentication logging while delegating to SSH credentials.