Desktop remoto em VPS Linux com xrdp e XFCE

O que um desktop remoto num VPS Linux realmente significa

Dois produtos diferentes respondem à pesquisa por "desktop remoto num VPS Linux", e escolher o produto errado pode fazer perder uma tarde. O primeiro é um intermediário de acesso remoto. O servidor self-hosted do RustDesk é o exemplo comum: retransmite uma sessão entre duas máquinas que já possui, como o seu portátil e o PC de casa. O servidor alugado não apresenta qualquer desktop. Apenas apresenta os dois extremos um ao outro e encaminha pacotes quando não conseguem comunicar diretamente. O segundo é um desktop gráfico real executado no servidor alugado. Nesse caso, os pixels são processados no centro de dados e transmitidos para si. É o caso do xrdp, do VNC (virtual network computing) ou de um workspace num contentor.

Uma pergunta permite distingui-los. Depois de tudo funcionar, onde fica o ponteiro do rato? Se estiver numa máquina que já possui, precisa de um intermediário. Se estiver no próprio VPS, precisa de um desktop no VPS. A segunda situação ocupa a maior parte do conteúdo abaixo, porque é a que a maioria dos guias ignora.

Qual opção se adequa ao seu trabalho

• RustDesk com o seu próprio relay. Protege a sessão contra a passagem por um servidor público de rendezvous operado por terceiros, porque as chaves ficam sob o seu controlo. Não protege a máquina controlada, que continua a ser o PC onde instalou o cliente, com a palavra-passe que esse PC tiver.
• xrdp através de um túnel SSH ou de uma VPN. Protege contra a sondagem constante de toda a Internet à porta TCP 3389 e contra tentativas de adivinhar a palavra-passe na interface de início de sessão RDP, porque essa porta nunca fica exposta à Internet. Não protege uma palavra-passe de conta fraca contra alguém que já tenha acesso ao túnel.
• VNC através do mesmo túnel. Fornece uma sessão de ambiente de trabalho que sobrevive a uma desligação, usando um protocolo mais antigo e simples do que RDP. Por si só, não protege nada: o túnel faz todo o trabalho de segurança, pelo que o VNC sozinho numa porta pública é a pior opção aqui.
• Um workspace num contentor, como Webtop ou Kasm. Fornece um browser ou um ambiente de trabalho completo num contentor que pode eliminar e reconstruir, protegendo a sua máquina real contra o que esse browser aceder. Não protege o host: estas imagens são executadas com privilégios amplos e com um sudo sem palavra-passe no interior, pelo que o contentor não é um limite de segurança adequado para uma carga de trabalho hostil.

Instalar o xrdp e o XFCE no Ubuntu 24.04

A imagem de um servidor VPS não inclui um ambiente gráfico. Instale primeiro um ambiente gráfico e depois o xrdp, o servidor de código aberto que utiliza RDP (protocolo de ambiente de trabalho remoto), o mesmo protocolo utilizado pelo cliente do Windows. Escolha um ambiente leve. O XFCE é a opção habitual.

sudo apt update
sudo apt install -y xrdp xorgxrdp xfce4 xfce4-goodies dbus-x11
systemctl is-active xrdp

Em agosto de 2026, o Ubuntu 24.04 inclui o xrdp 0.9.24 e o xorgxrdp no componente universe. Instale xorgxrdp pelo nome, embora seja apenas um pacote recomendado. Este é o backend de servidor X que o xrdp inicia para uma nova sessão. Sem ele, a caixa de início de sessão aceita a palavra-passe e regressa imediatamente à mesma caixa de início de sessão.

Agora indique à sessão qual ambiente de trabalho deve iniciar. O xrdp executa /etc/xrdp/startwm.sh, que executa ~/.xsession quando esse ficheiro existe.

echo "xfce4-session" > ~/.xsession
chmod 644 ~/.xsession

