Como configurar desktop remoto em um VPS Linux

O que significa realmente um desktop remoto num VPS Linux

Existem dois produtos diferentes associados à pesquisa por "desktop remoto num VPS Linux", e escolher o produto errado pode consumir uma tarde. O primeiro é um intermediário de acesso remoto. O servidor self-hosted do RustDesk é o exemplo comum: encaminha 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 desenha nenhum desktop. Apenas apresenta os dois extremos e encaminha os pacotes quando não conseguem comunicar diretamente. O segundo é um desktop gráfico real em execução no servidor alugado. Nesse caso, os pixels são desenhados 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 está 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 você controla o par de chaves. Não protege a máquina controlada, que continua a ser o PC onde você instalou o cliente, com a palavra-passe definida nesse PC.
• xrdp através de um túnel SSH ou de uma VPN. Protege contra a varredura constante da Internet à porta TCP 3389 e contra tentativas de adivinhar a palavra-passe na interface de login do RDP, porque essa porta nunca fica exposta à Internet. Não protege uma palavra-passe de conta fraca contra quem já tem acesso ao túnel.
• VNC através do mesmo túnel. Fornece uma sessão de desktop que sobrevive a uma desconexão, usando um protocolo mais antigo e simples do que o RDP. Por si só, não protege nada: o túnel faz todo o trabalho de segurança, portanto 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 desktop completo num contentor que você 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, portanto o contentor não é um limite de segurança em que deva confiar para uma carga de trabalho hostil.

Instalar xrdp e XFCE no Ubuntu 24.04

A imagem de um servidor VPS não inclui um ambiente gráfico. Primeiro, instale um ambiente gráfico. Depois, instale 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 é normalmente a opção adequada.

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

O Ubuntu 24.04 inclui o xrdp 0.9.24 e o xorgxrdp no componente universe, em agosto de 2026. Instale xorgxrdp explicitamente pelo nome, embora seja apenas um pacote recomendado. É o backend do 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 devolve-o imediatamente à mesma caixa de início de sessão.

Agora, indique à sessão qual ambiente gráfico 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 disponibiliza 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 imprimir 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 conseguirá abrir a chave, e /var/log/xrdp.log registará a falha com o nome de ficheiro snakeoil na linha.

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

A porta TCP 3389 é continuamente sondada por tudo na internet, e uma caixa de login RDP responde educadamente a todas as tentativas de senha. Não a abra. Vincule o xrdp ao endereço de loopback e acesse-o por meio de 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 pode deixar o serviço silenciosamente em todos os endereços.

sudo systemctl restart xrdp
ss -tlnp | grep 3389

Você precisa de 127.0.0.1:3389. Ver 0.0.0.0:3389 significa que o xrdp ignorou sua alteração, geralmente porque a linha acabou em outra seção mais abaixo no arquivo.

Agora abra o túnel na 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 configure o cliente RDP para usar 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 informe 127.0.0.1 como computador. O FreeRDP solicita 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. Mova 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 cansativo. Para uma equipe, a melhor solução é uma rede privada. Coloque o servidor atrás de uma VPN WireGuard autogerenciada, 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 você não souber o 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 num VPS de 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 após o login no Ubuntu 24.04, baseados em comparações publicadas e não em medições no seu computador. Meça o seu próprio consumo com free -m logo depois de se ligar.

[
  {
    "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"
  }
]

Nos 5 desktops, a diferença é significativa. O LXQt fica perto de 300 MB e o XFCE perto de 400 MB, por isso ambos deixam espaço num sistema de 2 GB para um browser. O GNOME precisa de cerca de 1,200 MB antes de abrir uma única janela. Num sistema de 2 GB, isto faz com que o browser dispute com o desktop a memória restante.

O browser é o principal consumidor, não a shell do desktop. Um browser moderno utiliza entre 150 e 400 MB por separador ativo. Assim, um VPS de 2 GB com XFCE suporta alguns separadores e depois começa a usar swap. Adicione swap para que o sistema fique mais lento 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 killer de processos por falta de memória do kernel o terminou. O browser é normalmente a vítima.

A CPU é o outro limite e é fácil subestimá-lo. Um VPS não tem GPU, por isso o X recorre à renderização por software através do llvmpipe. Isto significa que a CPU desenha todos os pixels. Deslocar uma página pesada e reproduzir vídeo aparecem como carga normal da CPU. A taxa de fotogramas diminui, em vez de o sistema bloquear. Esse é o mesmo limite encontrado ao perguntar se é possível jogar num VPS: para qualquer conteúdo 3D, a resposta é não, precisamente por esse motivo.

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

O Ubuntu 24.04 usa PipeWire para o á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 produz som. O Ubuntu inclui 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. Reconectar 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 houver 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 Windows.

