desenv-web-rp.com

Como encaminhar o X pelo SSH para executar aplicativos gráficos remotamente?

Eu tenho uma máquina executando o Ubuntu que eu SSH para a minha máquina Fedora 14. Quero encaminhar o X da máquina Ubuntu de volta ao Fedora para que eu possa executar programas gráficos remotamente. Ambas as máquinas estão em uma LAN.

Eu sei que o -X opção ativa o encaminhamento do X11 no SSH, mas sinto que estou perdendo algumas das etapas.

Quais são as etapas necessárias para encaminhar o X de uma máquina Ubuntu para o Fedora via SSH?

390
Mr. Shickadance

O encaminhamento do X11 precisa estar ativado no lado do cliente e no servidor.

No lado do cliente , o -X (opção X maiúscula) para ssh habilita o encaminhamento do X11, e você pode torná-lo o padrão (para todas as conexões ou para uma conexão específica) com ForwardX11 yes no ~/.ssh/config .

No lado do servidor , X11Forwarding yes deve ser especificado em /etc/ssh/sshd_config . Observe que o padrão não é encaminhamento (algumas distribuições o ativam em seu padrão /etc/ssh/sshd_config) e que o usuário não pode substituir esta configuração.

O programa xauth deve ser instalado no lado do servidor. Se houver algum programa X11 lá, é muito provável que xauth esteja lá. No caso improvável xauth foi instalado em um local não padrão, ele pode ser chamado através de ~/.ssh/rc (no servidor!).

Observe que você não precisa definir nenhuma variável de ambiente no servidor. DISPLAY e XAUTHORITY serão automaticamente definidos com seus valores adequados. Se você executar ssh e DISPLAY não estiver definido, significa que o ssh não está encaminhando a conexão X11.

Para confirmar se o ssh está encaminhando o X11, verifique se há uma linha contendo Requesting X11 forwarding no ssh -v -X resultado. Observe que o servidor não responde de qualquer maneira, uma precaução de segurança de ocultar detalhes de possíveis invasores.

452

Para que o encaminhamento do X11 funcione no ssh, você precisará de três itens.

  1. Seu cliente deve estar configurado para encaminhar o X11.
  2. Seu servidor deve estar configurado para permitir o encaminhamento do X11.
  3. Seu servidor deve poder configurar a autenticação X11.

Se você tiver ambos os itens 1 e 2, mas estiver faltando o número 3, você terminará com uma variável de ambiente DISPLAY vazia.

Sopa de nozes, veja como fazer o encaminhamento do X11 funcionar.

  1. No seu servidor, verifique se/etc/ssh/sshd_config contém:

    X11Forwarding yes
    X11DisplayOffset 10
    

    Pode ser necessário o SIGHUP sshd, para que ele capte essas alterações.

    cat /var/run/sshd.pid | xargs kill -1
    
  2. No seu servidor, verifique se o xauth está instalado.

    [email protected]:~$ which xauth
    /usr/bin/xauth
    

    Se você não tiver o xauth instalado, encontrará o problema "variável de ambiente DISPLAY vazia".

  3. No seu cliente, conecte-se ao seu servidor. Certifique-se de dizer ao ssh para permitir o encaminhamento do X11. eu prefiro

    [email protected]:~$ ssh -X [email protected]
    

mas você pode gostar

    [email protected]:~$ ssh -o ForwardX11=yes [email protected]

ou você pode configurá-lo em seu ~/.ssh/config.


Hoje eu estava correndo com essa variável de ambiente DISPLAY vazia hoje, quando ssh'ing em um novo servidor que não administro. Rastrear a parte xauth que faltava foi um pouco divertido. Aqui está o que eu fiz e o que você pode fazer também.

Na minha estação de trabalho local, onde sou administrador, verifiquei se o/etc/ssh/sshd_config foi configurado para encaminhar o X11. Quando ssh -X volto ao localhost, o meu DISPLAY está configurado corretamente.

