O reencaminhamento X11 por SSH permite executar uma aplicação gráfica num servidor Linux e ver a respetiva janela na sua máquina local. Faz sentido quando precisa pontualmente de uma ferramenta gráfica e o seu cliente tem um servidor X. Use ssh -X por omissão, -Y apenas com servidores totalmente fiáveis, e defina X11Forwarding yes no sshd_config.

ssh -X vs ssh -Y: o que muda no reencaminhamento X11 do OpenSSH

ssh -X ativa o reencaminhamento X11 e trata as aplicações remotas como não fiáveis, sujeitas aos controlos da extensão X11 SECURITY. ssh -Y ativa o reencaminhamento X11 fiável e dispensa esses controlos. Em ambos os casos, o tráfego X vai cifrado dentro da sessão SSH e o servidor define DISPLAY para que as janelas cheguem ao seu ecrã.

A diferença tem a ver com segurança. A página de manual do ssh avisa que qualquer pessoa capaz de contornar as permissões de ficheiros no anfitrião remoto pode chegar ao seu ecrã local através da ligação reencaminhada e, por exemplo, monitorizar as teclas premidas. Com -Y esse acesso não tem restrições; com -X é limitado, à custa de algumas aplicações deixarem de funcionar.

  • Use -X por omissão e sempre em anfitriões partilhados ou servidores que não administra.
  • Use -Y apenas quando a aplicação falha com -X e confia totalmente no servidor.
  • Verifique ForwardX11Trusted no ssh_config global do sistema: algumas distribuições alteram-no e, nesse caso, -X comporta-se como -Y.

Como ativar X11Forwarding no servidor SSH e testá-lo

O servidor só aceita o reencaminhamento X11 quando /etc/ssh/sshd_config contém X11Forwarding yes e o programa xauth está instalado; se faltar algum dos dois, o pedido do cliente é recusado. Esta é a configuração mínima em ambos os lados:

# Server: /etc/ssh/sshd_config
X11Forwarding yes
X11UseLocalhost yes

# Check syntax and reload the service
sudo sshd -t
sudo systemctl reload sshd   # on Debian/Ubuntu the service is called ssh

# Client: one-off connection
ssh -X user@server
echo $DISPLAY                # something like localhost:10.0
xclock &

# Client: ~/.ssh/config
Host lab
    HostName lab.example.com
    User user
    ForwardX11 yes
    ForwardX11Trusted no

As diretivas documentadas do sshd_config cobrem o resto: X11UseLocalhost yes associa o ecrã reencaminhado apenas à interface de loopback do servidor, e X11DisplayOffset define o primeiro número de ecrã que o sshd atribui, daí o habitual :10. Quando algo falha, ssh -v -X user@server diz-lhe porquê:

  1. X11 forwarding request failed on channel 0: o servidor tem X11Forwarding no ou não tem xauth.
  2. Can't open display na aplicação: normalmente DISPLAY está vazio porque a sessão nunca pediu reencaminhamento, ou não há nenhum servidor X local em execução.

Reencaminhamento X11 em iOS e Android vs desktop: o que cada lado precisa

O reencaminhamento X11 precisa de um servidor X na máquina cliente, porque é essa máquina que desenha as janelas. Um desktop Linux costuma ter um; o macOS precisa do XQuartz instalado; um cliente SSH móvel é normalmente um terminal sem servidor X.

O que se medeDesktop com ssh -XTelemóvel iOS/AndroidAlternativa: túnel -L ou SFTP
Servidor X localObrigatório: X11, XWayland ou XQuartzNormalmente indisponível no terminalNão é necessário
Funciona com MoshO Mosh não reencaminha X11; precisa de SSHO Mosh mantém o terminal, sem janelas XO túnel -L precisa de SSH, não de Mosh
Mudança de wifi para dados móveisA sessão SSH e as suas janelas caemCom Mosh e tmux a sessão sobreviveO túnel volta a abrir-se; o tmux mantém os processos ativos
Risco para a máquina localCom -Y, acesso sem restrições ao ecrãNenhum ecrã X expostoSó a porta reencaminhada fica exposta
Melhor utilizaçãoFerramenta gráfica pontual numa rede estávelAdministração no terminal e ficheirosInterfaces web, gráficos e documentos

