RDP è la strada più pulita quando devi amministrare un PC Windows da Ubuntu senza complicarti la vita con soluzioni invasive. Se il desktop remoto è già abilitato sul lato Windows, da Linux ti basta un client solido, una rete che non perda colpi e qualche controllo preliminare su account, firewall e versione del sistema. Il punto non è solo “connettersi”: è farlo in modo ripetibile, sicuro e con un minimo di diagnosi quando qualcosa non torna.
Che cosa serve davvero prima di aprire la sessione
La connessione RDP funziona bene quando sono allineati tre elementi: il servizio sul PC Windows, la raggiungibilità di rete e il client su Ubuntu. Se uno di questi manca, il sintomo cambia: rifiuto immediato, timeout, finestra nera, credenziali respinte o disconnessione dopo l’autenticazione. Conviene partire dal presupposto più semplice: il PC Windows deve accettare connessioni RDP e deve esserci un utente autorizzato a entrare.
Su Windows, la funzione “Desktop remoto” è disponibile nelle edizioni Pro, Enterprise e Education. Sulle edizioni Home non c’è il server RDP nativo per l’accesso in ingresso. È un limite strutturale, non un problema di Ubuntu. Se il PC remoto è Windows Home, la soluzione va cambiata: software di terze parti, accesso via console o upgrade dell’edizione.
Dal lato Linux, il client più usato in ambiente desktop è Remmina. È comodo, integra profili salvabili, supporta più protocolli e gestisce bene opzioni come risoluzione, qualità colore, clipboard e ridirezione delle unità. In alternativa, FreeRDP è ottimo da terminale quando serve automazione, test veloci o troubleshooting più preciso.
Abilitare RDP su Windows senza lasciare buchi inutili
Prima di collegarti, verifica che sul PC Windows il Desktop remoto sia attivo e che il firewall consenta il traffico in ingresso sulla porta 3389. Se il PC è in rete locale, questo basta. Se invece vuoi esporlo su Internet, il discorso cambia: non va pubblicato “nudo” sulla WAN. La scelta corretta è una VPN o un gateway dedicato. Esporre RDP direttamente è una superficie d’attacco che non conviene regalare a scansioni automatiche e tentativi di brute force.
In Windows 10/11 il percorso tipico è nelle impostazioni di sistema, sezione dedicata al desktop remoto. Una volta abilitato, annota il nome del PC o l’indirizzo IP e verifica che l’utente con cui accedi sia autorizzato. Se usi un account locale, conta anche il formato del nome: spesso serve NOMEPC omeutente. Con un account Microsoft, l’autenticazione può richiedere il formato e-mail oppure l’account locale associato, a seconda della configurazione.
Se vuoi ridurre i problemi, assegna al PC Windows un IP stabile nella LAN o una prenotazione DHCP sul router. È una misura piccola ma utile: evita di inseguire ogni volta un indirizzo diverso quando il lease cambia. Se non puoi farlo, usa almeno il nome host e verifica la risoluzione DNS locale.
Installare il client su Ubuntu
Su Ubuntu l’installazione di Remmina è lineare. Il pacchetto può essere installato dai repository ufficiali oppure via Snap, ma in contesti tecnici preferisco spesso il pacchetto della distribuzione per avere meno attrito con integrazioni desktop e dipendenze. La scelta migliore dipende da policy locali e versione del sistema.
sudo apt update
sudo apt install remmina remmina-plugin-rdp freerdp2-x11Il pacchetto remmina-plugin-rdp abilita il supporto RDP dentro Remmina. freerdp2-x11 è utile anche per avere il comando xfreerdp, che torna comodo quando vuoi testare la sessione fuori dall’interfaccia grafica.
Se il desktop è minimale o vuoi una soluzione da CLI, puoi lavorare direttamente con FreeRDP. In quel caso hai più controllo sui parametri e meno variabili GUI da inseguire.
Connessione con Remmina: il percorso più rapido
Remmina è la scelta giusta quando devi usare RDP con una certa frequenza. Ti consente di salvare profili, riutilizzare credenziali in modo controllato e regolare i dettagli della sessione senza digitare ogni volta tutto da zero. Il flusso base è semplice: nuovo profilo, protocollo RDP, host o IP, utente, password e opzioni grafiche.
- Apri Remmina e crea una nuova connessione RDP.
- Inserisci l’indirizzo IP o il nome host del PC Windows.
- Compila l’utente nel formato richiesto, per esempio
NOMEPC\utenteoppureutente. - Imposta la password e, se disponibile, salva la credenziale solo se il contesto lo consente.
- Scegli la risoluzione: finestra, schermo intero o dimensionamento dinamico.
- Avvia la sessione e osserva eventuali errori di handshake o autenticazione.
Se la finestra si apre ma il desktop non compare, non partire subito a cambiare dieci opzioni. Controlla prima se la sessione è in realtà attiva ma sta renderizzando male: capita con compositing, driver grafici o ridirezione schermo. In molti casi basta forzare una sessione con colore a 24 bit, disattivare effetti superflui o provare la modalità finestra invece del full screen.
Un dettaglio pratico: se usi più monitor, non sempre il client replica in modo perfetto la disposizione della macchina remota. Per troubleshooting iniziale conviene partire con un solo display e una risoluzione standard, poi alzare il livello di complessità solo dopo che la connessione base è stabile.
Connessione da terminale con xfreerdp
Quando vuoi capire se il problema è nel client grafico o nel servizio RDP, xfreerdp è più trasparente. Ti mostra meglio dove si interrompe il flusso: rete, negoziazione TLS, autenticazione o apertura sessione. È la scelta giusta per un test rapido e ripetibile.
xfreerdp /v:192.0.2.10 /u:utente /p:'password' /cert:ignore /dynamic-resolutionQui /cert:ignore serve solo per test in ambiente controllato o quando il certificato del server non è ancora sistemato. Non è una buona pratica da tenere come default se hai una PKI corretta o un certificato affidabile; in quel caso conviene validare il certificato e non ignorarlo. /dynamic-resolution aiuta quando vuoi adattare la finestra senza aprire una nuova sessione.
Se devi autenticarti con un account locale del PC Windows, puoi specificare il dominio locale o il nome macchina. Esempio:
xfreerdp /v:192.0.2.10 /u:NOMEPC\utente /p:'password' /cert:ignoreSe la password contiene caratteri speciali, occhio alla shell: usa apici singoli quando possibile, oppure passa da file sicuri o prompt interattivi se il contesto operativo lo richiede. Non lasciare segreti in chiaro nella history della shell più del necessario.
Problemi tipici e come leggerli senza perdere tempo
Quando RDP non funziona, il primo errore è quasi sempre interpretare male il sintomo. Una connessione che fallisce subito non è uguale a una connessione che si autentica e poi resta su schermo nero. Il punto di diagnosi cambia.
- Timeout o host irraggiungibile. Di solito è rete, DNS, routing o firewall. Verifica con
pingse consentito, ma soprattutto con una prova TCP sulla porta 3389. - Rifiuto immediato. Spesso il servizio RDP è spento, il firewall blocca o l’edizione Windows non supporta il server RDP.
- Credenziali respinte. Qui il problema è quasi sempre utente, formato del nome, account non autorizzato o policy di accesso remoto.
- Schermo nero dopo login. Può essere una sessione bloccata, un problema grafico, un profilo utente corrotto o una policy di gruppo che interferisce con la creazione del desktop.
Per la verifica minima sulla rete, da Ubuntu puoi fare un test della porta. Se la porta non risponde, non ha senso insistere sul client.
nc -vz 192.0.2.10 3389Atteso: connessione riuscita o risposta di porta aperta. Se vedi “refused”, il servizio non ascolta o il firewall lo blocca. Se vedi timeout, la strada è interrotta a monte: routing, firewall intermedio, host spento o filtro di rete.
Per capire se il PC Windows ascolta davvero, sul lato Windows puoi controllare il servizio e la porta in ascolto. Un controllo utile è questo, eseguito in PowerShell amministrativo:
Get-Service TermService
netstat -ano | findstr :3389TermService deve risultare in stato Running. Se non è attivo, RDP non può funzionare. Se la porta 3389 non compare in ascolto, il problema è ancora più a monte della sessione utente.
Impostazioni utili per qualità, clipboard e sicurezza
Una volta che la connessione base va, puoi rifinire il profilo. La clipboard bidirezionale è comoda, ma va valutata in ambienti sensibili. In reti aziendali può essere disabilitata per policy; in altri casi è accettabile, purché tu sappia che stai aprendo un canale di scambio dati tra locale e remoto.
La ridirezione delle unità locali è un’altra funzione utile ma da usare con criterio. Spostare file tra Ubuntu e Windows via drive mapping è pratico, però aumenta la superficie di scambio dati e può complicare audit e compliance. Se devi trasferire pochi file, spesso è meglio usare un canale esplicito e tracciabile, non una condivisione permanente.
Per le prestazioni, la metrica che conta davvero è la reattività percepita: tempo di apertura sessione, latenza nell’input e stabilità del frame rendering. Se sei su VPN o su link non eccellente, abbassa la qualità grafica, disattiva effetti inutili e limita il profilo colore. Su connessioni lente, l’RDP lavora meglio con una configurazione sobria che non con un desktop pieno di animazioni.
Sicurezza: non esporre RDP come se fosse un sito web
Il punto più importante è questo: RDP non va trattato come un servizio da pubblicare direttamente su Internet senza protezioni. La porta 3389 è costantemente scandita. Se devi accedere da fuori ufficio, la pratica corretta è una VPN, un jump host o un gateway con autenticazione forte e logging adeguato.
Al minimo, verifica che sul PC Windows siano attive politiche di autenticazione robuste, che gli account con accesso remoto siano pochi e che il firewall consenta RDP solo dai segmenti necessari. Se il contesto è domestico o piccolo ufficio, non per questo va abbassata la guardia: anche lì le esposizioni inutili sono un invito ai tentativi automatici.
Se usi password salvate nel profilo del client, proteggi il filesystem e la sessione utente di Ubuntu. Non è una misura glamour, ma è quella che evita di lasciare credenziali leggibili a chi ha accesso locale alla macchina. Se il rischio operativo lo richiede, preferisci un vault o una gestione centralizzata delle credenziali.
Una procedura pulita da seguire quando devi andare in produzione
- Conferma che il PC Windows supporti RDP e che l’utente sia autorizzato.
- Verifica raggiungibilità della porta 3389 dalla macchina Ubuntu con un test TCP.
- Prova la sessione con Remmina; se fallisce, ripeti con
xfreerdpper ottenere un errore più leggibile. - Se la connessione entra ma il desktop è nero o instabile, riduci complessità grafica e prova una sessione pulita.
- Se l’accesso arriva dall’esterno della LAN, sposta il problema sul fronte sicurezza: VPN, gateway o accesso mediato.
Un approccio del genere evita il classico ping-pong tra client, server e rete. Prima capisci il layer che si rompe, poi modifichi il minimo necessario. È il modo più efficiente per non confondere un problema di trasporto con un problema di autenticazione o con un desktop che non parte correttamente.
Quando RDP non basta più
Se devi fare assistenza continuativa, spesso conviene affiancare a RDP un sistema di gestione più strutturato: VPN per l’accesso, logging centralizzato, inventario delle macchine e una policy chiara sugli utenti autorizzati. RDP resta il canale operativo, ma non dovrebbe essere l’unico pezzo dell’architettura di accesso remoto.
Per un uso quotidiano da Ubuntu a Windows, però, resta una soluzione solida: semplice da mettere in piedi, veloce da testare e sufficientemente flessibile per la maggior parte degli scenari di amministrazione. La differenza la fa quasi sempre la disciplina iniziale: rete pulita, account corretti, client configurato bene e niente esposizioni inutili.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.