ssh retorna a mensagem “Falha na solicitação de encaminhamento do X11 no canal 1”


33

Quando ssh em um servidor remoto que não está executando nenhum tipo de ambiente de área de trabalho X11, recebo a seguinte mensagem.

$ ssh user@server
X11 forwarding request failed

$ ssh user@server ls
X11 forwarding request failed on channel 1
file1
file2
...

Como posso me livrar dessas mensagens?

Respostas:


38

Essas mensagens podem ser eliminadas através de 1 de 3 métodos, usando apenas opções SSH. Você sempre pode enviar mensagens /dev/nulltambém, mas esses métodos tentam lidar com a mensagem através da configuração, em vez de apenas interceptá-los e descartá-los.

Método # 1 - instalar o xauth

O servidor no qual você está remotando está reclamando que não pode criar uma entrada no .Xauthorityarquivo do usuário , porque xauthnão está instalado. Então você pode instalá-lo em cada servidor para se livrar dessa mensagem irritante.

No Fedora 19 você instala xauthassim:

$ sudo yum install xorg-x11-xauth

Se você tentar sshentrar no servidor, verá uma mensagem informando que uma entrada está sendo criada no .Xauthorityarquivo do usuário .

$ ssh root@server
/usr/bin/xauth:  creating new authority file /root/.Xauthority
$

Logons subsequentes não mostrarão mais esta mensagem.

Método # 2 - desativá-lo via ForwardX11

Você pode instruir o sshcliente a não tentar ativar o encaminhamento do X11, incluindo o parâmetro SSH ForwardX11.

$ ssh -o ForwardX11=no root@server

Você pode fazer o mesmo com a -xopção:

$ ssh -x root@server

Isso apenas desativará temporariamente esta mensagem, mas é uma boa opção se você não puder ou não quiser instalar xauthno servidor remoto.

Método # 3 - desativá-lo via sshd_config

Normalmente, esse é o padrão, mas, caso contrário, você pode configurar o sshdservidor para que o X11Forwarding esteja desativado /etc/ssh/sshd_config.

X11Forwarding no

Dos três métodos, geralmente uso o número 2, porque geralmente desejarei usar a X11Forwardingmaioria dos meus servidores, mas não quero ver os X11....avisos

$ HOME / .ssh / config

Na maioria das vezes, essas mensagens nem aparecem. Eles geralmente estão presentes apenas quando você tem as seguintes entradas no seu $HOME/.ssh/configarquivo, na parte superior.

ServerAliveInterval 15
ForwardX11 yes
ForwardAgent yes
ForwardX11Trusted yes

GatewayPorts yes

Portanto, é essa configuração, que está impulsionando a geração dessas X11..mensagens. Novamente, o método 2 parece ser o mais apropriado se você deseja operar com o ForwardX11 yespadrão, mas desativa-o seletivamente para determinadas conexões sshda perspectiva do cliente .

Segurança

Geralmente, é desaconselhável continuar com ForwardX11 yesisso o tempo todo. Portanto, se você deseja operar suas conexões SSH da maneira mais segura possível, é melhor fazer o seguinte:

  1. Não inclua ForwardX11 yesno seu $HOME/.ssh/configarquivo
  2. Use o ForwardingX11 apenas quando precisar ssh -X user@server
  3. Se você puder, desabilite X11Forwardingcompletamente no servidor para que não seja permitido

Referências



Para o registro, recebi essa mensagem quando estava tentando executar clientes X no servidor remoto. Eles não foram lançados porque $ DISPLAY não foi definido. Consegui corrigi-lo com sua primeira sugestão: instalar o xauth.
Tom Ellis

13

No meu caso, adicionar esta string para /etc/ssh/sshd_configresolver o problema:

X11UseLocalhost no

Isso funcionou para mim (o servidor já tinha o xauth instalado). Obrigado.
Paul Higgins

Isso pareceu resolver o meu problema, mas não entendo o motivo, o que é preocupante. Eu tenho o que deveria ser três máquinas idênticas do Debian 7, uma das quais parou subitamente de aceitar o locahostencaminhamento do X11. O encaminhamento X11 nos outros dois ainda funciona. Alguma idéia do que poderia ter mudado?
Kyle Strand

12

Atravessei isso hoje e bati minha cabeça por um tempo até eu me deparar com um cenário ssh:

Se for RHEL 7 (centOS, OEL, etc) e tiver o ipv6 desativado, será necessário:

AddressFamily inet

definido em / etc / ssh / sshd_config.


Se apenas a mensagem de erro relacionada com esta ...
Jack Wasey