Por fim, o xrdp precisa de ler a chave TLS (segurança da camada de transporte) que apresenta aos clientes. Esse ficheiro tem o modo 640 e pertence ao grupo ssl-cert.

ls -l /etc/ssl/private/ssl-cert-snakeoil.key
id xrdp

A listagem mostra -rw-r----- 1 root ssl-cert. Se id xrdp não apresentar ssl-cert entre os grupos, execute sudo adduser xrdp ssl-cert e depois sudo systemctl restart xrdp. Se ignorar este passo, o xrdp não consegue abrir a chave e /var/log/xrdp.log regista a falha com o nome do ficheiro snakeoil na linha.

Por que você não deve abrir a porta 3389 para a internet

A porta TCP 3389 é verificada continuamente por tudo o que está na internet, e uma caixa de login do RDP responde educadamente a cada tentativa de senha. Não a abra. Faça o xrdp escutar apenas no endereço de loopback e acesse-o por um túnel em que você já confia.

Edite /etc/xrdp/xrdp.ini e altere o listener na seção [Globals].

[Globals]
port=tcp://.:3389

O arquivo fornecido documenta essa sintaxe nos próprios comentários: tcp://.:3389 significa 127.0.0.1:3389, e tcp://:3389 significa todas as interfaces. Reinicie e confirme, porque um erro de digitação aqui deixa o serviço silenciosamente em todos os endereços.

sudo systemctl restart xrdp
ss -tlnp | grep 3389

Você quer 127.0.0.1:3389. Ver 0.0.0.0:3389 significa que o xrdp ignorou a sua alteração, normalmente porque a linha acabou sob outro cabeçalho de seção mais abaixo no arquivo.

Agora abra o túnel a partir da sua própria máquina.

ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com

-N significa "abrir a conexão, mas não executar nenhum comando", portanto a sessão existe apenas para transportar a porta. Deixe esse terminal em execução e aponte o cliente RDP para 127.0.0.1:3389. Em um cliente Linux, o software é o FreeRDP 3, cujo binário no Ubuntu 24.04 se chama xfreerdp3:

sudo apt install -y freerdp3-x11
xfreerdp3 /v:127.0.0.1:3389 /u:you /dynamic-resolution +clipboard /sound

No Windows, use o mstsc integrado e digite 127.0.0.1 como computador. O FreeRDP pede que você confie no certificado na primeira conexão e exibe Do you trust the above certificate? (Y/T/N), o que é esperado com o certificado snakeoil autoassinado.

Se o ssh responder bind [127.0.0.1]:3389: Address already in use, algo na sua própria máquina já está usando a porta 3389. Altere a extremidade local com ssh -N -L 13389:127.0.0.1:3389 you@vps.example.com e conecte-se a 127.0.0.1:13389.

Um túnel por pessoa se torna trabalhoso. Para uma equipe, a melhor opção é uma rede privada. Coloque o servidor atrás de uma VPN WireGuard autogerida, atribua-lhe o endereço do túnel 10.8.0.1 e defina port=tcp://10.8.0.1:3389 para que o xrdp responda apenas dentro da VPN. De qualquer forma, a regra de firewall para a porta 3389 não deve existir. Se não tiver certeza do que as regras atuais permitem, comece por noções básicas do firewall ufw em um VPS e verifique antes de se conectar, não depois.

Quanta RAM um desktop remoto usa numa VPS com 2 GB

O desktop escolhido determina se um plano de 2 GB é confortável ou impraticável. Os valores abaixo são números típicos arredondados da memória em uso logo depois do login no Ubuntu 24.04, obtidos de comparações publicadas e não medidos na sua máquina. Meça o seu próprio consumo com free -m logo depois de estabelecer a ligação.

[
  {
    "label": "LXQt",
    "idle_ram_mb": 300
  },
  {
    "label": "XFCE",
    "idle_ram_mb": 400
  },
  {
    "label": "MATE",
    "idle_ram_mb": 500
  },
  {
    "label": "KDE Plasma",
    "idle_ram_mb": 800
  },
  {
    "label": "GNOME",
    "idle_ram_mb": "1,200"
  }
]