O termi1 é um terminal SSH, Mosh e SFTP, e o Mosh, por conceção, não faz reencaminhamento de portas nem reencaminhamento X11. O que resolve num telemóvel é outra coisa: manter a sessão ativa quando passa do wifi para os dados móveis e voltar ao tmux com tudo o que deixou a correr.

4 alternativas ao reencaminhamento X11 por SSH que funcionam a partir de um telemóvel

ssh -L reencaminha uma porta local para um serviço no servidor e cobre muitos casos que antes implicavam uma janela X: painéis web, notebooks ou consolas de administração à escuta em localhost.

# Forward the server's port 8080 to your machine
ssh -N -L 8080:localhost:8080 user@server
# Then open http://localhost:8080 in your local browser
  1. Túnel de porta com ssh -L: mostra as interfaces web do servidor no seu navegador local, sem servidor X, em qualquer cliente que suporte reencaminhamento de portas.
  2. Descarregar o resultado por SFTP: se a aplicação gráfica servia apenas para ver um gráfico, um PDF ou uma imagem, gere o ficheiro no servidor e transfira-o. O SFTP integrado do termi1 faz isto sem sair da sessão.
  3. Ferramentas de texto dentro do tmux: htop, journalctl ou um editor de terminal substituem muitos monitores gráficos. O teclado do termi1 acrescenta Esc, Ctrl e F1–F12, que estas ferramentas usam constantemente.
  4. Ambiente de trabalho remoto através de uma rede privada: se precisa de um ambiente de trabalho completo, uma rede mesh privada Prialo ou o Tailscale chegam à máquina sem IP público nem portas abertas.

Quando o reencaminhamento X11 por SSH ainda faz sentido em 2026

O reencaminhamento X11 compensa quando se verificam três condições: a aplicação gráfica só existe no servidor, precisa dela por pouco tempo e está num desktop com servidor X e uma rede estável. Fora desse caso, as alternativas acima são mais simples e expõem menos.

Casos razoáveis: um instalador gráfico, uma ferramenta de diagnóstico do fabricante ou um visualizador sem versão web. Casos a evitar: -Y por hábito, ForwardX11 yes em Host *, ou X11Forwarding yes em servidores de produção que ninguém usa graficamente; aí, X11Forwarding no é a configuração certa.

A partir de um telemóvel, o fluxo prático é ligar-se com Mosh, voltar a anexar o tmux e trabalhar em texto. Se não se lembra da sintaxe do ssh -L, a IA do terminal SSH e Mosh termi1 escreve o comando na linha de comandos sem premir Enter e, nas ligações marcadas como produção, o Production Guard trava tudo o que apague, pare ou altere algo.

Perguntas frequentes

Qual é a diferença entre ssh -X e ssh -Y?

A diferença entre ssh -X e ssh -Y é o nível de confiança. O -X reencaminha o X11 aplicando às aplicações remotas as restrições da extensão X11 SECURITY; o -Y trata-as como fiáveis e dá-lhes acesso total ao seu ecrã local. Use o -Y apenas com servidores que controla.

Porque é que o SSH diz X11 forwarding request failed on channel 0?

A mensagem X11 forwarding request failed on channel 0 significa que o servidor recusou o reencaminhamento X11. As causas habituais são X11Forwarding no em /etc/ssh/sshd_config ou a falta do programa xauth no servidor. Corrija a diretiva, instale o xauth, recarregue o sshd e abra uma nova sessão.

O reencaminhamento X11 funciona com Mosh?

O reencaminhamento X11 não funciona com Mosh. O Mosh usa UDP, por omissão nas portas 60000-61000, arranca o mosh-server através de uma ligação SSH inicial e não faz reencaminhamento de portas nem reencaminhamento X11. Para abrir janelas X precisa de uma sessão SSH normal com -X ou -Y.

Posso usar o reencaminhamento X11 a partir de um iPhone ou telemóvel Android?

O reencaminhamento X11 a partir de um iPhone ou telemóvel Android só funciona se o cliente incluir um servidor X para desenhar as janelas, o que é pouco comum em terminais móveis. Na prática, um túnel ssh -L para uma interface web, descarregar resultados por SFTP ou ferramentas de texto no tmux funcionam melhor.