Come installare un server VNC su Ubuntu per GNOME

Su Ubuntu con GNOME, il punto non è “far partire VNC”, ma farlo partire nel modo giusto: sessione grafica coerente, servizio avviato quando l’utente è loggato, porta esposta solo dove serve e accesso cifrato fuori dalla rete fidata. Se salti questi passaggi, ottieni quasi sempre uno di questi tre scenari: schermata nera, sessione che si chiude al logout oppure server VNC raggiungibile ma troppo esposto.

Per un desktop GNOME moderno, la soluzione più lineare è usare un server compatibile con X11 e agganciarlo a una sessione utente stabile, oppure usare il supporto desktop remoto integrato quando la versione di GNOME lo consente. In questo articolo prendo la strada più controllabile per amministrazione e troubleshooting: TigerVNC con GNOME, avviato come servizio per utente, con tunnel SSH come accesso consigliato. È un approccio più verboso del “clicca e via”, ma molto più facile da diagnosticare in produzione o su macchine gestite da remoto.

Quando VNC ha senso su GNOME

VNC è utile quando devi vedere il desktop completo della macchina, non solo una shell. È la scelta tipica per postazioni di amministrazione, server con interfaccia grafica, sandbox di test o ambienti dove GNOME è già presente e vuoi gestire GUI legacy. Non è il protocollo più efficiente in assoluto, e non è quello che sceglierei per un uso massivo o su link lenti senza ottimizzazioni, ma resta semplice da integrare e da capire.

Con GNOME bisogna chiarire un dettaglio importante: il desktop remoto e il VNC classico non sono la stessa cosa. Il primo spesso si appoggia a componenti già integrati nella sessione grafica; il secondo crea un server separato, che va avviato e mantenuto con cura. Se vuoi prevedibilità operativa, TigerVNC è una base solida. Se invece ti serve solo condividere la sessione locale di un desktop già attivo, la strada integrata di GNOME può essere più comoda. Qui però mi concentro su una configurazione classica e controllabile, adatta a chi deve sapere dove mettere le mani quando qualcosa non va.

Prerequisiti e verifica del layer grafico

Prima di installare pacchetti, verifica che la macchina abbia GNOME e che la sessione grafica sia disponibile. Su Ubuntu Desktop è ovvio; su server o VM spesso non lo è. Se non hai un display manager o una sessione utente grafica, VNC può partire ma offrirti una sessione vuota o un ambiente incompleto.

Controlli rapidi:

lsb_release -a

systemctl status gdm3

echo $XDG_SESSION_TYPE

Se `gdm3` non è attivo o non esiste una sessione grafica, prima risolvi quello. Un server VNC non sostituisce il desktop environment: lo espone, e basta. Se il problema è a monte, il VNC è solo il sintomo visibile.

Installazione dei pacchetti necessari

Per una base pulita installa TigerVNC e gli strumenti minimi per il test. Su Ubuntu recente i pacchetti standard sono sufficienti nella maggior parte dei casi.

sudo apt update

sudo apt install tigervnc-standalone-server tigervnc-common dbus-x11 x11-xserver-utils

`dbus-x11` serve spesso per evitare problemi di avvio della sessione GNOME dentro VNC. Senza DBus corretto, alcune applicazioni del desktop partono male o non partono affatto. `x11-xserver-utils` è utile per piccoli aggiustamenti della sessione X11, anche se non sempre indispensabile.

Se vuoi verificare subito la presenza del binario e della versione:

vncserver -version

Se il comando non è trovato, il pacchetto non è stato installato correttamente. Se la versione compare, sei pronto per la configurazione utente.

Impostare la password VNC per l’utente corretto

VNC lavora per utente. La password va configurata nell’account che eseguirà il server, non in root. Questo dettaglio evita confusione su file di stato e permessi, e riduce il rischio di lasciare configurazioni sparse in home diverse.

su - nomeutente

vncpasswd

Il file generato finisce normalmente in `~/.vnc/passwd`. Verifica che i permessi siano stretti:

ls -l ~/.vnc/passwd

Atteso: il file deve essere leggibile solo dall’utente proprietario. Se vedi permessi larghi, correggili subito. Non lasciare password VNC riutilizzate o deboli: VNC non nasce con un modello di sicurezza forte, quindi la difesa reale è il tunnel e il controllo degli accessi esterno.

Configurare la sessione GNOME per TigerVNC