Entre esses 5 desktops, a diferença é o ponto principal. O LXQt fica perto de 300 MB e o XFCE perto de 400 MB, deixando espaço suficiente numa máquina com 2 GB para um navegador. O GNOME precisa de aproximadamente 1,200 MB antes de abrir uma única janela. Numa VPS com 2 GB, isso faz o navegador disputar com o desktop a memória restante.

O navegador é o custo real, não a shell do desktop. Um navegador moderno usa entre 150 e 400 MB por separador ativo. Por isso, uma VPS com 2 GB e XFCE suporta alguns separadores e depois começa a usar swap. Adicione swap para que a máquina fique mais lenta em vez de terminar processos: sudo fallocate -l 2G /swapfile, depois sudo chmod 600 /swapfile, sudo mkswap /swapfile, sudo swapon /swapfile e uma linha correspondente em /etc/fstab para que a configuração sobreviva a um reboot. Quando algo desaparece sem aviso, execute dmesg | grep -i "killed process". Essa linha indica que o OOM killer do kernel terminou o processo. O navegador é normalmente a vítima.

A CPU é o outro limite, e é mais fácil subestimá-lo. Uma VPS não tem GPU. Por isso, o X recorre à renderização por software através do llvmpipe, o que significa que a CPU desenha cada pixel. Fazer scroll numa página pesada e reproduzir vídeo aparecem como carga normal da CPU. A taxa de frames diminui em vez de a máquina bloquear. Esse é o mesmo limite que encontra se estiver a perguntar se é possível jogar numa VPS: para qualquer tarefa 3D, a resposta é não, exatamente por esse motivo.

Som e área de transferência numa sessão xrdp

O Ubuntu 24.04 usa PipeWire para áudio, mas o redirecionamento de som do xrdp foi desenvolvido para PulseAudio. Por isso, uma instalação nova fornece vídeo funcional, mas não emite som. O Ubuntu disponibiliza a ponte necessária.

sudo apt install -y pipewire-module-xrdp pulseaudio-utils alsa-utils

Termine completamente a sessão RDP e inicie sessão novamente, porque o módulo é carregado quando a sessão começa. Uma reconexão não é suficiente. Depois, verifique a partir da sessão:

pactl list short sinks
speaker-test -c 2 -t wav -l 1

Deverá ver um sink cujo nome menciona xrdp e ouvir o tom de teste através do cliente. Se não existir um sink xrdp, o módulo não foi carregado nesta sessão. O cliente também tem de solicitar áudio: essa é a opção /sound em xfreerdp3 ou a definição "Remote audio" em Local Resources no cliente do Windows.

A área de transferência de texto funciona nos dois sentidos quando xrdp-chansrv está em execução na sua sessão, algo que o xrdp inicia automaticamente. Confirme com pgrep -a xrdp-chansrv. Se copiar e colar deixar de funcionar durante uma sessão, esse processo terminou. Uma reconexão inicia-o novamente. A cópia de ficheiros, em vez de texto, usa um canal separado chamado redirecionamento de unidades: /drive:home,/home/you em xfreerdp3 monta uma pasta local na sessão remota.

A janela do polkit e outras falhas no primeiro início de sessão

A surpresa mais comum no primeiro início de sessão é uma caixa de diálogo com a mensagem Authentication is required to create a color managed device. A causa é específica. O serviço colord pede autorização ao polkit. O polkit concede essa ação silenciosamente apenas a uma sessão que considera local. Uma sessão RDP não é considerada local. Por isso, o polkit pede uma palavra-passe. O Ubuntu 24.04 inclui o polkit 124, que removeu os ficheiros de autoridade local antigos .pkla. Por isso, qualquer guia que indique escrever /etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla não tem efeito no 24.04. Em vez disso, escreva uma regra JavaScript.

