1 31/10/2026 10 min

RDP su Linux: quando ha senso davvero

Se devi accedere a un desktop Linux da remoto, RDP è una scelta sensata soprattutto quando ti serve compatibilità con client Windows, passaggi semplici per gli utenti e una soluzione che si integri bene con ambienti misti. La parte importante è questa: su Linux RDP non è “il desktop remoto nativo” del sistema, ma un servizio da installare e configurare sopra un desktop environment già presente. In pratica, il risultato dipende molto da quale stack grafico usi, da come gestisci le sessioni e da quanto vuoi esporre il servizio in rete.

Nel mondo Linux, il caso più comune è xrdp, che espone una sessione RDP e si appoggia a un ambiente desktop come Xfce, MATE o, con più attenzione, GNOME. Se l’obiettivo è amministrare una macchina headless, dare accesso a un utente remoto o creare un punto di supporto per help desk, RDP funziona bene. Se invece vuoi una soluzione “zero sorprese” su GNOME puro con Wayland, conviene verificare prima la compatibilità della distribuzione e della sessione grafica, perché non tutti gli ambienti si comportano allo stesso modo.

Architettura minima: cosa serve prima di aprire la porta 3389

Prima di toccare i pacchetti, chiarisci tre punti: quale desktop deve essere esposto, chi si collega e da dove passa il traffico. RDP su Linux non è solo “installo un demone e basta”: devi avere una sessione grafica funzionante, un utente con permessi corretti e una strategia di accesso sicura. La porta standard è 3389/TCP, ma esporla direttamente su Internet è una cattiva idea nella maggior parte dei casi.

Il percorso più pulito è questo: accesso RDP solo da rete interna, oppure tramite VPN, oppure dietro un gateway con regole restrittive. Se devi aprire il servizio verso l’esterno, almeno limita gli IP sorgenti, imposta autenticazione robusta e monitora gli accessi. In ambienti produttivi, la superficie d’attacco conta più della comodità iniziale.

Installazione di xrdp su distribuzioni Debian e Ubuntu

Su Debian e Ubuntu il pacchetto più usato è xrdp. In molti casi conviene affiancarlo a un desktop leggero, perché una sessione remota deve essere stabile prima ancora che “bella”. Xfce è spesso la scelta più prevedibile.

sudo apt update
sudo apt install xrdp xfce4 xfce4-goodies
sudo systemctl enable --now xrdp

Dopo l’installazione, verifica che il servizio sia attivo:

systemctl status xrdp --no-pager

L’output atteso è uno stato active (running). Se invece vedi failed, controlla subito i log del servizio e la configurazione del desktop scelto. Il punto critico non è quasi mai il demone RDP in sé, ma la sessione grafica che non parte correttamente.

Installazione su RHEL, AlmaLinux, Rocky e derivate

Su famiglie RHEL-like la disponibilità dei pacchetti può cambiare in base ai repository abilitati. In genere il flusso è simile, ma conviene verificare prima il nome esatto del pacchetto e la presenza di un desktop installato. Anche qui un ambiente leggero aiuta molto a ridurre problemi di compatibilità.

sudo dnf install xrdp
sudo systemctl enable --now xrdp

Se usi SELinux, non dare per scontato che tutto funzioni al primo colpo. In questi casi il debug va fatto guardando i log e gli audit denial, non disattivando SELinux “per provare”. Se devi cambiare policy o boolean, fallo in modo mirato e con rollback chiaro.

Desktop environment: perché Xfce spesso batte GNOME in remoto

Molti problemi con RDP su Linux nascono dal desktop environment, non da RDP. Xfce tende a essere più lineare perché ha meno dipendenze, meno integrazioni grafiche complesse e una sessione più prevedibile quando parte da un login remoto. GNOME può funzionare, ma richiede più attenzione a Wayland, sessioni utente e componenti grafiche specifiche della distro.

Se vuoi una configurazione semplice e ripetibile, imposta la sessione Xorg per l’utente remoto. In molti scenari basta definire il desktop da avviare in ~/.xsession o ~/.Xclients, a seconda della distribuzione e del display manager. Un esempio pratico per Xfce:

echo xfce4-session > ~/.xsession
chmod +x ~/.xsession

