Install TigerVNC Server on Debian 13 (Trixie)

TigerVNC on Debian 13 starts a full XFCE desktop as a systemd service without a custom xstartup script. With no configuration at all, it listens only on 127.0.0.1. An idle session on our test box held 175 to 203 MB of memory across about 60 tasks, so a 4 GB VM carries several users before memory becomes the limit.

Original content from computingforgeeks.com - post 102795

The steps below install TigerVNC and XFCE, run one session per user through the tigervncserver@ unit, and compare five of the security types the server offers, from the default localhost-only VncAuth to X509 certificates and RSA-AES. Every command and output comes from a fresh Debian 13 cloud VM (tested October 2026 with TigerVNC 1.15), with the viewer side run from the matching tigervnc-viewer package. Two behaviours that older guides get wrong are measured here as well, the password length limit and how far PlainUsers actually reaches.

Prerequisites

Our lab VM had 2 vCPUs, 4 GB of RAM and a 20 GB disk, and it ran the stock Debian 13 cloud image with a sudo user named klinsmann. Replace that name with your own user wherever it appears. The desktop install alone added 1.2 GB on disk, so a 10 GB root volume is the practical floor, and memory planning should start from the per-session figure below rather than from the base system:

• Server: Debian 13 with sudo and SSH access; the cloud image ships no firewall, so Step 6 adds one.
• Client: any TigerVNC viewer; on Debian or Ubuntu that is the tigervnc-viewer package, and tigervnc.org links Windows and macOS builds.
• Memory: about 200 MB per connected XFCE session on top of the base system.

A fresh server should get the usual baseline before any desktop goes on it. Our list of things to do after installing Debian 13 covers SSH keys, updates and the firewall in that order, and the SSH key part matters here because Step 5 depends on it.

Step 1: Install TigerVNC and XFCE

Both TigerVNC and XFCE are in the Debian main archive, so no extra repository is involved. The server package is tigervnc-standalone-server, tigervnc-tools provides the tigervncpasswd command, and dbus-x11 gives the desktop a session bus. Install all of them in one transaction.

sudo apt update
sudo apt install -y xfce4 xfce4-goodies tigervnc-standalone-server tigervnc-common tigervnc-tools dbus-x11

On the minimal cloud image this pulled in 642 packages. Most of that weight is the desktop and its applications rather than TigerVNC, and the summary line from apt gives the real cost of a desktop on a headless server.

0 upgraded, 642 newly installed, 0 to remove and 0 not upgraded.
Need to get 306 MB of archives.
After this operation, 1222 MB of additional disk space will be used.

xfce4-goodies adds panel plugins and extra tools, so leave it out if disk matters more than convenience. Confirm the installed versions next, because the configuration paths in the rest of this guide changed between TigerVNC releases and an older package would put files somewhere else.

dpkg -l tigervnc-standalone-server tigervnc-common tigervnc-tools xfce4 | grep ^ii

Our test box reported these builds, all from the trixie main archive with no backports involved.

ii tigervnc-common 1.15.0+dfsg-2.1~deb13u1
ii tigervnc-standalone-server 1.15.0+dfsg-2.1~deb13u1
ii tigervnc-tools 1.15.0+dfsg-2.1~deb13u1
ii xfce4 4.20.1

Alongside the binaries, the package installs the systemd template unit [email protected] and the user map /etc/tigervnc/vncserver.users, which Step 3 uses. A detailed walk through the desktop itself is in our guide to installing XFCE on Debian.

Step 2: Set the VNC password

VncAuth uses its own password, separate from the Unix login, and stores it in the home directory of the user who owns the session. Run the tool as that user and not with sudo, since sudo would write the file into the root home directory where the session never looks.

tigervncpasswd

Enter the password twice and answer n to the view-only question. On Debian 13 the tool writes an 8-byte file with mode 0600 to ~/.config/tigervnc/passwd, not to ~/.vnc as on older releases, which is the first place to look when an old guide’s paths do not match.

-rw------- 1 klinsmann klinsmann    8 Oct 20 11:23 passwd

Those 8 bytes are the whole story of VncAuth strength. The protocol uses exactly 8 characters, and this version of tigervncpasswd refuses longer input outright instead of truncating it quietly, so a 12-character password from a password manager will not go in. We tried a 12-character and then a 5-character password, and the two runs printed these lines.

Password should not be greater than 8 characters
Because only 8 valid characters are used - try again
Password must be at least 6 characters - try again

Six to eight characters is a weak secret for anything reachable from a network. That is the reason the default configuration binds to loopback only, and the reason Step 7 compares stronger options before any port is opened.