Forçar a desabilitação do DISPLAY não foi muito difícil. Eu só precisava assistir o que o sshd e o ssh estavam fazendo para configurá-lo corretamente. Aqui está o resultado completo de tudo o que fiz ao longo do caminho.

    [email protected]:~$ mkdir ~/dummy-sshd
    [email protected]:~$ cp -r /etc/ssh/* ~/dummy-sshd/
    cp: cannot open `/etc/ssh/ssh_Host_dsa_key' for reading: Permission denied
    cp: cannot open `/etc/ssh/ssh_Host_rsa_key' for reading: Permission denied

Em vez de usar o Sudo para forçar a cópia dos meus arquivos ssh_Host_ {dsa, rsa} _key no lugar, usei o ssh-keygen para criar arquivos fictícios para mim.

    [email protected]:~$ ssh-keygen -t rsa -f ~/dummy-sshd/ssh_Host_rsa_key
    Generating public/private rsa key pair.
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /home/blyman/dummy-sshd/ssh_Host_rsa_key.
    Your public key has been saved in /home/blyman/dummy-sshd/ssh_Host_rsa_key.pub.

Enxágüe e repita com -t dsa:

    [email protected]:~$ ssh-keygen -t dsa -f ~/dummy-sshd/ssh_Host_dsa_key
    # I bet you can visually copy-paste the above output down here

Edite ~/dummy-sshd/sshd_config para apontar para os novos arquivos de chave ssh_Host corretos.

    # before
    [email protected]:~$ grep ssh_Host /home/blyman/dummy-sshd/sshd_config 
    HostKey /etc/ssh/ssh_Host_rsa_key
    HostKey /etc/ssh/ssh_Host_dsa_key

    # after
    [email protected]:~$ grep ssh_Host /home/blyman/dummy-sshd/sshd_config 
    HostKey /home/blyman/dummy-sshd/ssh_Host_rsa_key
    HostKey /home/blyman/dummy-sshd/ssh_Host_dsa_key

Inicie o sshd em uma nova porta no modo sem desanexação:

    [email protected]:~$ sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
    sshd re-exec requires execution with an absolute path

Opa, corrija melhor esse caminho:

    [email protected]:~$ /usr/sbin/sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
    debug1: sshd version OpenSSH_5.5p1 Debian-4ubuntu6
    debug1: read PEM private key done: type RSA
    debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
    debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
    debug1: private Host key: #0 type 1 RSA
    debug1: read PEM private key done: type DSA
    debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
    debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
    debug1: private Host key: #1 type 2 DSA
    debug1: setgroups() failed: Operation not permitted
    debug1: rexec_argv[0]='/usr/sbin/sshd'
    debug1: rexec_argv[1]='-p'
    debug1: rexec_argv[2]='50505'
    debug1: rexec_argv[3]='-f'
    debug1: rexec_argv[4]='/home/blyman/dummy-sshd/sshd_config'
    debug1: rexec_argv[5]='-d'
    Set /proc/self/oom_adj from 0 to -17
    debug1: Bind to port 50505 on 0.0.0.0.
    Server listening on 0.0.0.0 port 50505.
    debug1: Bind to port 50505 on ::.
    Server listening on :: port 50505.

Pop um novo terminal e ssh no localhost na porta 50505:

    [email protected]:~$ ssh -p 50505 localhost
    The authenticity of Host '[localhost]:50505 ([::1]:50505)' can't be established.
    RSA key fingerprint is 81:36:a5:ff:a3:5a:45:a6:90:d3:cc:54:6b:52:d0:61.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '[localhost]:50505' (RSA) to the list of known hosts.
    Linux skretting 2.6.35-32-generic #67-Ubuntu SMP Mon Mar 5 19:39:49 UTC 2012 x86_64 GNU/Linux
    Ubuntu 10.10

    Welcome to Ubuntu!
     * Documentation:  https://help.ubuntu.com/

    1 package can be updated.
    0 updates are security updates.

    Last login: Thu Aug 16 15:41:58 2012 from 10.0.65.153
    Environment:
      LANG=en_US.UTF-8
      USER=blyman
      LOGNAME=blyman
      HOME=/home/blyman
      PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
      MAIL=/var/mail/blyman
      Shell=/bin/bash
      SSH_CLIENT=::1 43599 50505
      SSH_CONNECTION=::1 43599 ::1 50505
      SSH_TTY=/dev/pts/16
      TERM=xterm
      DISPLAY=localhost:10.0
    Running /usr/bin/xauth remove unix:10.0
    /usr/bin/xauth add unix:10.0 MIT-MAGIC-COOKIE-1 79aa9275ced418dd445d9798b115d393

Veja as últimas três linhas lá. Por sorte, eu tinha o DISPLAY definido e aquelas duas linhas bonitas de/usr/bin/xauth.

A partir daí, era brincadeira de criança afastar meu/usr/bin/xauth para /usr/bin/xauth.old, desconectar do ssh e interromper o sshd, em seguida, inicie o sshd e o ssh novamente no localhost.

Quando o/usr/bin/xauth se foi, não vi o DISPLAY refletido no meu ambiente.


Não há nada brilhante acontecendo aqui. Principalmente, tive sorte em escolher uma abordagem sensata para tentar reproduzir isso na minha máquina local.

98
Belden

Certifique-se de que:

  • Você xauth instalou no servidor (consulte: xauth info/xauth list).
  • No servidor, seu /etc/ssh/sshd_config _ arquivo tem estas linhas:

    X11Forwarding yes
    X11DisplayOffset 10
    X11UseLocalhost no
    
  • No lado do cliente, seu ~/.ssh/config _ arquivo tem estas linhas:

    Host *
      ForwardAgent yes
      ForwardX11 yes
    
  • No lado do cliente, você tem o servidor X instalado (por exemplo, macOS: XQuartz; Windows: Xming).


Para fazer o encaminhamento do X11 usando SSH, você precisa adicionar -X ao seu comando ssh, por exemplo.

ssh -v -X [email protected]

verifique se o seu DISPLAY está não vazio por:

echo $DISPLAY

Se for, ter um parâmetro detalhado para ssh (-v), verifique se há avisos, por exemplo.

debug1: No xauth program.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated

Caso você tenha X11 não confiável conforme mostrado acima, tente -Y flag em vez disso (se você confiar no host):

ssh -v -Y [email protected]

Consulte: O que significa “Aviso: falha na configuração de encaminhamento do X11 não confiável: dados da chave xauth não gerados”) quando ssh'ing com -X?


Caso você tenha aviso: sem dados xauth, tente gerar um novo .Xauthority, por exemplo.

xauth generate :0 . trusted
xauth list

Consulte: Criar/recriar um novo arquivo .Xauthority


Se você tiver avisos diferentes dos descritos acima, siga as outras dicas.


43
kenorb

A correção é adicionar essa linha ao seu /etc/ssh/sshd_config:

X11UseLocalhost no

https://joshua.hoblitt.com/rtfm/2013/04/how_to_fix_x11_forwarding_request_failed_on_channel_0/

21
Ace

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

  • Primeiro

Instale todos os seguintes. Na janela, instale Xming. No Ubuntu no terminal, use Sudo apt install para instalar ssh xauth xorg.

Sudo apt install ssh xauth xorg
  • Segundo

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

  • Terceiro

Editar ssh_config como administrador (USE Sudo). Dentro ssh_config, remova o hash # nas linhas ForwardAgent, ForwardX11, ForwardX11Trusted e defina os argumentos correspondentes como yes.

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes
  • Adiante

No ssh_config, remova o hash frontal # antes Port 22 e Protocol 2 e também adicione 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 para o arquivo xauth.

# /etc/ssh/ssh_config

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

Agora, já que terminamos de editar ssh_config, salve-o quando sairmos do editor. Agora vá para a pasta ~ ou $HOME, acrescente export DISPLAY=localhost:0 para o seu .bashrc e salve-o.

# ~/.bashrc
...
...
export DISPLAY=localhost:0
  • Último

Estamos quase terminando. Reinicie seu shell bash, abra seu programa Xming e use ssh -X [email protected]. Então aproveite o ambiente da GUI.

ssh -X [email protected]

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

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

5
DestinyOne

Adicionar X11UseLocalhost no para /etc/ssh/sshd_config e reinicie o servidor SSH.

Se você não exibir o DISPLAY, verifique se o xauth está instalado corretamente e tente novamente.

RHE/CEntos não tem esse problema, é uma coisa do Ubuntu!

4
stephen cooke

Para mim, o problema estava em nodev opção de montagem para o sistema de arquivos/tmp. O X11 precisa de um arquivo especial para ser criado lá.

Portanto, verifique quais são as opções de montagem para o sistema de arquivos/tmp se você usar uma partição ou disco separado para isso.

1
yakovpol

Para adicionar às excelentes respostas anteriores (configurar ~/.ssh/config e verificando se a variável de ambiente DISPLAY está definida no cliente, configurando /etc/ssh/sshd_config e instalando xauth no servidor), também verifique se xterm está instalado no cliente, por exemplo.

Sudo apt-get install xterm
1
Aliz Rao

xauth pode ser bloqueado.

   -b      This  option  indicates  that  xauth  should  attempt to break any authority file locks before proceeding.  Use this
           option only to clean up stale locks.

Usando

xauth -b

Na máquina em que eu estava tentando ssh quebrou a trava em xauth. Desconectando-se da sessão ssh após emitir xauth -b então o login finalmente me permitiu obter êxito echo $DISPLAY. Definitivamente, tente isso antes de recriar .Xauthority

1
Barton Chittenden

X11Forwarding deve ser definido no servidor SSH (no seu caso, a caixa Ubuntu) em seu sshd_config, e você deve permitir que o X11 seja encaminhado para o cliente SSH (sua caixa do Fedora) passando o -X ou editar a opção ssh_config para adicionar o ForwardX11 padrão.

1
Caleb