“Installare uno strumento di desktop remoto” è una sola frase su Windows e all’incirca quattro decisioni su Linux. Una configurazione funzionante di desktop remoto su Linux dipende da quale famiglia di protocolli scegli, da quale server grafico esegue la macchina di destinazione, da quale ambiente desktop ci gira sopra e da cosa intendi davvero per “desktop remoto” — supporto ad hoc per un utente non tecnico, accesso non presidiato a un server oppure una sessione persistente per il tuo uso da un’altra stanza.
La maggior parte delle guide al desktop remoto su Linux sceglie un solo percorso e lo presenta come la soluzione. Il risultato sono lettori che seguono le istruzioni alla lettera e finiscono con schermi neri, perché la guida dava per scontato X11 e loro usano Wayland, oppure dava per scontato GNOME e loro usano XFCE. Questa guida illustra le migliori soluzioni di desktop remoto per Linux per ogni combinazione, così ottieni una configurazione che funziona davvero sulle tue macchine invece di una che sembra corretta finché non la provi.
Scelte rapide per il desktop remoto su Linux
• Da Linux a Linux su LAN o WAN lenta: X2Go. Efficiente con poca banda, cifratura SSH predefinita, persistenza della sessione. Installare XFCE sulla destinazione.
• Supporto per utenti non tecnici: HelpWire. Avvio tramite link, nessuna configurazione lato utente.
• Accesso non presidiato senza implementare xrdp o X2Go: HelpWire. Approvazione dell’utente una tantum, riconnessione su richiesta. Accesso completo alla schermata di accesso su X11; limitato alle sessioni già attive su Wayland.
• Client Windows che si connettono a Linux: xrdp + XFCE. Nessuna installazione lato client su Windows. Usare Xorg sul server.
• Accesso ad alte prestazioni per singolo utente: NoMachine. Migliore qualità di rendering; il piano gratuito copre una connessione per macchina.
• GNOME su Wayland (Ubuntu 24.04+, Fedora 40+): GNOME Remote Desktop. Nativo, gestisce la schermata di accesso tramite GDM.
• KDE Plasma 6 su Wayland: KRdp. RDP Wayland nativo; in fase di maturazione nei casi limite.
I due strati che determinano ciò che funziona
Una configurazione di desktop remoto Linux è il risultato di due scelte indipendenti. Sbagliarne anche solo una comporta sessioni vuote, input che non viene rilevato o errori di compatibilità lenti da individuare.
• Livello 1 — Famiglia di protocolli. Quale formato di trasmissione utilizza la sessione e quindi quali client possono connettersi, quanta larghezza di banda richiede e come si comporta su reti di scarsa qualità.
• Livello 2 — Server di visualizzazione. Che cosa è in esecuzione sulla macchina di destinazione — X11 o Wayland — e quindi che cosa uno strumento remoto è autorizzato a vedere e controllare.
Ogni strumento citato più avanti in questo articolo è in realtà una combinazione specifica di questi due livelli. Capirli separatamente rende ovvie le scelte degli strumenti.
Livello 1: Famiglia di protocolli
Tre protocolli coprono la maggior parte delle implementazioni reali di desktop remoto su Linux. Esiste anche il forwarding X11 tramite SSH, ma incanala singole applicazioni anziché intere sessioni desktop ed è fuori ambito qui.
VNC (Virtual Network Computing) è l’opzione più antica e più ampiamente supportata. Acquisisce il contenuto dello schermo come dati di pixel e lo invia al client. Quella semplicità gli conferisce una compatibilità quasi universale; esistono client per Windows, macOS, Linux, Android, iOS e il browser, ma trasmette più dati per fotogramma rispetto ai protocolli più recenti, il che penalizza su collegamenti congestionati o ad alta latenza. Su una LAN la differenza è di solito accettabile. TigerVNC è l’implementazione più adatta all’uso in produzione.
RDP (via xrdp) è un server RDP open source che consente alle macchine Linux di accettare connessioni dal client Desktop remoto integrato in Windows. Si integra con PAM di Linux per l’autenticazione e supporta la crittografia TLS. Per ambienti misti in cui gli amministratori Windows devono raggiungere server Linux senza installare software client aggiuntivo, è l’opzione con il minor attrito. Un dettaglio da conoscere prima di distribuirlo: per impostazione predefinita, xrdp fa da proxy tramite una sessione VNC interna (XVnc) anziché effettuare il rendering nativamente su RDP, e tale livello di conversione è una fonte comune di lamentele sulle prestazioni. Il backend xorgxrdp si integra direttamente con Xorg e in genere offre prestazioni migliori, ma richiede Xorg invece di Wayland.
NX utilizza compressione e memorizzazione nella cache dei frame per ridurre i dati trasmessi durante una sessione. Richiede sensibilmente meno larghezza di banda rispetto a VNC e si comporta meglio su collegamenti lenti. X2Go è la principale implementazione open source. NoMachine distribuisce una versione proprietaria che utilizza un’iterazione più recente dello stesso approccio. Gli strumenti basati su NX sono più sensibili alla latenza che al throughput puro — si comportano bene su connessioni a banda larga lente ma possono risultare lenti su collegamenti ad alta latenza, come quelli satellitari.
Livello 2: Compatibilità con il server grafico
È qui che il desktop remoto su Linux diventa complicato, ed è qui che in realtà si annida la maggior parte delle sorprese in cui si imbattono i lettori.
Wayland è ora il server grafico predefinito su diverse distribuzioni principali, tra cui Ubuntu 24.04 e Fedora 40. Il passaggio cambia ciò che gli strumenti di desktop remoto sono autorizzati a fare, e un numero significativo di guide di configurazione non lo affronta.
Con X11, strumenti come xrdp potevano iniettare un display virtuale collegando un modulo al processo del server Xorg. Wayland non espone tale interfaccia. L’acquisizione dello schermo e il controllo dell’input su Wayland sono mediati dal compositor tramite PipeWire e il framework xdg-desktop-portal, e qualsiasi applicazione che li richieda deve passare attraverso il portale. La prima volta che si effettua una connessione remota, il portale mostra una richiesta di autorizzazione chiedendo all’utente locale di autorizzare la condivisione dello schermo, il controllo dell’input e l’accesso agli appunti. Questo è il comportamento previsto, non un bug.
La conseguenza della schermata di autenticazione. I compositor Wayland non espongono il greeter (la schermata di accesso) al portale. Ciò significa che l’accesso non presidiato, cioè raggiungere una macchina prima che un utente abbia effettuato l’accesso, funziona solo su X11, oppure tramite integrazioni specifiche del compositor come il supporto GDM di GNOME Remote Desktop. Si tratta di un vincolo a livello di sistema operativo che interessa ogni strumento di desktop remoto su Wayland, non qualcosa che un fornitore specifico possa aggirare.
Verifica quale stai usando. Prima di risolvere qualsiasi problema di desktop remoto, conferma il tipo di sessione:
echo $XDG_SESSION_TYPE
Una risposta di wayland significa che xrdp e X2Go standard non funzioneranno senza passaggi aggiuntivi. Una risposta di x11 significa che i comandi di configurazione per quegli strumenti si applicano direttamente.
Note sulle versioni di Ubuntu. In Ubuntu 24.04 Wayland è il predefinito ma Xorg è ancora disponibile — fai clic sull’icona a forma di ingranaggio nella schermata di accesso di GDM prima di inserire le credenziali e seleziona Ubuntu on Xorg. Ubuntu 25.10 ha eliminato completamente Xorg, quindi nelle versioni più recenti il percorso Wayland è obbligatorio e gli strumenti che richiedono X11 semplicemente non si applicano.
Mettere insieme i due livelli
Le sezioni sugli strumenti che seguono sono meglio lette come risposte alla domanda “dato il mio protocollo e i vincoli del server di visualizzazione, cosa dovrei implementare?” Alcune combinazioni meritano di essere segnalate in anticipo:
• Se la destinazione esegue Wayland e vuoi accesso non presidiato alla schermata di login, le opzioni sono limitate — GNOME Remote Desktop con integrazione GDM, oppure passare la macchina a Xorg.
• Se la destinazione esegue X11 e il client è Windows, xrdp è quasi sempre la scelta giusta.
• Se la destinazione esegue Wayland con GNOME o KDE Plasma 6, preferisci le opzioni native (GNOME Remote Desktop, KRdp) rispetto ad aggiungere VNC al compositore.
• Se nessuno dei due endpoint è sotto il tuo controllo amministrativo, la scelta del protocollo conta meno della facilità di guidare un utente non tecnico attraverso la configurazione, e uno strumento basato su link come HelpWire è di solito l’unica strada praticabile.
I migliori strumenti di desktop remoto per Linux
xrdp + XFCE — Il più compatibile con i client Windows
xrdp in combinazione con XFCE è la configurazione di desktop remoto Linux più ampiamente compatibile disponibile. Accetta connessioni dal client Desktop remoto integrato di Windows, da Remmina su Linux e da Microsoft Remote Desktop su macOS e iOS, senza software aggiuntivo richiesto sul lato client.
Server di visualizzazione: Ideale per X11/Xorg. Nei sistemi basati su Wayland, è generalmente necessario passare la sessione a Xorg per sessioni affidabili.
Configurazione su Ubuntu 22.04 / Debian 12:
sudo apt update
sudo apt install xrdp xfce4 xfce4-goodies
echo xfce4-session > ~/.xsession
sudo adduser xrdp ssl-cert
sudo systemctl enable xrdp
sudo systemctl restart xrdp
sudo ufw allow 3389/tcp
Da Windows, apri Connessione desktop remoto, inserisci l’IP dell’host Linux e autenticati con le credenziali Linux.
Ottimizzazione delle prestazioni. Ridurre la profondità di colore in /etc/xrdp/xrdp.ini da 32 bit a 24 bit riduce la larghezza di banda con un impatto visivo minimo:
[Globals]
max_bpp=24
crypt_level=high
[Xorg]
xserverbpp=24
Applica con sudo systemctl restart xrdp.
Risoluzione dei problemi della sessione vuota. Uno schermo nero su Ubuntu 24.04 di solito significa che la sessione è passata in modo predefinito a Wayland. Disconnettiti, seleziona Ubuntu su Xorg dall’icona a forma di ingranaggio nella schermata GDM e riconnettiti. L’installazione di xorgxrdp migliora anche il rendering quando si esegue sotto Xorg.
Se XRDP non funziona su Ubuntu, verifica come risolverlo.
HelpWire — Supporto e accesso non presidiato senza configurazione
Gli strumenti sopra riportati presuppongono che un amministratore stia configurando entrambi gli endpoint. Questa ipotesi viene meno negli scenari di supporto IT in cui non ci si può aspettare che l’utente remoto configuri le regole del firewall o installi un componente server. HelpWire è progettato per questo caso e supporta anche l’accesso non presidiato su Linux.
Le sessioni vengono avviate tramite un link univoco: l’operatore crea un profilo client, invia il link e l’utente remoto installa l’app Client leggera e approva la richiesta.
Accesso non presidiato funziona in modo analogo, con una differenza — dopo un’approvazione una tantum, l’operatore può riconnettersi in qualsiasi momento in cui il dispositivo è acceso e online, anche se l’utente non sta utilizzando attivamente la macchina.
Distribuzioni supportate: Ubuntu 18.04–24.04 (DEB) e CentOS 8/9, Fedora 41 (RPM).
Server di visualizzazione: X11 e Wayland sono entrambi supportati, con una differenza importante. Su X11, l’accesso non presidiato include la schermata di accesso. Su Wayland, l’accesso non presidiato non include la schermata di accesso a causa di limitazioni a livello di sistema.
HelpWire è un servizio basato sul cloud e non una distribuzione self-hosted; pertanto, le organizzazioni che richiedono che tutto rimanga on-premises dovrebbero preferire xrdp o X2Go dietro una VPN.
X2Go — Opzione gratuita per LAN e WAN a bassa larghezza di banda
X2Go instrada il traffico di sessione tramite SSH, ereditando l’autenticazione SSH esistente e la configurazione del firewall. Nessuna porta aggiuntiva oltre la 22. Le sessioni persistono attraverso le disconnessioni e possono essere riprese senza perdere le applicazioni in esecuzione, il che è utile quando la connettività è intermittente. Sono supportati più utenti simultanei, ciascuno in una sessione isolata.
Server di visualizzazione: orientato a X11. Non è adatto ai desktop Wayland.
Compatibilità con gli ambienti desktop: XFCE e MATE funzionano in modo affidabile. GNOME su X2Go produce artefatti grafici e non è stabile per l’uso regolare — se il sistema di destinazione esegue GNOME, usa xrdp o NoMachine.
Configurazione del server:
sudo apt update
sudo apt install x2goserver x2goserver-xsession xfce4
Configurazione del client:
sudo apt install x2goclient
Crea un profilo di sessione con il nome host del server, il nome utente SSH e XFCE come tipo di sessione.
X2Go scarica parte del rendering sul client, il che può superare xrdp su server con risorse limitate.
X2Go — Opzione gratuita per LAN e WAN a bassa larghezza di banda
L’implementazione NX proprietaria di NoMachine gestisce la compressione dei frame, lo streaming adattivo e l’inoltro audio. In genere offre uno scorrimento e operazioni sulle finestre più fluidi rispetto a xrdp sulla stessa connessione. La configurazione è semplice e non richiede di configurare SSH o un gestore delle sessioni desktop separato.
Server di visualizzazione: Supporta i desktop Wayland, ma il comportamento varia in base all’ambiente desktop e alla versione.
Limite del livello gratuito: una connessione in ingresso simultanea per macchina. Gli scenari multiutente richiedono l’edizione Enterprise commerciale.
Uso delle risorse: CPU e memoria superiori rispetto a xrdp durante le sessioni attive, soprattutto in fase di connessione e con rendering complessi. Vale la pena eseguire una profilazione sui server con 2 GB di RAM o meno.
Installazione:
sudo dpkg -i nomachine_*.deb
sudo systemctl enable –now nxserver.service
NoMachine è in ascolto sulla porta 4000 per impostazione predefinita. Aprire la porta nel firewall se le connessioni proverranno dall’esterno della LAN.
GNOME Remote Desktop — RDP Wayland nativo per GNOME
Integrato nelle versioni moderne di GNOME. Implementa sia RDP che VNC, e GNOME ha aggiunto il supporto per l’accesso remoto tramite GDM nelle configurazioni supportate.
Questo è attualmente il percorso nativo Wayland più maturo per il desktop remoto su Linux, e l’impostazione predefinita corretta su sistemi GNOME su Ubuntu 24.04+ e Fedora 40+, dove passare a Xorg non è desiderabile o non è possibile.
KRdp — RDP Wayland nativo per KDE Plasma 6
KDE Plasma 6: server RDP nativo, configurabile in Impostazioni → Rete → Desktop remoto. Funzionale in Plasma 6 e in rapida maturazione, sebbene meno collaudato di GNOME Remote Desktop in configurazioni complesse.
Soluzioni di Desktop Remoto per Linux: Confronto completo
| Strumento | Protocollo | Supporto Wayland | Accesso non presidiato | Larghezza di banda | Multiutente | Configurazione | Costo |
| xrdp + XFCE | RDP | Solo X11 | Sì (tramite accesso al sistema operativo) | Moderata | Sì | Moderata | Gratuito |
| HelpWire | TLS (instradato via cloud) | Sì | Sì (Linux: mar 2026) | Moderata | Sì | Molto facile | Gratuito |
| X2Go | NX su SSH | Solo X11 | Sì (tramite accesso al sistema operativo) | Bassa | Sì | Moderata | Gratuito |
| TigerVNC | VNC | workaround wayvnc | Sì | Alta | Sì | Facile | Gratuito |
| NoMachine | NX (proprietario) | Parziale | Sì | Bassa | 1 gratuito | Facile | Gratuito / A pagamento |
| GNOME Desktop Remoto | RDP / VNC | Nativo | Sì (integrazione GDM) | Moderata | Limitato | Facile | Gratuito |
| KRdp | RDP | Nativo (KDE) | Limitato | Moderata | Limitato | Facile | Gratuito |