Step 3: Start the session with systemd

Each display number maps to one Unix user in /etc/tigervnc/vncserver.users. Display :1 listens on TCP port 5901, :2 on 5902, and so on, so the number you pick here also fixes the port. Add the mapping for the first user.

echo ':1=klinsmann' | sudo tee -a /etc/tigervnc/vncserver.users

Enable and start the instance for display :1, then read its status. The status output looks small, and it is misleading in one detail that matters when you size the server.

sudo systemctl enable --now tigervncserver@:1.service
systemctl status tigervncserver@:1.service --no-pager

The unit reports under 1 MB of memory because it only holds tigervncsession. The desktop runs in a separate logind session scope opened through PAM, so this figure says nothing about the real footprint. The block below is trimmed to the relevant lines.

● tigervncserver@:1.service - Remote desktop service (VNC)
     Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled; preset: enabled)
     Active: active (running) since Tue 2026-10-20 11:23:46 UTC; 5s ago
    Process: 34255 ExecStart=/usr/libexec/tigervncsession-start :1 (code=exited, status=0/SUCCESS)
   Main PID: 34262 (tigervncsession)
     Memory: 448K (peak: 1.8M)
     CGroup: /system.slice/system-tigervncserver.slice/tigervncserver@:1.service
             ‣ 34262 /usr/sbin/tigervncsession klinsmann :1

Oct 20 11:23:46 vnc01 tigervncsession[34262]: pam_unix(tigervnc:session): session opened for user klinsmann(uid=1000) by (uid=0)

No xstartup file existed at this point, yet XFCE started. Three defaults in the Debian wrapper explain what happened on the first start:

• Session: with no per-user startup script, the wrapper runs /etc/X11/Xtigervnc-session, which hands off to /etc/X11/Xsession and then to x-session-manager, which is xfce4-session when XFCE is the only desktop.
• Security type: with nothing configured, it offers VncAuth only.
• Binding: because VncAuth encrypts nothing after the password exchange, it forces -localhost=1.

A custom xstartup is therefore only needed to run a different desktop than the system default. Check the binding with ss, whose process column also confirms that Xtigervnc itself owns the socket.

sudo ss -ltnp | grep 5901

Only loopback is bound, on IPv4 and IPv6, and the session log in ~/.config/tigervnc/vnc01:1.log says the same with Listening for VNC connections on local interface(s), port 5901.

LISTEN 0      5          127.0.0.1:5901      0.0.0.0:*    users:(("Xtigervnc",pid=34271,fd=9))
LISTEN 0      5              [::1]:5901         [::]:*    users:(("Xtigervnc",pid=34271,fd=10))

To measure the real footprint, query the logind scope that holds the desktop. systemd-logind names these sessions c1, c2 and so on because they have no audit session ID, and loginctl list-sessions shows which one belongs to which display if more than one exists.

loginctl show-session c1 -p Display -p Service -p Scope
systemctl show session-c1.scope -p MemoryCurrent -p TasksCurrent

Our first measurement, taken seconds after start at the default 1920×1200 geometry and before any client connected, came to 174.6 MB across 57 tasks.

Display=:1
Service=tigervnc
Scope=session-c1.scope
MemoryCurrent=174575616
TasksCurrent=57

The largest single process was Xtigervnc at 124 MB resident, followed by xfce4-session at 80 MB and xfdesktop at 72 MB. Resident sizes overlap through shared libraries, so they do not add up to the scope total, and the scope figure is the one to plan with. For comparison across desktops, our measured desktop environment RAM usage tests put XFCE among the lighter options, which is why it remains the usual pick for VNC.

Step 4: Set the geometry and colour depth

Out of the box, the wrapper uses 1920×1200 at 24-bit depth. Per-user options live in ~/.config/tigervnc/config.pl, a Perl file of variable assignments that ends with 1;. The wrapper also accepts a plain key=value file named ~/.config/tigervnc/config, but only when no config.pl exists, so keep one format per user to avoid wondering which file won. Create the Perl file as the session owner.

nano ~/.config/tigervnc/config.pl

A geometry that matches the client screen avoids scaling in the viewer, and a smaller framebuffer also means less to encode per update. Our test box used 1600×900.

$geometry = "1600x900";
$depth = 24;
1;

Restart the instance so the wrapper rereads the file, then check the server command line. It shows the new values together with the defaults the wrapper filled in, which is the fastest way to see what a config file actually changed.

sudo systemctl restart tigervncserver@:1.service
ps -o args= -C Xtigervnc