A área de transferência de texto funciona nos dois sentidos quando xrdp-chansrv está em execução na sua sessão. O xrdp inicia esse processo automaticamente. Confirme com pgrep -a xrdp-chansrv. Se copiar e colar deixar de funcionar durante uma sessão, esse processo terminou, e a reconexão inicia-o novamente. Copiar 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 de autorização 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 criar /etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla não produz efeito no 24.04. Crie antes 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 volte a ligar-se. Vale a pena conhecer outras duas falhas pelos sintomas.

A caixa de início de sessão aceita a palavra-passe e volta imediatamente a apresentá-la. A sessão iniciou-se e terminou. Leia primeiro /var/log/xrdp-sesman.log e, em seguida, ~/.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 sem permissões de escrita ou um disco cheio acabam todos neste ponto.

Liga-se e vê um ecrã cinzento com um cursor em forma de X. O X iniciou-se, mas o ambiente de trabalho não. Trata-se novamente de ~/.xsession: execute xfce4-session manualmente por SSH e leia o erro apresentado.

O que o servidor RustDesk auto-hospedado faz

O RustDesk é dividido 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 direta ponto a ponto falha. Nenhum dos dois executa um ambiente de trabalho. Ambos são fornecidos pela mesma imagem. 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 no primeiro arranque:

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.

O firewall tem de permitir diretamente estas portas. hbbs usa TCP 21115, 21116 e 21118, além de UDP 21116. 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

Os leitores que já terminam o TLS 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 fazer o encaminhamento, nem um pedido HTTP para analisar. Por isso, um bloco server do nginx ou um router HTTP do Traefik não tem nada com que fazer correspondência. 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 é um 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. Nesse caso, adicione regras de firewall para permitir que apenas o proxy aceda à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, tudo o que precisa é de um navegador limpo, com um IP que não muda, isolado da sua própria máquina. Um espaço 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 instalar 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 através do mesmo túnel SSH ou da mesma VPN que utilizou para o xrdp.

O Kasm Workspaces segue a mesma ideia, mas em escala muito maior. Inclui 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 normalmente disponibiliza. Em agosto de 2026, o requisito 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 o consegue executar. 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 inclui um canal de áudio. Continua a ser útil numa situação: quando pretende uma sessão de desktop que continue em execução depois de desligar e quer recuperar essa mesma sessão quando voltar. 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, pode criar 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 os dados depois disso. Numa porta pública, o conteúdo da sessão pode ser lido na rede.

Um VPS é uma boa máquina de desktop?

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

Como máquina descartável, é muito boa. As mesmas características explicam porquê. O endereço IP é estável e pertence a um data center, que é o que pretende quando um serviço precisa de ver um endereço consistente. A máquina é recriada a partir de uma imagem em minutos, por isso uma sessão que tenha instalado algo malicioso não lhe causa perdas. Está isolada do seu hardware real e continua a funcionar quando fecha o portátil. A faturação por hora torna barato um desktop temporário.

Se ainda está a determinar para que serve a máquina, vale a pena ler a lista prática do que um VPS faz bem antes de instalar um desktop nela. Se queria um desktop por causa de uma aplicação Windows, compare primeiro essa opção 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 numa 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 browser com alguns separadores. O GNOME ou o KDE Plasma numa VPS com 2 GB deixa quase nada para as aplicações. Adicione um ficheiro 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 out-of-memory killer do kernel.

Devo abrir a porta 3389 na firewall da minha VPS?

Não. A porta TCP 3389 é analisada constantemente, e uma interface de login RDP exposta permite tentativas de adivinhação de 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.

Porque é que o xrdp pede "Authentication is required to create a color managed device"?

O serviço colord pede permissão ao polkit, e o polkit concede essa ação silenciosamente apenas a uma sessão local. Uma sessão RDP não é considerada local, por isso é apresentado um pedido de palavra-passe em cada login. No Ubuntu 24.04, a correção antiga .pkla não tem efeito, porque o polkit 124 deixou de utilizar os ficheiros de autoridade local. 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 comecem por org.freedesktop.color-manager. e execute 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 fazer o encaminhamento. Além disso, a porta 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 estabeleçam ligação diretamente. As portas websocket 21118 e 21119, utilizadas pelo cliente web, usam HTTP e podem ficar atrás de um proxy. Nesse caso, configure a firewall para permitir o acesso apenas ao proxy, porque o hbbs confia em X-Real-IP nessas ligações.

Porque não existe som na minha sessão xrdp?

O Ubuntu 24.04 utiliza PipeWire, enquanto o redirecionamento de som do xrdp foi criado para 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 faça login 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 com um nome que indique xrdp. Confirme também que o cliente solicita áudio. No xfreerdp3, isto corresponde à flag /sound. No cliente Windows, corresponde à opção "Remote audio".