Il file chiave è `~/.vnc/xstartup`. Qui dici al server VNC cosa deve avviare quando parte la sessione. Per GNOME su Ubuntu è meglio evitare script troppo creativi: tieni la sequenza essenziale, altrimenti finirai a inseguire una finestra nera o una sessione che non monta correttamente il desktop.

mkdir -p ~/.vnc

nano ~/.vnc/xstartup

Contenuto tipico di partenza:

#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
export XDG_SESSION_TYPE=x11
export GDK_BACKEND=x11
exec gnome-session

Rendi eseguibile lo script:

chmod +x ~/.vnc/xstartup

Qui c’è una scelta pratica: GNOME in VNC funziona meglio se lo tratti come sessione X11 dedicata. Se la tua installazione di Ubuntu usa Wayland come default per il login locale, non è un problema in sé, ma dentro VNC la strada più semplice resta X11. Se forzi componenti Wayland nel contesto VNC, spesso ti porti a casa solo comportamenti incoerenti.

Avvio manuale per trovare subito gli errori

Prima di creare un servizio systemd, avvia il server a mano. È il modo più rapido per vedere se il problema è nella sessione, nei permessi o nel desktop environment. La prima prova va fatta con una display number esplicita, per esempio `:1`.

vncserver :1 -geometry 1920x1080 -depth 24

Se tutto va bene, il server ti dirà su quale porta sta ascoltando. In VNC il display `:1` corrisponde tipicamente alla porta `5901`. Per verificare:

ss -ltnp | grep 5901

Atteso: una riga con `LISTEN` e il processo VNC. Se non compare nulla, il server non è rimasto su, e devi guardare i log.

I log di TigerVNC si trovano di solito in `~/.vnc/hostname:1.log` oppure con nome simile. Per vedere gli ultimi errori:

