RustDesk blocca le connessioni su server pubblici: perché ora serve il login

RustDesk è una di quelle applicazioni che ha davvero rivoluzionato il mercato delle applicazioni per l’accesso remoto e il controllo a distanza di sistemi desktop, workstation, server e device mobili. In un altro articolo abbiamo visto come usarlo per amministrare da remoto dispositivi Android ed effettuarne lo screen mirroring.

A differenza di molte soluzioni commerciali, RustDesk (download) offre un controllo diretto sull’infrastruttura: chi lo utilizza può scegliere se appoggiarsi a server pubblici oppure gestire internamente l’intero flusso di connessione: ne parlavamo nella nostra guida a RustDesk.

Il software, scritto in Rust e distribuito con componenti leggeri e portabili, punta su prestazioni elevate e una superficie d’attacco ridotta. Non è un dettaglio secondario: proprio la scelta del linguaggio e l’assenza di dipendenze pesanti contribuiscono a limitare vulnerabilità comuni in altri strumenti simili.

Fin dalle prime versioni, RustDesk ha attirato amministratori di sistema e professionisti IT che cercavano un’alternativa concreta a piattaforme come TeamViewer o AnyDesk.

Perché RustDesk introduce il login obbligatorio

Molti utenti stanno segnalando la comparsa del messaggio seguente, non appena si tenta di stabilire una connessione remota con RustDesk, almeno nella configurazione standard che prevede l’uso di server pubblici:

Connection error. The connection is not allowed.

To help prevent scamming and potential botnet attacks, this public server currently requires users to log in before connecting. If botnet abuse continues, controlled devices may also need to authenticate, using a user-friendly approach suitable for headless environments and one-time support scenarios. Please log in first and try again.

RustDesk is designed as a self-hosted solution. This public server is provided for demo and testing purposes only – please do not use it for production or sensitive work.

L’introduzione del login obbligatorio per i server pubblici nasce da una necessità concreta: come spiegano i responsabili del progetto, l’obiettivo consiste nel ridurre l’abuso sistematico delle infrastrutture condivise. I maintainer di RustDesk hanno infatti osservato traffico anomalo, connessioni massive e tentativi automatizzati che sfruttavano i relay server senza alcuna limitazione.

RustDesk si basa su due componenti principali: hbbs, che si occupa di identificare e mettere in contatto i dispositivi e hbbr, che funge da relay, cioè da intermediario per instradare le connessioni quando i dispositivi si trovano dietro NAT. In assenza di un sistema di autenticazione, qualsiasi utente poteva sfruttare i server pubblici come infrastruttura centrale per stabilire sessioni remote, anche senza autorizzazione.

Con il login obbligatorio, il client che utilizza un server pubblico deve autenticarsi tramite un account Google, GitHub o Microsoft. In questo modo si introduce una forma minima di accountability: non è più possibile avviare sessioni anonime su infrastrutture condivise.

Come attivare il login per l’uso dei server pubblici RustDesk

Per continuare a usare i server pubblici RustDesk senza limitazioni, basta fare clic sui tre puntini a destra dell’indicazione ID (nella colonna di sinistra dell’interfaccia).

Una volta nelle Impostazioni di RustDesk, si deve scegliere Account quindi Login per poi autenticarsi con un account Google, GitHub o Microsoft.

Cosa significa l’invito a passare a una configurazione self-hosted

L’invito a passare a una configurazione self-hosted, nel caso di RustDesk, è una presa di posizione piuttosto concreta. Significa smettere di utilizzare server pubblici condivisi e iniziare a gestire in autonomia l’infrastruttura che regge le connessioni remote: il traffico, le chiavi e i meccanismi di instradamento non passano più da nodi gestiti da terzi.

L’introduzione del login obbligatorio sui server pubblici riduce l’anonimato e limita gli abusi. Ma i gestori di RustDesk sottolineano che i server pubblici non andrebbero utilizzati in produzione ma solo per utilizzi saltuari o di test.

Passare al self-hosting significa assumersi una responsabilità in più, ma anche guadagnare autonomia: si gestiscono direttamente aggiornamenti, sicurezza e disponibilità del servizio. Non è sempre un vantaggio assoluto: richiede tempo e competenze.

