Toda vez que inicio uma conexão ssh do meu Mac para um Linux (Debian), recebo este aviso:

No xauth data; using fake authentication data for X11 forwarding.

Isso também acontece para ferramentas que estão usando ssh, como git ou mercurial.

Eu só quero fazer uma alteração local no meu sistema para impedir que isso apareça.

Nota: Eu tenho o servidor X11 (XQuartz 2.7.3 (xorg-server 1.12.4)) no meu Mac OS X (10.8.1) e está funcionando corretamente, posso iniciar o relógio com êxito local ou remotamente.

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

debug1: No xauth program.

o que significa que não possui 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 se foi.

Encontrou a causa, meu ~/.ssh/configestava incompleto, você precisa de ambos:

Host *
    ForwardAgent yes
    ForwardX11 yes

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

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

• Primeiro

Instale todos os seguintes. Na janela, instale 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_config, remover o hash #nas linhas ForwardAgent, ForwardX11, ForwardX11Trusted, e definir os argumentos correspondentes a yes.

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes

• Adiante

No ssh_configarquivo, remover o hash frente #antes Port 22e Protocol 2, além de acrescentar uma nova linha no final do arquivo para indicar o local do arquivo xauth, XauthLocation /usr/bin/xauth, lembre-se escrever o seu próprio caminho de 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 o ssh_configarquivo, salve-o quando sairmos do editor. Agora vá para a pasta ~ou $HOME, acrescente 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 da 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 (em XauthLocaionvez de XauthLocation)

Como observado, parece que xauthno OS X o Yosemite voltou 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

Há um bug no MacOS no momento. Eu me deparei com isso também. 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 canal de arquivos associado à sua raiz X não pode ser tratado corretamente e, portanto, precisa de correção. :-)

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).

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

No meu caso, foi o problema de .Xauthority contendo o cookie Magic não encaminhado, Fabby em http://askubuntu.com/questions/571116/ recomenda em 14/11/2014 - adicionar esta linha no final do arquivo .bashrc ou . perfil 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 su de ...

  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 

portanto, é acessível para e para. poderá acionar aplicativos e exibir o resultado da janela X na tela local em toda a conta proxy!

DICA: verifique a lista xauth ... se reflete o cookie mágico.

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

Abra seu arquivo de configuração ssh com vim ~/.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