Non tutte le distro leggono lo stesso file nello stesso modo. Se la sessione non parte, controlla la documentazione del pacchetto xrdp della tua distribuzione e i log del login grafico. Il comportamento cambia tra ambienti con GDM, LightDM e SDDM.

Configurazione di xrdp: file utili e punti da non sbagliare

I file più importanti sono in genere /etc/xrdp/xrdp.ini e /etc/xrdp/sesman.ini. Il primo gestisce il listener RDP, il secondo la sessione utente. Prima di modificare, fai sempre una copia del file o tieni un diff pronto: è il modo più rapido per tornare indietro senza improvvisare.

sudo cp /etc/xrdp/xrdp.ini /etc/xrdp/xrdp.ini.bak
sudo cp /etc/xrdp/sesman.ini /etc/xrdp/sesman.ini.bak

Di solito il file xrdp.ini non richiede ritocchi pesanti per un uso base. Il punto delicato è verificare che il servizio ascolti sulla porta prevista e che il firewall consenta il traffico solo da dove serve davvero. Se vuoi cambiare porta, fallo consapevolmente e aggiorna anche le regole di rete e la documentazione operativa.

Per controllare su quali porte sta ascoltando il servizio:

ss -ltnp | grep 3389

Se non compare nulla, il servizio non è in ascolto oppure sta usando una porta diversa. In quel caso vai subito su log e unit systemd, non sulla parte grafica.

Firewall: aprire solo il necessario

Per un accesso RDP corretto non basta che il demone sia avviato: il firewall deve consentire la connessione. Su Ubuntu con UFW e su RHEL-like con firewalld il principio è lo stesso, ma cambia la sintassi. Apri solo la porta richiesta e solo sul perimetro previsto.

Con UFW:

sudo ufw allow from 192.0.2.0/24 to any port 3389 proto tcp
sudo ufw status numbered

Con firewalld:

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" port port="3389" protocol="tcp" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Il controllo finale è semplice: da un client autorizzato la porta deve risultare raggiungibile, da una sorgente non autorizzata no. Se non hai segmentazione di rete, almeno limita il traffico con ACL, VPN o security group del provider.

Login remoto: utente, password e sessione giusta

Quando apri la sessione RDP, il client chiede credenziali Linux normali, non un account speciale inventato per RDP. Questo è un vantaggio operativo, ma implica che permessi, shell e sessioni dell’utente devono essere coerenti. Se l’utente non ha una sessione grafica valida, si autentica ma poi vede schermo nero o logout immediato.

Un errore tipico è avere un desktop environment installato ma non associato correttamente all’utente remoto. Un altro è usare Wayland dove il backend RDP atteso non è quello compatibile con xrdp. In queste situazioni il sintomo è spesso un accesso riuscito seguito da una disconnessione rapida o da una finestra vuota. La verifica da fare è nei log della sessione e nei file di configurazione del desktop dell’utente.

Troubleshooting rapido: i sintomi più comuni

Se RDP non funziona, il primo passo è capire in quale layer si rompe il flusso: rete, servizio, autenticazione o sessione grafica. Non partire dalla reinstallazione. In cinque minuti puoi raccogliere abbastanza evidenza per evitare tentativi ciechi.

1. Il servizio è vivo? Controlla il demone e il socket di ascolto.

systemctl status xrdp --no-pager
ss -ltnp | grep 3389

Se il servizio è attivo ma la porta non ascolta, c’è un problema di binding o di avvio. Se la porta ascolta ma il client non collega, il problema è quasi sempre firewall, routing o policy di rete.

2. I log mostrano errori di sessione? Controlla i log del servizio e della sessione utente. I path possono variare, ma spesso trovi evidenza in /var/log/xrdp.log, /var/log/xrdp-sesman.log oppure nel journal.

journalctl -u xrdp -u xrdp-sesman --since "15 min ago" --no-pager

Se compaiono errori su Xorg, auth, display o permissions, hai già la direzione giusta. In molti casi il problema è un file di startup utente sbagliato o una sessione grafica incompatibile.

3. Il desktop scelto parte localmente? Accedi in locale o tramite console virtuale e verifica che lo stesso utente possa avviare la sessione grafica senza errori. Se non parte neppure localmente, RDP non c’entra: devi sistemare il desktop base prima di tutto.

Sicurezza: esporre RDP senza farsi male