Tuttavia, RustDesk – anche grazie a Docker – risulta piuttosto semplice da installare e configurare. Di contro è necessario avere un server Linux sempre attivo e raggiungibile 24 ore su 24 per la gestione degli accessi remoti.

Preparazione del server e requisiti

Serve una macchina Linux raggiungibile da Internet; un VPS (Virtual Private Server) è più che sufficiente. Una configurazione tipica parte da Ubuntu 24.04 o Debian 12 con almeno 1 vCPU e 1 GB di RAM. Prima di installare qualsiasi componente conviene aggiornare il sistema e installare strumenti base come curl.

Le porte sono un punto critico: RustDesk utilizza TCP/UDP 21115, 21116, 21117 e 21118: vanno aperte nel firewall e, se presente, nel security group del provider. Senza questo passaggio la connessione con i client fallisce o risulta instabile.

Installazione con Docker

Il metodo più solido, e anche quello raccomandato nella documentazione ufficiale RustDesk, è l’utilizzo di Docker. Non è solo una scelta di comodità: serve a evitare problemi con NAT e IP interni che possono compromettere la comunicazione tra client.

Prima di tutto si prepara una directory dedicata, ad esempio /opt/rustdesk, che conterrà i dati persistenti; poi si crea un file docker-compose.yml (ne proponiamo uno consigliato, di seguito). La configurazione corretta prevede due servizi distinti, hbbs e hbbr, che condividono lo stesso volume dati.

version: '3'
services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbs
    command: hbbs
    volumes:
      - ./data:/root
    network_mode: host
    restart: unless-stopped
  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbr
    command: hbbr
    volumes:
      - ./data:/root
    network_mode: host
    restart: unless-stopped

A questo punto si avvia tutto con:

docker compose up -d

Al primo avvio, il servizio hbbs genera automaticamente le chiavi nella directory ./data. Il file id_ed25519.pub è fondamentale: contiene la chiave pubblica che i client devono utilizzare per autenticarsi sul server.

La modalità host, specificata nel file docker-compose.yml, non è un dettaglio opzionale. Permette ai container di vedere l’indirizzo IP reale dei client invece di un IP interno Docker come 172.x.x.x. Senza questa configurazione, debug e gestione delle connessioni diventano più complessi.

Verifica immediata dopo l’avvio

Dopo il deploy conviene controllare subito che tutto funzioni. Il primo controllo è la presenza dei file nella directory ./data: se la chiave pubblica non è presente, significa che hbbs non è partito correttamente.

Subito dopo si controllano i log con i comandi docker logs hbbs e docker logs hbbr.

Infine si passa al test reale: si configura un client con indirizzo IP del server e chiave pubblica e si verifica che riceva un ID. Se questo passaggio funziona, l’infrastruttura è operativa.

Distribuzione client preconfigurati: automazione e deployment rapido

Uno degli aspetti più pratici di RustDesk, purtroppo poco documentato, riguarda la possibilità di distribuire client già configurati. In pratica, si evita completamente la configurazione manuale lato utente finale: server e chiave sono impostati automaticamente al primo avvio.

Il metodo più immediato consiste nel rinominare l’eseguibile includendo i parametri di configurazione. RustDesk interpreta il nome del file e applica le impostazioni al lancio. Un esempio concreto: rustdesk-host=rust.esempio.it,key=ABC123xyz.exe

In questo modo il client si collega direttamente al server specificato utilizzando la chiave pubblica indicata, senza richiedere intervento da parte dell’utente.

Un’alternativa più esplicita utilizza la riga di comando: l’eseguibile di RustDesk può essere avviato con parametri che impostano la configurazione in modo persistente, come nel comando che segue.

rustdesk.exe --set-config "id_server=indirizzo_server,key=chiave_pubblica"

Questa modalità è particolarmente utile in ambienti automatizzati: script di provisioning, GPO Windows o sistemi di deployment software possono integrare facilmente questo comando. In pratica, si inserisce RustDesk in un flusso di installazione già esistente.

Va detto però che entrambe le soluzioni introducono una punto delicato: la chiave pubblica e l’indirizzo del server diventano parte del pacchetto distribuito. Ciò richiede attenzione nella gestione delle versioni e nella rotazione delle chiavi: se si cambia server o chiave, bisogna ridistribuire i client.