/* /etc/polkit-1/rules.d/45-allow-colord.rules */
polkit.addRule(function(action, subject) {
    if (action.id.indexOf("org.freedesktop.color-manager.") === 0 &&
        subject.isInGroup("sudo")) {
        return polkit.Result.YES;
    }
});

Execute sudo systemctl restart polkit e estabeleça a ligação novamente. Vale a pena conhecer outras duas falhas pelo respetivo sintoma.

A caixa de início de sessão aceita a palavra-passe e volta imediatamente a aparecer. A sessão iniciou-se e terminou. Leia primeiro /var/log/xrdp-sesman.log e depois ~/.xsession-errors no seu diretório pessoal. A ausência de xorgxrdp, um ~/.xsession que indique um ambiente de trabalho não instalado, um diretório pessoal onde não pode escrever ou um disco cheio acabam todos neste resultado.

Estabelece a ligação e vê um ecrã cinzento com um cursor em forma de X. O X iniciou-se, mas o ambiente de trabalho não. É novamente ~/.xsession: execute xfce4-session manualmente através de SSH e leia o erro apresentado.

O que o servidor RustDesk autoalojado faz

O RustDesk divide-se em dois processos. hbbs é o servidor de ID e rendezvous ao qual os clientes se registam, e hbbr é o relay que transporta a sessão quando uma ligação ponto a ponto direta falha. Nenhum dos dois executa um ambiente de trabalho. Ambos vêm da mesma imagem, e este é o ficheiro Compose publicado pelo projeto, com o endereço do relay alterado para o nome do seu próprio host:

services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:latest
    command: hbbs -r rustdesk.example.com:21117
    ports:
      - 21115:21115
      - 21116:21116
      - 21116:21116/udp
      - 21118:21118
    volumes:
      - ./data:/root
    restart: unless-stopped
  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    ports:
      - 21117:21117
      - 21119:21119
    volumes:
      - ./data:/root
    restart: unless-stopped

Inicie os serviços e leia a chave pública que o servidor gerou na primeira inicialização:

sudo docker compose up -d
sudo cat ./data/id_ed25519.pub

Cada cliente precisa do nome do seu host e dessa chave pública. Introduza ambos em Network settings no cliente RustDesk. A chave privada correspondente permanece em ./data/id_ed25519. Se eliminar o diretório de dados, o servidor gera um novo par de chaves. Nesse caso, terá de reconfigurar todos os clientes com a nova chave. Faça uma cópia de segurança desse diretório. Se esta passar a ser a forma usada pela sua equipa para aceder a todas as máquinas, em vez de ser apenas uma experiência de fim de semana, vale a pena seguir uma compilação dedicada do relay RustDesk para tratar as chaves Ed25519, usar tags de imagem fixas em vez de latest e ter em conta a largura de banda do relay que o seu plano acabar por cobrar.

A firewall tem de permitir diretamente estas portas. O hbbs usa TCP 21115, 21116 e 21118, além de UDP 21116. O hbbr usa TCP 21117 e 21119.

sudo ufw allow 21115/tcp
sudo ufw allow 21116/tcp
sudo ufw allow 21116/udp
sudo ufw allow 21117/tcp
sudo ufw allow 21118/tcp
sudo ufw allow 21119/tcp

Por que o RustDesk não funciona atrás do nginx ou do Traefik

Leitores que já terminam o TLS para tudo num único reverse proxy tentam esta configuração e falham. O hbbs e o hbbr usam os seus próprios protocolos binários sobre TCP e UDP, não HTTP. Não existe um cabeçalho Host para usar no encaminhamento nem um pedido HTTP para inspecionar. Por isso, um bloco server do nginx ou um router HTTP do Traefik não tem nada para corresponder. O listener UDP na porta 21116 não é HTTP em nenhuma camada.