RDP è comodo, ma è anche un servizio molto visibile e molto attaccato. La regola pratica è semplice: se puoi, non esporlo direttamente su Internet. Preferisci VPN, bastion host o accesso da sottoreti controllate. Se invece devi pubblicarlo, usa almeno segmentazione, limitazione per IP, password robuste e, dove possibile, un secondo fattore a monte del servizio.

Evita account condivisi. Su un server Linux con accesso remoto, il tracciamento degli accessi è parte della sicurezza, non un dettaglio amministrativo. Ogni utente deve avere il proprio account e, se possibile, permessi minimi. Se devi abilitare accessi amministrativi, separa l’uso quotidiano dall’uso privilegiato.

Occhio anche al server di desktop remoto in ambienti con dati sensibili: clipboard, trasferimento file e redirect periferiche possono diventare canali di esfiltrazione o di movimento laterale. Se il tuo scenario non li richiede, disabilitali o restringili. È una misura semplice che riduce il rischio operativo.

Prestazioni: come evitare una sessione lenta e inutilizzabile

Se il desktop remoto è lento, misura prima di cambiare impostazioni a caso. Le metriche utili sono latenza percepita, uso CPU della macchina, memoria disponibile e saturazione della rete. Un RDP “lento” può dipendere da un sistema già sotto carico, da un desktop environment pesante o da una qualità video troppo alta per la banda disponibile.

Le prime ottimizzazioni ragionevoli sono queste: usare un desktop leggero, ridurre effetti grafici, evitare sfondi animati, limitare risoluzione e profondità colore se il client lo consente. In un ambiente WAN o con banda incerta, un profilo più conservativo spesso migliora la reattività molto più di qualsiasi tweak avanzato.

Se hai un collo di bottiglia lato server, controlla anche swap, I/O disco e memoria resident. Un desktop remoto su macchina affamata di RAM degrada rapidamente, soprattutto quando l’utente apre browser pesanti o tool grafici multipli.

Client RDP: cosa usare da Windows, macOS e Linux

Dal lato client, il vantaggio di RDP è l’ampia compatibilità. Su Windows il client integrato è sufficiente nella maggior parte dei casi. Su macOS puoi usare il client Microsoft Remote Desktop o equivalenti. Su Linux ci sono client come Remmina o FreeRDP, utili quando vuoi testare connessioni, salvare profili o gestire più endpoint.

La cosa importante non è il nome del client, ma il comportamento: se la connessione fallisce, distingui tra problema di reachability, autenticazione e sessione. Un client diverso può aiutare a isolare il punto d’errore, ma non sostituisce i log lato server.

Una configurazione tipo che funziona nella pratica

Per un server Linux usato come desktop remoto interno, la configurazione più pragmatica è spesso questa: xrdp installato, Xfce come sessione, porta 3389 consentita solo dalla rete amministrativa, account utente separati e accesso preferibilmente via VPN. È una combinazione poco spettacolare ma solida, e soprattutto facile da mantenere nel tempo.

Se vuoi standardizzare l’installazione su più macchine, documenta sempre tre elementi: pacchetti installati, file modificati e regole firewall. In caso di incidente, queste tre informazioni ti fanno risparmiare più tempo di qualsiasi procedura generica. Un buon promemoria operativo può essere semplicemente un file di change con data, host, versione del sistema e differenze applicate ai file di configurazione.

Checklist finale prima del go-live

Prima di considerare chiusa la configurazione, verifica almeno questi punti: il servizio è attivo, la porta è raggiungibile solo dai segmenti previsti, la sessione grafica parte con l’utente corretto, i log non mostrano errori ricorrenti e il metodo di accesso è coerente con la policy di sicurezza del server. Se uno di questi elementi manca, la soluzione è ancora incompleta.

  • Servizio: systemctl status xrdp mostra active (running).
  • Rete: ss -ltnp | grep 3389 conferma l’ascolto e il firewall limita il traffico.
  • Sessione: il desktop remoto apre una sessione stabile, non uno schermo nero.
  • Sicurezza: accesso limitato per IP o via VPN, senza esposizione inutile.
  • Rollback: i backup di /etc/xrdp/xrdp.ini e /etc/xrdp/sesman.ini sono disponibili se serve tornare indietro.