Our restart produced -localhost=1, -rfbport 5901, -SecurityTypes VncAuth, -geometry 1600x900 and -depth 24. A system-wide default for every user belongs in /etc/tigervnc/vncserver-config-defaults, which uses the same Perl syntax, while settings that users must not override go into vncserver-config-mandatory next to it.

Step 5: Connect through an SSH tunnel

With the default loopback binding, a tunnel is the only way in from another machine. SSH carries the VNC traffic encrypted, the server needs no open port beyond 22, and the weak 8-character password is no longer exposed to the network. On the client, forward local port 5901 to the loopback port on the server.

ssh -L 5901:localhost:5901 [email protected]

Leave that session open, then point the viewer at the local end of the tunnel. On a Debian or Ubuntu client the viewer comes from tigervnc-viewer, and display localhost:1 means local port 5901.

sudo apt install -y tigervnc-viewer
xtigervncviewer localhost:1

Without a -passwd file, the viewer asks for the VNC password from Step 2 before the desktop opens. If SSH keys are not set up yet, our guide to SSH key authentication uses the same ssh-keygen and ssh-copy-id steps that work against Debian. For most single-admin servers this tunnel is the setup to keep, because it adds no listening port and no new credential to manage.

Loopback does not shield the session from other accounts on the same server, though. Any local user can connect to 127.0.0.1:5901, so once a second person has a login on the box, the 8-character VNC password is the only thing between them and your desktop.

Step 6: Prepare the firewall

The next step opens the VNC port on all interfaces, and our Debian 13 cloud image had neither nftables nor ufw installed. Put the firewall in place first, so the port is never reachable from everywhere. Allow SSH before enabling, or the current session drops; if sshd listens on a port other than 22, allow that port instead of the OpenSSH profile.

sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw allow from 10.0.1.0/24 to any port 5901 proto tcp
sudo ufw --force enable
sudo ufw status numbered

The numbered rule list matched the plan, with SSH open everywhere and VNC limited to one subnet.

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] OpenSSH                    ALLOW IN    Anywhere
[ 2] 5901/tcp                   ALLOW IN    10.0.1.0/24
[ 3] OpenSSH (v6)               ALLOW IN    Anywhere (v6)

Once Step 7 had the server listening on 0.0.0.0:5901, a TCP connect from a lab host outside that subnet got no answer within 6 seconds while port 22 still answered. We could not test the allowed path from a real 10.0.1.0/24 client, so confirm it from one of your own machines. More rule patterns, including rate limiting, are in our UFW firewall commands reference.

Step 7: Compare the security types

When a tunnel is not practical, for example for a viewer on a managed workstation where outbound SSH is blocked, TigerVNC can encrypt the connection itself. The $SecurityTypes variable in config.pl selects the methods. Any encrypting type (TLSVnc, TLSPlain, the X509 types with a password, or RA2) makes the wrapper drop the loopback restriction, while the *None types keep it, and the unencrypted RA2ne also opens on all interfaces. We tested five types against the matching viewer.

Security type	Encryption	Server identity check	Credential	Listens on
VncAuth (default)	None	None	8-character VNC password	127.0.0.1 and ::1
TLSVnc	Anonymous TLS	None, no prompt shown	8-character VNC password	All interfaces
X509Vnc	TLS	Certificate and hostname	8-character VNC password	All interfaces
X509Plain	TLS	Certificate and hostname	Unix password of the session owner	All interfaces
RA2_256	RSA-AES	Fingerprint prompt on every connection	8-character VNC password	All interfaces

Read the table by what each type protects against:

• TLSVnc: encrypts the traffic, but our viewer connected without any prompt because anonymous TLS has no certificate, so it stops passive sniffing and not interception.
• X509Vnc: verifies a certificate and the hostname, which makes it the type to use for direct connections.
• RA2_256: shows the server key fingerprint and asks for approval on every connection, with no certificate files to copy and nothing remembered between sessions.

The rest of this step sets up X509Vnc. Edit ~/.config/tigervnc/config.pl again and add the security type line above 1;.

$geometry = "1600x900";
$depth = 24;
$SecurityTypes = "X509Vnc";
1;

Restart the instance. On this start the wrapper finds no certificate and generates a self-signed one before launching the server, so nothing has to be created by hand.

sudo systemctl restart tigervncserver@:1.service
sudo ss -ltn | grep 5901

Port 5901 now listens on every interface, which is why the firewall came first.

LISTEN 0      5            0.0.0.0:5901      0.0.0.0:*
LISTEN 0      5               [::]:5901         [::]:*