Duas opções funcionam. O nginx pode encaminhar as portas TCP com um bloco stream. Isto é encaminhamento simples na camada 4, não um reverse proxy no sentido habitual. As portas 21118 e 21119 transportam os websockets usados pelo cliente Web do RustDesk. Como usam HTTP normal, podem ficar atrás do seu proxy. Se fizer isso, adicione regras de firewall para que apenas o proxy possa aceder às portas 21118 e 21119. O hbbs confia no cabeçalho X-Real-IP nas ligações websocket para determinar o endereço real do cliente.

Um navegador descartável num contentor

Por vezes, só precisa de um navegador limpo, com um IP que não muda, isolado da sua própria máquina. Um ambiente de trabalho num contentor faz isso com muito menos software instalado. O Webtop da LinuxServer é a opção mais leve:

services:
  webtop:
    image: lscr.io/linuxserver/webtop:latest
    container_name: webtop
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - /path/to/data:/config
    ports:
      - 127.0.0.1:3000:3000
      - 127.0.0.1:3001:3001
    shm_size: "1gb"
    restart: unless-stopped

A porta 3000 disponibiliza HTTP e a porta 3001 disponibiliza HTTPS. Pode aceder ao ambiente de trabalho num separador do navegador, sem precisar de um cliente RDP. As tags das imagens incluem XFCE, KDE, MATE e i3 em várias distribuições base. A documentação do próprio projeto é clara sobre o risco: o contentor tem acesso privilegiado ao host e inclui um terminal com sudo sem palavra-passe. Por isso, não deve ficar exposto à internet sem proteção. É também por isso que as portas acima estão associadas a 127.0.0.1, em vez de serem publicadas em todos os endereços. Aceda a este serviço pelo mesmo túnel SSH ou pela mesma VPN que utilizou para o xrdp.

O Kasm Workspaces segue a mesma ideia, mas numa escala muito maior, com uma consola web, contas de utilizador e contentores por sessão que são repostos quando a sessão termina. Precisa de mais recursos do que um VPS pequeno consegue disponibilizar. Em agosto de 2026, o mínimo documentado é de 2 núcleos de CPU, 4 GB de memória e 50 GB de SSD. Além disso, cada sessão de utilizador utiliza, por predefinição, 2 núcleos e 2768 MB. Um plano com 2 GB não consegue executá-lo. A instalação consiste em descarregar um ficheiro e executar um script:

cd /tmp
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.17.0.7f020d.tar.gz
tar -xf kasm_release_1.17.0.7f020d.tar.gz
sudo bash kasm_release/install.sh

VNC e os casos em que ainda é adequado

O VNC envia atualizações do framebuffer em vez de comandos de desenho. Por isso, parece mais pesado do que o RDP numa ligação lenta e não tem canal de áudio. Continua a ser adequado numa situação: quando pretende uma sessão de desktop que continue em execução depois de se desligar e quer recuperar a mesma sessão quando regressar. O TigerVNC faz isso. vncserver -localhost yes :1 associa o Xvnc a 127.0.0.1 na porta TCP 5901 e recusa ligações de qualquer outro local. Assim, cria o túnel exatamente como no xrdp, com ssh -N -L 5901:127.0.0.1:5901 you@vps.example.com. Nunca publique uma porta VNC. A maioria dos servidores VNC protege a palavra-passe durante o handshake, mas não protege o que vem depois. Por isso, numa porta pública, o conteúdo da sessão pode ser lido na rede.

Um VPS é um bom desktop?

Como máquina principal, não. Os motivos acumulam-se. Não existe GPU, por isso a CPU processa tudo. Cada tecla depende de uma ida e volta pela rede, e uma latência de 40 ms que parece aceitável numa sessão SSH é percetível num editor de texto. O vídeo é comprimido duas vezes: primeiro pelo site e depois pelo codificador RDP. Os seus ficheiros ficam num disco que não controla, e o uso intensivo do desktop consome uma franquia mensal de largura de banda dimensionada para um servidor web.

