Installare un server VNC su AlmaLinux 9 e Rocky Linux

Su AlmaLinux 9 e Rocky Linux 9 la strada più pulita per VNC è TigerVNC con una sessione dedicata per utente, avviata via systemd e esposta solo dove serve. La differenza tra una configurazione che regge e una che crea problemi dopo due giorni sta tutta in tre punti: scegliere un desktop leggero, legare il servizio all’utente giusto e non lasciare il display aperto su rete senza protezioni.

VNC non è un sostituto del desktop remoto “sicuro” di per sé. Trasporta schermate e input, non ti risolve autenticazione forte, cifratura end-to-end o segmentazione. Per questo, su una macchina Linux moderna, la scelta sensata è: sessione VNC locale, accesso ristretto da firewall o, meglio ancora, tunnel SSH o VPN. Se devi darlo a un team interno, il requisito minimo è sapere chi entra, da dove entra e come spegnerlo in fretta.

Scelta del pacchetto e del desktop

Su RHEL-like 9 la combinazione più stabile è TigerVNC più un ambiente leggero come Xfce o MATE. GNOME via VNC funziona in certi scenari, ma tende a essere più pesante e meno prevedibile se stai lavorando su server con risorse limitate. Se l’obiettivo è amministrazione remota, non una postazione grafica completa, conviene stare essenziali.

Il punto non è “avere un desktop”, ma avere una sessione X avviabile senza dipendere da login fisico. TigerVNC ti mette a disposizione un display virtuale, ad esempio :1, che corrisponde tipicamente alla porta TCP 5901. Ogni display aggiuntivo aggiunge 1 alla porta base 5900.

Pacchetti necessari su AlmaLinux 9 e Rocky Linux 9

Installa i pacchetti base e, se serve, un desktop leggero. Con Xfce il profilo resta semplice e poco esigente in RAM.

sudo dnf install -y tigervnc-server xorg-x11-fonts-Type1 xorg-x11-fonts-misc dbus-x11 xterm

Se vuoi Xfce:

sudo dnf install -y @xfce-desktop-environment

In alternativa, se il repository del gruppo desktop non è disponibile o vuoi tenere il sistema più pulito, puoi installare i pacchetti del desktop specifico che usi già in standard aziendale. Il criterio resta lo stesso: la sessione VNC deve puntare a un comando di avvio coerente con quel desktop.

Creare l’utente e definire il display

La configurazione migliore è per utente, non “globale”. Evita di usare root. Ti serve un account amministrativo normale, con privilegi elevati solo quando servono. Se il server è condiviso, ogni utente deve avere il proprio display e la propria password VNC.

Supponiamo di voler usare l’utente admin e il display :1. Il file di mappatura dei display su RHEL-like è /etc/tigervnc/vncserver.users.

sudo tee /etc/tigervnc/vncserver.users >/dev/null <<'EOF'
:1=admin
EOF

Questo file dice al servizio systemd quale utente associare al display. Se vuoi più sessioni, puoi aggiungere altre righe, ad esempio :2=altro_utente. Il vantaggio è che il mapping resta leggibile e non sparso in script artigianali.

Password VNC e file di sessione

Accedi come utente destinato alla sessione e imposta la password VNC. La password non va salvata in chiaro in documentazione, ticket o note operative non protette. Se la devi condividere, usa un canale sicuro e pianifica la rotazione.

su - admin
vncpasswd

Il comando crea di norma ~/.vnc/passwd. Verifica che i permessi siano stretti:

ls -l ~/.vnc/passwd

Atteso: accesso solo per l’utente proprietario. Se il file è troppo permissivo, correggi subito con chmod 600 ~/.vnc/passwd. Questo non è un dettaglio estetico: un file password leggibile da altri utenti è un incidente in attesa di accadere.

Ora definisci lo старт della sessione grafica. Il file più comune è ~/.vnc/xstartup. Per Xfce, un esempio essenziale è questo:

#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
exec startxfce4

Rendi eseguibile il file:

chmod +x ~/.vnc/xstartup

Se usi un altro desktop, il comando finale cambia. Il principio non cambia: il file deve avviare il tuo ambiente grafico e terminare con exec, così il processo principale diventa quello della sessione desktop e non un wrapper inutile.

Abilitare il servizio systemd

Su AlmaLinux e Rocky Linux 9 TigerVNC usa unità systemd template. Il servizio effettivo dipende dal display. Per il display :1 il nome tipico è vncserver@:1.service.

Prima di avviare, conviene verificare il file di configurazione e il mapping utente. Poi abilita e avvia:

sudo systemctl daemon-reload
sudo systemctl enable --now vncserver@:1.service

Controlla lo stato:

systemctl status vncserver@:1.service

Atteso: active (running). Se il servizio fallisce, il log più utile è quasi sempre quello di systemd:

journalctl -u vncserver@:1.service -b --no-pager

Gli errori più comuni sono tre: display già occupato, file xstartup non eseguibile, desktop non installato o comando errato. Non partire a toccare firewall e porte se il processo non sale localmente: prima fai funzionare la sessione sul loopback del sistema.

Firewall: aprire solo ciò che serve