The certificate is named after the output of hostname -f, not the short hostname, and that same name goes into its CN and subject alternative name. On our second run the server had 127.0.1.1 vnc01.example.com vnc01 in /etc/hosts, so the wrapper wrote vnc01.example.com-SrvCert.pem with its key in vnc01.example.com-SrvKey.pem at mode 0600. Check what yours is called and inspect it before handing it to any client.

hostname -f
openssl x509 -in ~/.config/tigervnc/$(hostname -f)-SrvCert.pem -noout -subject -dates -ext subjectAltName

It is valid for 2190 days, six years, and carries the full name plus localhost. The key is ECDSA on the P-384 curve.

vnc01.example.com
subject=CN=vnc01.example.com
notBefore=Oct 20 11:56:12 2026 GMT
notAfter=Oct 18 11:56:12 2032 GMT
X509v3 Subject Alternative Name:
    DNS:vnc01.example.com, DNS:localhost

Each client needs a copy of that certificate to verify the server, and copying it over SSH once means the copy itself cannot be tampered with. Use the name that hostname -f printed.

scp [email protected]:.config/tigervnc/vnc01.example.com-SrvCert.pem .

The client has to connect by exactly that name. Connecting to the IP address made the viewer stop with a hostname mismatch, even with the right certificate supplied through -X509CA, and connecting as the short name vnc01 failed the same way.

Answering Yes stores an exception, which defeats the point of the certificate. Add a DNS record or a hosts entry on the client instead, so the full name resolves to the server.

echo '10.0.1.50 vnc01.example.com' | sudo tee -a /etc/hosts

Then connect by that name with the copied certificate. The -X509CA option points at the file from scp, so the viewer trusts this one server and nothing else.

xtigervncviewer -SecurityTypes X509Vnc -X509CA vnc01.example.com-SrvCert.pem vnc01.example.com:1

Our viewer log showed Choosing security type X509Vnc (261) with no warning, and the window opened as vnc01.example.com:1 (klinsmann) - TigerVNC. Our test runs passed the password file with -passwd, so no prompt appeared; without it, the viewer asks for the VNC password. This capture comes from the earlier run, when the host had no domain name, and its terminal shows display :1 on 0.0.0.0:5901 and a second user, added in Step 9, still on loopback.

RA2_256 is the alternative when managing certificates is not worth it. The wrapper generates a 4096-bit RSA key in a -SrvRsaKey.pem file, and the viewer shows an 8-byte fingerprint such as 13-7e-ff-dc-96-55-d8-ff and asks you to accept it. We connected twice and got the prompt both times, because the viewer stores no record of RA2 keys. Record the fingerprint once over a path you trust, for example through the Step 5 tunnel to localhost:1 (a route we did not test for RA2 specifically), then compare it on every connection, because clicking Yes without comparing gives no protection against interception.

Step 8: Use Unix passwords with X509Plain

X509Plain replaces the 8-character VNC password with the Unix password, checked through PAM, while keeping the certificate check from Step 7. Replace the security type line in config.pl. A $PlainUsers line is optional, because the wrapper already sets it to the session owner. Our server command line showed -PlainUsers klinsmann with no such line in the file.

$geometry = "1600x900";
$depth = 24;
$SecurityTypes = "X509Plain";
1;

Restart the instance and connect with the matching security type. The certificate and name rules from Step 7 still apply.

sudo systemctl restart tigervncserver@:1.service
xtigervncviewer -SecurityTypes X509Plain -X509CA vnc01.example.com-SrvCert.pem vnc01.example.com:1

The viewer showed a username and password dialog under a green “This connection is secure” bar, and the session owner logged in with their Unix password. Each successful login still writes pam_unix(tigervnc:account): setuid failed: Operation not permitted to the journal, which is harmless noise from the account check running unprivileged.

A second account did not get in, even when listed. We created a user called analyst with a valid Unix password, set $PlainUsers = "klinsmann,analyst";, restarted, and the login failed with this entry in the journal.

Xtigervnc[37007]: pam_unix(tigervnc:auth): authentication failure; logname= uid=1000 euid=1000 tty= ruser= rhost=  user=analyst

Process ownership is the cause. Xtigervnc runs as uid 1000, the owner of display :1, and an unprivileged process can only verify its own Unix password through pam_unix. In practice, PlainUsers on a per-user systemd session authenticates the session owner and nobody else, so each person still needs their own display, as in Step 9.

Step 9: Add a second user on display :2

Each user gets a separate display, port, XFCE profile and config.pl. Create the account first if it does not exist yet. Our lab used analyst.