Como máquina descartável, é muito bom. As mesmas características explicam porquê. O endereço IP é estável e pertence a um centro de dados, que é o que precisa quando um serviço deve ver um endereço consistente. A máquina é reconstruída a partir de uma imagem em minutos, por isso uma sessão que tenha adquirido algo malicioso não lhe causa custos. Está isolada do seu hardware real e continua a funcionar quando fecha o portátil. A faturação por hora torna barato um desktop descartável.

Se ainda está a definir a finalidade da máquina, vale a pena ler a lista prática do que um VPS faz bem antes de instalar um desktop nela. E se queria um desktop por causa de uma aplicação Windows, compare primeiro essa necessidade com as diferenças reais entre Linux e Windows Server, porque a licença altera o custo da solução.

FAQ

Posso executar um ambiente de trabalho remoto num VPS com 2 GB?

Sim, com um ambiente de trabalho leve. O XFCE ou o LXQt utiliza aproximadamente 300 a 400 MB depois do login, o que deixa memória suficiente para um navegador com alguns separadores. O GNOME ou o KDE Plasma num sistema com 2 GB deixa quase nada para as aplicações. Adicione um ficheiro de swap de 2 GB para que a pressão de memória abrande a máquina em vez de terminar processos. Se algo desaparecer sem mensagem, consulte dmesg | grep -i "killed process" para verificar o mecanismo do kernel que termina processos por falta de memória.

Devo abrir a porta 3389 na firewall do meu VPS?

Não. A porta TCP 3389 é analisada constantemente, e uma caixa de login RDP exposta facilita tentativas de adivinhar palavras-passe. Defina port=tcp://.:3389 em /etc/xrdp/xrdp.ini para que o xrdp escute apenas em 127.0.0.1, confirme com ss -tlnp | grep 3389 e aceda através de ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com. Para mais de uma ou duas pessoas, associe o xrdp a um endereço WireGuard em vez do loopback.

Por que razão o xrdp pergunta "Authentication is required to create a color managed device"?

O serviço colord pede autorização ao polkit, e o polkit concede essa ação silenciosamente apenas a uma sessão local com utilizador presente. Uma sessão RDP não é considerada local, por isso aparece um pedido de palavra-passe em cada login. No Ubuntu 24.04, a correção antiga .pkla não produz qualquer efeito, porque o polkit 124 deixou de utilizar os ficheiros de autoridade locais. Crie /etc/polkit-1/rules.d/45-allow-colord.rules com uma regra JavaScript que devolva polkit.Result.YES para IDs de ação que começam por org.freedesktop.color-manager. e execute depois sudo systemctl restart polkit.

Posso colocar um servidor RustDesk autoalojado atrás do nginx ou do Traefik?

Não o serviço principal. O hbbs e o hbbr utilizam os seus próprios protocolos binários, em vez de HTTP, por isso não existe um cabeçalho Host para usar no encaminhamento. Além disso, o UDP 21116 não pode atravessar um proxy HTTP. Abra as portas TCP 21115 a 21119 e a porta UDP 21116 na firewall e permita que os clientes se liguem diretamente. As portas websocket 21118 e 21119, utilizadas pelo cliente Web, usam HTTP e podem ficar atrás de um proxy. Nesse caso, restrinja-as na firewall para que apenas o proxy lhes possa aceder, porque o hbbs confia em X-Real-IP nessas ligações.

Por que razão não há som na minha sessão xrdp?

O Ubuntu 24.04 utiliza o PipeWire, enquanto o redirecionamento de som do xrdp foi desenvolvido para o PulseAudio. Por isso, o áudio não funciona até instalar a bridge. Execute sudo apt install -y pipewire-module-xrdp, termine completamente a sessão e inicie sessão novamente. O módulo é carregado no início da sessão, e uma reconexão não o carrega. Verifique com pactl list short sinks se existe um sink cujo nome contenha xrdp. Confirme também que o cliente solicita áudio. No xfreerdp3, esta opção é a flag /sound; no cliente Windows, aparece como "Remote audio".