La porta VNC standard per :1 è 5901/tcp. Aprirla verso tutta Internet è quasi sempre una cattiva idea. Se devi esporla, limita l’origine. Se non puoi limitare l’origine, usa almeno una VPN o un tunnel SSH e non pubblicare il servizio direttamente.

Per un test locale o in rete interna, puoi aprire la porta con firewalld:

sudo firewall-cmd --permanent --add-port=5901/tcp
sudo firewall-cmd --reload

Verifica la regola attiva:

sudo firewall-cmd --list-ports

Se il server è in produzione, la verifica minima non è “la porta è aperta”, ma “la porta è raggiungibile solo dal segmento previsto”. Un controllo rapido lato client può essere:

nc -vz server.example.com 5901

Se il test passa da una rete non autorizzata, il blast radius è già troppo ampio. In quel caso chiudi la porta e restringi l’accesso prima di andare oltre.

Accesso sicuro: tunnel SSH invece di VNC esposto

La configurazione più pulita, quando hai accesso SSH, è lasciare VNC in ascolto localmente e inoltrare la porta via SSH. In questo modo l’autenticazione e la cifratura le gestisce SSH, mentre VNC resta confinato sul server.

Dal client:

ssh -L 5901:127.0.0.1:5901 admin@server.example.com

Poi il client VNC si collega a 127.0.0.1:5901. Se questa è la tua modalità operativa, puoi anche non aprire la porta nel firewall pubblico. È una scelta che riduce superficie d’attacco e semplifica l’audit.

Per ambienti con più operatori, una VPN aziendale o un bastion host restano preferibili a pubblicare VNC direttamente. VNC ha senso come layer applicativo interno; non come servizio esposto senza contesto.

Controllo della sessione e verifica funzionale

Dopo l’avvio, verifica che il processo sia effettivamente in ascolto:

ss -ltnp | grep 5901

Atteso: una riga con LISTEN sulla porta 5901 e il processo associato a Xtigervnc o equivalente. Se non compare, il servizio potrebbe essere partito e caduto subito dopo: in quel caso i log di journal restano la fonte primaria.

Se vuoi confermare il lato applicativo, connettiti dal client VNC e osserva se la sessione apre il desktop previsto. Una schermata nera o un loop di riconnessione spesso indica che il comando in xstartup termina subito, o che il desktop non trova i componenti DBus/X richiesti.

Un test utile è lanciare manualmente, come utente della sessione, il comando che il file xstartup esegue. Se il desktop non parte neppure a mano, il problema non è VNC ma l’ambiente grafico sottostante.

Risoluzione dei problemi tipici

Se il servizio non parte, la sequenza più efficiente è questa: prima stato del servizio, poi log, poi file di configurazione. In pratica:

systemctl status vncserver@:1.service
journalctl -u vncserver@:1.service -b --no-pager
cat /etc/tigervnc/vncserver.users
ls -l /home/admin/.vnc/xstartup /home/admin/.vnc/passwd

Se vedi errori di autenticazione o permessi, controlla proprietà e modalità della directory ~/.vnc. Se vedi “session startup via xstartup exited too early”, il contenuto dello script non è coerente con il desktop installato. Se vedi “port already in use”, un’altra istanza è già attiva o il display è stato lasciato sporco da un crash precedente.

In caso di display bloccato, prima di cancellare file a caso verifica chi sta usando la porta:

sudo lsof -iTCP:5901 -sTCP:LISTEN

Se il processo è orfano, fermalo con criterio:

sudo systemctl stop vncserver@:1.service

Solo dopo, se necessario, valuta la rimozione del lock del display o la pulizia della directory ~/.vnc. Farlo prima di capire chi tiene la porta è il modo più veloce per trasformare un problema reversibile in un rebus.

Hardening minimo sensato

Se VNC resta in uso per più di un test temporaneo, applica almeno queste regole: niente root, niente porta pubblica senza filtro sorgente, password ruotata periodicamente, servizio solo quando serve. Se il server è multiutente, separa chiaramente i display e documenta quale utente corrisponde a quale sessione.

Il controllo minimo di esposizione può essere fatto anche con un semplice audit della socket:

ss -ltnp | grep 590

Se trovi ascolto su 0.0.0.0 e non era previsto, hai già un dato utile per il rollback: restringere bind e accesso prima di lasciare il servizio in esercizio. Dove possibile, preferisci il bind su localhost e l’accesso tramite SSH.

Sequenza consigliata in ambiente reale

Se vuoi una procedura lineare che riduca gli errori, usa questa sequenza: installa i pacchetti, crea il mapping display-utente, imposta la password, prepara xstartup, avvia il servizio, verifica il log, poi decide se esporre la porta o incapsularla in SSH. Invertire i passi spesso porta a fare troubleshooting di rete quando il problema è a monte, nella sessione grafica.

Questa impostazione funziona bene sia su server singoli sia su ambienti di supporto interni. La parte importante non è “far comparire il desktop”, ma farlo in modo ripetibile, reversibile e con superficie d’attacco ridotta. Se il contesto cambia, per esempio più utenti, accesso remoto esterno o policy di compliance, la stessa base resta valida ma va adattata con più attenzione a rete, logging e segregazione degli account.