você sabe o que é engraçado? Eu me deparei com isso hoje e pesquisei no Google, encontrei este artigo e encontrei meu próprio comentário de quatro anos atrás e disse: "Oh, sim, esse é o problema".
Systemspoet 25/07

2

Outra pequena variação seria se você quisesse parar de ver esta mensagem (ou seja, parar de tentar encaminhar o X11) para determinados servidores, mas ainda assim manter o padrão no ForwardX11 yes em todas as outras conexões.

Nesse cenário, você pode desativar o encaminhamento do X11 para um host (ou intervalo) específico em seu ~ / .ssh / config. Algo assim:

host 10.1.1.*
ForwardX11 no 

Agradecimento: Este é um pequeno embelezamento para a resposta existente (e muito completa) existente - já que eu não podia comentar!


2

Se a execução do cliente no modo detalhado ( ssh -v user@host) fornecer a você

debug1: Remote: No xauth program; cannot forward with spoofing.

mas, de xauthfato, está instalado no servidor, provavelmente é porque o sshd procura o executável xauth no local errado ( / usr / X11R6 / bin / xauth normalmente). Pode-se consertar isso definindo

XAuthLocation /usr/bin/xauth

em / etc / sshd / sshd_config (ou com o que seu servidor estiver configurado).


Isso funcionou para mim no CentOS 7. Essa é a mensagem de erro exata que eu estava vendo.
27717 Brian Minton

Este foi o meu problema, tentando fazer login remotamente em um Mac. Há o encantamento correta era XAuthLocation / opt / X11 / bin / xauth
Leon Avery

1

Configurando o encaminhamento do X11 por host

Além de todas as excelentes respostas já aqui, você pode configurar ForwardX11por host, portanto, se apenas serverfalhar dessa maneira, poderá adicionar uma entrada ao seu ~/.ssh/configarquivo do seguinte formato:

Host server server.domain.dom
    ForwardX11 no

Você pode até usar entradas como esta como alias para conjuntos inteiros de configurações

Host my.server
    HostName server.domain.dom
    User user
    Port 1234
    ForwardX11 no

Isso é especialmente útil se você configurou nomes de servidores de preenchimento automático para SSH e SCP .


1

Me deparei com essa pergunta depois de encontrar um sshd-xauthbug com quase uma década de idade. Duas soluções são relatadas, a primeira ignorando xauth, a segunda abordando o bug.


Solução 1 - ignorar xauth

  • local - a máquina local que serve um Xserver.
  • remote - a máquina remota que atende ao aplicativo que direciona os dados para o Xserver

Remoto /etc/ssh/sshd_config:

X11Forwarding no
X11DisplayOffset 10
X11UseLocalhost yes

Controlo remoto ~/.Xauthority está vazio ou não existe

No local:

Xephyr -ac -screen 1280x800 -br -reset   :2 &
DISPLAY=:2 ssh  -fR 6010:/tmp/.X11-unix/X2  user@remote "DISPLAY=:10 xeyes"

No teste, o local estava executando o Ubuntu 18.05, o remoto estava executando o Debian Jesse.

Também publiquei esta solução como resposta a outra pergunta.


Solução 2 - resolva o bug sshd / xauth

Esta solução está próxima da solução do @systempoet acima , embora isso por si só não tenha sido suficiente.

Além de modificar /etc/ssh/sshd_configno controle remoto:

AddressFamily inet

/etc/hosts no controle remoto também foi modificado:

::1     localhost ip6-localhost ip6-loopback

Se um deles foi comentado, a mensagem de erro

X11 forwarding request failed on channel 0

apareceu após a ssh -X ...chamada. Além disso, /var/log/auth.logo erro foi mostrado:

sshd[...]: error: Failed to allocate internet-domain X11 display socket

Teste para produzir o bug (antes da correção):

Máquina local:

$ Xephyr -ac -screen 1280x800 -br -reset -terminate  :2 &
$ DISPLAY=:2 ssh -X  user@remote
X11 forwarding request failed on channel 0

0

Um ponto importante a ser observado depois de fazer as alterações na configuração é que você precisará matar o sshd para que ele capte as alterações:

cat /var/run/sshd.pid | xargs kill -1

sendo o usuário root.


-2
  1. Defina as 2 opções a seguir /etc/ssh/sshd_configem seu host RHEL

    X11Forwarding yes X11UseLocalhost no

  2. sudo /etc/init.d/sshd reload

  3. sudo yum install xauth
  4. ssh de volta ao host RHEL com a opção -X: ssh -X yourname@rhelbox
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.