sudo useradd -m -s /bin/bash analyst
sudo passwd analyst

The order of the next commands matters, because the VNC password has to exist before the unit starts. We enabled :2 for analyst before setting it, and the journal made the failure look like success.

tigervncsession[38190]: tigervncsession: tigervncserver exited with status=1
tigervncsession[38190]: pam_unix(tigervnc:session): session closed for user analyst
systemd[1]: tigervncserver@:2.service: Deactivated successfully.

systemd reports “Deactivated successfully” and systemctl is-active prints inactive, not failed. Running the wrapper by hand as that user shows the real reason, You will require a password to access your desktops. Set the password as the new user, then map the display and start it.

sudo -u analyst tigervncpasswd
echo ':2=analyst' | sudo tee -a /etc/tigervnc/vncserver.users
sudo systemctl enable --now tigervncserver@:2.service

Both instances were then active, and each followed its own config.pl, with :1 on an encrypted type across all interfaces and :2 on the default VncAuth bound to loopback. Any SSH login can carry the tunnel to :2, for example ssh -L 5902:localhost:5902 [email protected] followed by xtigervncviewer localhost:2, because the VNC password is what identifies analyst. That also means klinsmann, or any other local account, can reach the loopback port of analyst, so the second VNC password matters as much as the first. Open 5902 in ufw only if that user also moves to an encrypted type, since VncAuth on an open port sends everything after the password in clear.

Memory per session was measured from each logind scope after both desktops had settled. The first session had served several viewer connections by then, while the second had none.

Display	User	Security type	Memory (MemoryCurrent)	Tasks
:1	klinsmann	X509Vnc, after several viewer connections	203.2 MB	62
:2	analyst	VncAuth, no client connected yet	180.0 MB	62

With both sessions running, free -m reported 3068 MiB available out of 3922 MiB. On paper that leaves room for many more idle XFCE sessions, but a browser inside a session changes the picture quickly, so size the VM by the applications people will run and not by the idle desktop.

Troubleshooting

These are the failures we hit on Debian 13, with the exact message each one produced and the change that fixed it.

“tigervncserver exited with status=1” and the unit is inactive

The user has no ~/.config/tigervnc/passwd. systemd marks the unit inactive rather than failed, so monitoring that only alerts on failed units misses it. Create the password as that user with tigervncpasswd and start the instance again. On a system upgraded from an older release, the wrapper moves an existing ~/.vnc into ~/.config/tigervnc on first start, but only when ~/.config/tigervnc does not exist yet. It leaves a symlink behind and renames tigervnc.conf to config.pl, so old password files keep working. We read that from the wrapper source rather than testing an upgrade.

“Password should not be greater than 8 characters”

VncAuth uses 8 characters, and this version rejects anything longer instead of truncating it. Use 6 to 8 characters for VncAuth, or move to X509Plain if policy requires longer passwords, keeping in mind that it only authenticates the session owner.

“Server certificate doesn’t match given server name”

The viewer connected by IP address or by a name that is not in the certificate. Since the auto-generated certificate covers only the hostname -f name and localhost, connect with exactly that name through a DNS or hosts entry. A certificate that lists other names can replace it through the $X509Cert and $X509Key variables in config.pl.

Old sessions stay in “closing” after restarts

Each systemctl restart during our tests left the previous logind session in the closing state. After eight restarts of :1 and one of :2, loginctl listed nine closing sessions, each holding one leftover xiccd colour daemon at about 1 MB. loginctl terminate-session did not clear them in our test, but stopping the abandoned scope units did.

for u in $(systemctl list-units 'session-c*.scope' --no-legend --plain | awk '$4=="abandoned"{print $1}'); do sudo systemctl stop "$u"; done

Afterwards only the two running scopes remained, and the xiccd count dropped from 11 to 2, one per live session. Stopping a scope kills everything left in it, including any nohup job someone started from the old desktop, so check systemd-cgls first on a shared server. A reboot clears them as well, which makes this housekeeping rather than a fault on a server that rarely restarts its VNC units.

Debian 12 paths

Debian 12 ships TigerVNC 1.12, which predates the move to XDG directories in 1.14. On bookworm the password, the per-user tigervnc.conf and the logs live under ~/.vnc, and the 8-character refusal is also newer than that release, so a longer password is accepted there and silently cut to 8 characters. We did not retest the full flow on Debian 12. For a browser-based alternative that fronts VNC, RDP and SSH from one portal, see how to configure VNC connections in Apache Guacamole. The wider comparison of open source remote desktop tools covers xrdp and NoMachine as well.