ls -1 ~/.vnc/
 tail -n 50 ~/.vnc/*.log

Le cause più frequenti in questa fase sono tre: `gnome-session` non trovato, DBus non inizializzato correttamente oppure conflitto con una sessione grafica già attiva. Il log te lo dice quasi sempre in chiaro; conviene leggerlo prima di cambiare config a caso.

Servizio systemd per avvio automatico

Per un server da gestire bene, il VNC manuale non basta. Serve un servizio per utente, così puoi controllare start, stop, restart e diagnosi con `systemctl`. Un’unità user-level è in genere la soluzione più pulita.

Crea la directory se non esiste:

mkdir -p ~/.config/systemd/user

Poi crea `~/.config/systemd/user/vncserver@.service` con questo contenuto:

[Unit]
Description=TigerVNC server on %i
After=graphical-session.target network.target

[Service]
Type=forking
PAMName=login
PIDFile=%h/.vnc/%H:%i.pid
ExecStartPre=-/usr/bin/vncserver -kill %i
ExecStart=/usr/bin/vncserver %i -geometry 1920x1080 -depth 24
ExecStop=/usr/bin/vncserver -kill %i
Restart=on-failure

[Install]
WantedBy=default.target

Ricarica i servizi dell’utente e abilita l’unità:

systemctl --user daemon-reload
systemctl --user enable --now vncserver@1.service

Verifica subito stato e log:

systemctl --user status vncserver@1.service
journalctl --user -u vncserver@1.service -b --no-pager

Se vuoi che il servizio parta anche senza login interattivo dell’utente, devi abilitare il lingering. È una scelta da fare consapevolmente, perché aumenta la persistenza del servizio oltre la sessione grafica locale.

sudo loginctl enable-linger nomeutente

Questo è un punto da trattare con criterio: l’utente non deve diventare un account “sempre acceso” senza bisogno. Se abiliti lingering, documenta il motivo e verifica che l’accesso sia protetto da rete fidata o tunnel.

Accesso sicuro: tunnel SSH invece di porta aperta

La regola pratica è semplice: non esporre VNC direttamente su Internet se puoi evitarlo. La porta 5901 non dovrebbe essere una porta “pubblica” su firewall o security group. Il modo corretto è aprire SSH e fare port forwarding locale.

ssh -L 5901:localhost:5901 nomeutente@server

Da lì, il client VNC si collega a `localhost:5901`. In questo modo il traffico VNC viaggia dentro SSH e non lasci in giro una superficie d’attacco inutile. Se usi firewall host, consenti SSH e limita o blocca la porta VNC in ingresso dall’esterno.

Con `ufw`, per esempio, una politica prudente è questa:

sudo ufw allow OpenSSH
sudo ufw deny 5901/tcp

Se sei in cloud, fai la stessa cosa nel security group o nel firewall del provider. L’errore più comune è aprire VNC “temporaneamente” e poi dimenticarselo esposto per mesi.

Connessione dal client e parametri utili

Dal lato client puoi usare un visualizzatore VNC qualsiasi, ma il punto operativo è sempre lo stesso: con tunnel SSH attivo, la destinazione è `localhost:5901`. Se colleghi direttamente la porta pubblica, stai saltando il pezzo più importante della configurazione.

Parametri che conviene ricordare:

Se vedi una finestra con sfondo vuoto o con solo il cursore, il problema è quasi sempre nella sessione che non parte correttamente, non nel client. In quel caso torna ai log del server VNC e verifica il contenuto di `~/.vnc/xstartup`.

Problemi tipici e come riconoscerli

Il primo errore classico è la schermata nera. Di solito significa che il server VNC è vivo, ma la sessione GNOME non è stata avviata nel modo atteso. La verifica più veloce è leggere il log e controllare se `gnome-session` termina subito o se manca un componente D-Bus.

Il secondo errore è il server che parte ma poi muore al logout. Questo succede quando lo hai lanciato come processo legato alla shell e non come servizio o sessione stabile. In quel caso il fix non è “riavviare più forte”, ma usare systemd user service o lingering in modo corretto.

Il terzo errore è il desktop che si apre ma non risponde bene, con lentezza evidente. Qui il collo di bottiglia può essere la CPU della VM, il rendering software o una risoluzione troppo alta per l’hardware disponibile. Prima di cambiare protocollo, misura il carico:

top
free -h
journalctl --user -u vncserver@1.service -b

Se la macchina è piccola, GNOME è già pesante di suo. Su ambienti con risorse limitate, un desktop più leggero può essere più sensato di una sessione GNOME forzata dentro VNC. Non è un fallimento della configurazione: è un limite di ergonomia tra stack grafico e risorse disponibili.

Hardening minimo senza complicare la vita

Per un uso serio, alcune misure sono quasi obbligatorie. Prima di tutto: password VNC robusta, accesso solo via SSH tunnel, porta VNC non pubblica e account utente senza privilegi amministrativi inutili. Se il servizio gira su una macchina condivisa, separa bene gli account e non usare root per comodità.

Un controllo minimo di audit utile è questo:

ss -ltnp | grep 5901
sudo ufw status verbose
systemctl --user status vncserver@1.service

Se la porta è in ascolto su `0.0.0.0` e non hai tunnel o firewall, stai esponendo troppo. Se vuoi una superficie più stretta, fai ascoltare solo localhost e usa SSH forwarding. In molti casi è la scelta migliore anche per semplicità operativa.

Variante con desktop remoto integrato di GNOME

Su alcune versioni di Ubuntu e GNOME, il desktop remoto è già integrato nelle impostazioni di sistema. È una strada valida se vuoi condividere la sessione esistente e ridurre il numero di componenti da mantenere. La logica è diversa: non avvii un server separato, ma abiliti la condivisione del desktop dalla UI.

Il percorso tipico è nelle impostazioni di sistema, sezione relativa a condivisione o desktop remoto. Da lì puoi abilitare la funzione, impostare password o autorizzazioni e decidere se consentire l’accesso remoto. La parte delicata resta la sicurezza: anche in questo caso preferisci accesso limitato e, se possibile, tunnel o rete fidata.

Questa variante è più semplice per l’utente finale, ma meno uniforme da amministrare quando hai più macchine o vuoi replica della configurazione. TigerVNC resta più adatto se ti serve una procedura ripetibile e documentabile in modo preciso.

Scelta pratica finale

Se ti serve un server VNC su Ubuntu con GNOME che sia davvero gestibile, la combinazione più equilibrata è: sessione X11 dedicata, `xstartup` minimale, avvio con systemd user service e accesso attraverso SSH tunnel. È meno “magico” di una soluzione integrata, ma ti dà log, stato servizio e rollback chiaro.

La regola che evita il 90% dei problemi è banale: prima fai partire la sessione in locale, poi automatizza, poi apri l’accesso. Se inverti l’ordine, finisci a diagnosticare tre problemi insieme: desktop, servizio e rete. Con il flusso giusto, invece, ogni layer si controlla da solo e il tempo perso cala parecchio.

Assunzione operativa: i comandi sono pensati per Ubuntu recente con GNOME e TigerVNC; se la tua release differisce in modo sostanziale, verifica nome pacchetti, path dei log e comportamento di systemd user prima di applicare in produzione.