Nenhuma das soluções postadas funcionou para mim. Meu sistema cliente (desktop) está executando o macOS 10.12.5 (Sierra). Eu adicionei -vas opções para o sshcomando e ele me disse,

debug1: No xauth program.

o que significa que não tem um caminho correto para o xauthprograma. (Nesta versão do macOS, o caminho para xauthnão é padrão.) A solução foi adicionar esta linha a /etc/ssh/ssh_config(pode estar /etc/ssh/configem algumas configurações) ou em ~/.ssh/config(se você não tiver direitos de administrador):

XAuthLocation /opt/X11/bin/xauth

Agora a mensagem de aviso desapareceu.

Encontrei a causa, o meu ~/.ssh/configestava incompleto, você precisa dos dois:

Host *
    ForwardAgent yes
    ForwardX11 yes

Meu erro foi incluir apenas a opção ForwardX11.

Deixando o Ubuntu bash no Windows 10 ser executado ssh -X para obter um ambiente GUI em um servidor remoto

• Primeiro

Instale todos os itens a seguir. No Windows, instale o Xming. No Ubuntu bash, use sudo apt installpara instalar ssh xauth xorg.

sudo apt install ssh xauth xorg

• Segundo

Vá para a pasta contém o ssh_configarquivo, o meu é /etc/ssh.

• Terceiro

Edite ssh_configcomo administrador (USE sudo). Dentro ssh_configde , remova o hash #nas linhas ForwardAgent, ForwardX11, ForwardX11Trustede defina os argumentos correspondentes para yes.

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes

• Adiante

No ssh_configarquivo, remova o hash frontal #antes de Port 22e Protocol 2, e também anexe uma nova linha no final do arquivo para indicar o local do arquivo xauth XauthLocation /usr/bin/xauth, lembre-se de escrever seu próprio caminho do arquivo xauth.

# /etc/ssh/ssh_config

#   IdentifyFile ...
    Port 22
    Protocol 2
#   Cipher 3des
#   ...
#   ...
    ...
    ...
    GSSAPIDelegateCredentials no
    XauthLocation /usr/bin/xauth

• Quinto

Agora que terminamos de editar ssh_configo arquivo, salve-o quando sairmos do editor. Agora vá para a pasta ~ou $HOME, anexe export DISPLAY=localhost:0ao seu .bashrcarquivo e salve-o.

# ~/.bashrc
...
...
export DISPLAY=localhost:0

• Último

Estamos quase terminando. Reinicie seu shell bash, abra seu Xmingprograma e use ssh -X yourusername@yourhost. Então aproveite o ambiente GUI.

ssh -X yourusername@yourhost

O problema também está no subsistema Ubuntu no Windows, e o link está em

https://gist.github.com/DestinyOne/f236f71b9cdecd349507dfe90ebae776

Nota: o texto vinculado inclui 2 erros de digitação ( XauthLocaionem vez de XauthLocation)

Como observado, parece que xauthno OS X Yosemite regrediu para uma versão antiga que não funciona com a $DISPLAYconfiguração do XQuartz:

% xauth -V
1.0.9
% xauth generate $DISPLAY .
xauth: (argv):1:  bad display name "/private/tmp/com.apple.launchd(...)/org.macosforge.xquartz:0" in "add" command

Eu adicionaria isso como um comentário, mas não tenho representante suficiente. Adicionar mais uma linha à solução de sorin funcionou para mim.

Na máquina cliente, edite seu arquivo de configuração ssh comvim ~/.ssh/config

Em seguida, adicione estas linhas a ele:

Host *
    ForwardAgent yes
    ForwardX11 yes
    XAuthLocation /opt/X11/bin/xauth

Você pode verificar sua xauthlocalização com:

which xauth

Há um bug no MacOS no momento. Eu também me deparei com isso. A correção para mim envolveu adicionar o seguinte ao meu .bash_profile

dispdir=`dirname $DISPLAY`
dispfile=`basename $DISPLAY`
dispnew="$dispdir/:0"
if [ -e $DISPLAY -a "$dispfile" = "org.x:0" ]; then
  mv $DISPLAY $dispnew
fi
export DISPLAY=$dispnew

Essencialmente, o nome do pipe de arquivo associado à sua raiz X não pode ser tratado corretamente e, portanto, precisa de correção. :-)

acabei de remover ~/.Xauthority (máquina de destino) da minha pasta raiz e ssh -X 192.168.123.1 novamente e ik funcionou.

Incluindo

XAuthLocation /opt/local/bin/xauth em ~/.ssh/config

no meu macOS Sierra 10.12.6 funcionou para mim. Uma pequena mudança da resposta 7).

Isso começou a acontecer comigo depois de mover minha instalação do Cygwin de um PC para outro. O problema parecia ser a mudança do nome do host: o cookie mágico não correspondia mais ao nome do host do novo PC.

Corrida

touch ~/.Xauthority
xauth add :0 . `mcookie`

na instalação local do Cygwin corrigiu o problema para mim - xauth listagora listou um cookie mágico associado ao nome de host correto do novo PC e o aviso parou de aparecer.

No meu caso foi o problema de .Xauthority contendo o cookie Magic não encaminhado, Fabby em http://askubuntu.com/questions/571116/ recomenda em 2014-11-14 adicionar esta linha no final do .bashrc ou . profile para permitir o encaminhamento de chaves xauth entre usuários ao chamar su:

export $(dbus-launch)

Eu adicionei também anteriormente:

export XAUTHORITY=~/.Xauthority 

para garantir que o controle remoto chamado com ssh -X ̍@ o encontre.

No meu caso .Xauthority é um link simbólico para o usuário original /home//.Xauthority que eu su do...

  cd /home/<child_user>;ln -sf /home/<parent_user>/.Xauthority .xAuthority

com direitos corretos:

  sudo chown <parent_user> /home/<parent_user>/.profile
  chmod a+rw /home/<parent_user>/.profile 

por isso é acessível para e para . será capaz de acionar aplicativos e exibir o resultado da janela X em sua tela local em toda a conta de proxy!

DICA: Verifique a lista xauth... se reflete o magic cookie no .