Tente ssh -Y

Algum motivo para você não querer usar o -Ysinalizador em vez do -Xsinalizador?

Muito simplesmente, a diferença entre -Xe -Yé que -Ypermite o encaminhamento confiável do X11.

CUIDADO (cansado de ler respostas incompletas que levam a falha de segurança)

1. usar ssh -Y significa aqui ter informações falsas de xauth, o que é ruim!

2. ssh -X deve funcionar, pois o XQuartz, uma vez habilitado, usa xauth. O único problema é que o ssh está procurando xauth em /usr/X11R6/bin e em macos com XQuartz está em /opt/X11/bin

Solução segura:

1. Habilite a primeira opção na guia Segurança das preferências (Cmd-,) que habilita conexões autenticadas

2. adicione o seguinte a $HOME/.ssh/config

   XAuthLocation /opt/X11/bin/xauth

3. ssh -X you_serverfunciona de forma segura

Se você está vindo para cá em 2015: mesmo que todo o resto esteja configurado corretamente, isso também pode acontecer no Mac OS X 10.10 Yosemite, ao usar ssh -Xe executar uma versão do XQuartz <= 2.7.7. A causa raiz é que os soquetes de exibição X11 são gravados fora do caminho de pesquisa xauth: problema #2068 no rastreador XQuartz.

Edit: Um XQuartz corrigido já foi lançado na nova página inicial, xquartz.org , e instalar a versão mais recente de lá (atualmente 2.7.9) resolverá o problema.

Se você receber a mesma mensagem mesmo usando -Y, o xauthprograma pode estar faltando no servidor. Em sistemas do tipo Debian, você precisa do xauthpacote. Em sistemas do tipo RedHat, você precisa do xorg-x11-xauthpacote.

"Não confiável" neste contexto significa que você não confia na conexão. O SSH usará medidas de segurança adicionais para tentar tornar o encaminhamento do X11 mais seguro. "Confiável" significa que você está totalmente confiante de que ninguém no host remoto terá acesso aos seus dados Xauth e os usará para monitorar suas teclas, por exemplo.

Esta terminologia realmente me confundiu por anos. Achei que as conexões "confiáveis" eram mais seguras. Mas, na verdade, é uma opção que você deve usar em situações em que a conexão é confiável e você deseja executar coisas sem que medidas de segurança extras atrapalhem seu caminho. "Não confiável" é aquele que torna (um pouco) mais seguro lidar com um host remoto não confiável.

Uma conexão "Não confiável" tenta limitar o que um black hat pode fazer com você, acionando a extensão de segurança X11 e desabilitando outras extensões que você (espero) não precisa. Provavelmente é por isso que RandR está desabilitado com -X. Você precisa ser capaz de girar sua tela X do host remoto?

Também é importante observar que o encaminhamento X11 "não confiável" é desativado após um certo período de tempo para evitar que você o deixe acidentalmente ativado. Novas tentativas de abrir janelas falharão depois disso. Isso me mordeu várias vezes antes de eu ler documentos suficientes para entender o que estava acontecendo.

Descartar problemas do lado do servidor

Primeiro, você deve descartar quaisquer problemas do lado do servidor. Você é capaz ssh -Xde qualquer outro host com sucesso? Funciona ssh -Yenquanto ssh -Xnão funciona? Em ambos os casos, suponha que ssh + X11 esteja configurado corretamente em seu servidor e passe para a próxima seção.

Se você não estiver em condições de verificar isso (você tem apenas um laptop executando o X11, digamos), você pode sshdo servidor para si mesmo usando uma sessão falsa:

1. export DISPLAY=:44# (shell Bourne) ou
   setenv DISPLAY :44# (csh / tcsh)
2. xauth add $DISPLAY MIT-MAGIC-COOKIE-1 1234 # Biscoito falso apenas para este teste
3. ssh -X localhost env |grep DISPLAY

Resultado esperado: deve haver uma variável DISPLAY definida na extremidade remota da sessão ssh-to-self. Se você não obtiver nenhum resultado, seu servidor provavelmente está configurado incorretamente (por exemplo, as bibliotecas X11 e/ou o xauthcomando podem estar ausentes; ou a configuração sshd pode ser definida para negar acesso ao X11)

No Mac: verifique se o Xquartz está atualizado

De acordo com a resposta de Will Angley

Examinar ssh -vv -Xsaída

A mensagem de erro que você cita é um sintoma que pode ter várias causas. Tente novamente com , o que deve fornecer pistas adicionais sobre por que a configuração do túnel X11 falhou.ssh -X -vv remotehost

Você vê a seguinte mensagem aparecendo?

debug1: Nenhum programa xauth.

1. Anote onde em seu sistema cliente, o xauthcomando reside:

   qual xauth

2. Adicione o seguinte no final do seu ~/.ssh/config (e adicione um comentário para se lembrar de mantê-lo lá no futuro):

   Hospedeiro *
       XAuthLocation /opt/X11/bin/xauth
   

   Ajuste este caminho de acordo com as descobertas da etapa 1 — Créditos para Jan-Willem Arnold

Eu não tenho uma configuração que possa exibir esse comportamento, então isso é um tiro no escuro:

O aviso pode ser suprimido se você definir ForwardX11Trustedpara "no"hosts que emitem esse aviso. Você pode colocar isso em ~/.ssh/configou /etc/ssh/ssh_config, e você pode tornar a opção específica para um host específico incluindo Host <hostname>na linha acima. o <hostname>componente corresponde ao que você digita na linha de comando (não o nome do host resolvido) e pode incluir curingas.

Se a instalação xauthnão funcionar corretamente, um caso particularmente irritante pode ser um .Xauthorityarquivo corrompido. Este caso em particular permitiu que alguns clientes X funcionassem, mas não outros com maior tendência a falhar com telas mais recentes. Remover e recriar o .Xauthorityarquivo pode resolver esse problema.

Como já foi explicado acima, o seguinte funcionou para mim:

Edite ~/.ssh/config para adicionar as linhas

Host *
    XAuthLocation /opt/X11/bin/xauth

e agora ssh -X hostname funciona (XQuartz 2.7.11, macOS 10.4 Mojave)

Usando o XQuartz 2.7.11 no MacOS Catalina, tive que atualizar meu arquivo /etc/ssh/ssh_config e adicionar XAuthLocation /opt/X11/bin/xauthdepois Host *para ssh -X funcionar