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

Question

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

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

Quais são os passos necessários para encaminhar o X de uma máquina Ubuntu para o Fedora sobre SSH?

    

Answer 1

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

No lado do cliente , a opção -X (capital X) para ssh habilita o encaminhamento X11, e você pode tornar isso o padrão (para todas as conexões ou para uma conexão específica) com ForwardX11 yes em ~/.ssh/config .

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

O programa xauth deve ser instalado no lado do servidor. Se houver algum programa X11, é muito provável que xauth esteja lá. No caso improvável de xauth ter sido instalado em um local fora do padrão, ele pode ser chamado por meio 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 para seus valores apropriados. Se você executar ssh e DISPLAY não estiver configurado, significa que o ssh não está encaminhando a conexão X11.

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

    

Answer 2

Para obter o encaminhamento do X11 trabalhando sobre o ssh, você precisará de 3 coisas no lugar.

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 ser capaz de configurar a autenticação do X11.

Se você tiver os números 1 e 2 no lugar, mas não tiver o número 3, você acabará com uma variável de ambiente DISPLAY vazia.

Sopa para nozes, veja como fazer o encaminhamento do X11 funcionando.

1. Em seu servidor, certifique-se de que / etc / ssh / sshd_config contenha:

   X11Forwarding yes
   X11DisplayOffset 10
   

   Você pode precisar SIGHUP sshd para pegar essas alterações.

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

2. No seu servidor, verifique se você tem o xauth instalado.

   belden@skretting:~$ which xauth
   /usr/bin/xauth
   

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

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

   belden@skretting:~$ ssh -X blyman@the-server
   

mas você pode gostar

    belden@skretting:~$ ssh -o ForwardX11=yes blyman@the-server

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

Eu estava correndo para esta variável de ambiente vazia do DISPLAY hoje cedo quando ssh'ing em um novo servidor que eu não administro. O rastreamento da parte xauth ausente 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 que o / etc / ssh / sshd_config estava configurado para encaminhar o X11. Quando eu ssh -X volta ao localhost, eu recebo meu DISPLAY corretamente.

Forçar a exibição do DISPLAY não foi muito difícil. Eu só precisava ver o que o sshd e o ssh estavam fazendo para definir corretamente. Aqui está a saída completa de tudo que fiz ao longo do caminho.

    blyman@skretting:~$ mkdir ~/dummy-sshd
    blyman@skretting:~$ 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, usei o ssh-keygen para criar os fictícios para mim.

    blyman@skretting:~$ 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.

Enxague e repique com -t dsa:

    blyman@skretting:~$ 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 chaves ssh_host corretos.

    # before
    blyman@skretting:~$ grep ssh_host /home/blyman/dummy-sshd/sshd_config 
    HostKey /etc/ssh/ssh_host_rsa_key
    HostKey /etc/ssh/ssh_host_dsa_key

    # after
    blyman@skretting:~$ 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

Abra o sshd em uma nova porta no modo não desanexar:

    blyman@skretting:~$ sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
    sshd re-exec requires execution with an absolute path

Opa, corrija melhor esse caminho:

    blyman@skretting:~$ /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.

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

    blyman@skretting:~$ 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

Olhe as últimas três linhas lá. Eu tive fortuitamente DISPLAY SET, e tinha aquelas duas linhas bonitas de / usr / bin / xauth.

De lá, foi brincadeira de criança deixar de lado meu / usr / bin / xauth para /usr/bin/xauth.old, desconectar do ssh e parar o sshd, depois iniciar o sshd e o ssh de volta ao localhost.

Quando / 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 sã para tentar reproduzir isso na minha máquina local.

    

Answer 3

Certifique-se de que:

• Você tem xauth instalado no servidor (consulte: xauth info / xauth list ).

• No servidor, seu arquivo /etc/ssh/sshd_config tem estas linhas:

  X11Forwarding yes
  X11DisplayOffset 10
  X11UseLocalhost no
  

• No lado do cliente, seu arquivo ~/.ssh/config tem estas linhas:

  Host *
    ForwardAgent yes
    ForwardX11 yes
  

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

Em seguida, para fazer o encaminhamento do X11 usando o SSH, você precisa adicionar -X ao comando ssh , por exemplo,

ssh -v -X user@host

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

echo $DISPLAY

Se for, então, ter um parâmetro detalhado para ssh ( -v ), verifique se há algum aviso, 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 como mostrado acima, tente -Y flag (se confiar no host):

ssh -v -Y user@host

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

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

xauth generate :0 . trusted
xauth list

Veja: Crie / recrie um novo arquivo .Xauthority

Se você tiver um aviso diferente do que o acima, siga as outras dicas.

Answer 4

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

X11UseLocalhost no

link

    

Answer 5

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

• Primeiro

Instale todos os itens a seguir. Na janela, instale Xming . No bash do Ubuntu, use sudo apt install para instalar ssh xauth xorg .

sudo apt install ssh xauth xorg

• Segundo

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

• Terceiro

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

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes

• adiante

No arquivo ssh_config , remova o hash da frente # antes de Port 22 e Protocol 2 e também anexe uma nova linha no final do arquivo para indicar a localização do arquivo xauth, XauthLocaion /usr/bin/xauth , lembre-se de gravar seu próprio caminho do arquivo xauth.

# /etc/ssh/ssh_config

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

• Quinto

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

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

• Última

Estamos quase terminando. Reinicie seu shell bash, abra seu programa Xming 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

link

    

Answer 6

Para mim, o problema estava na opção de montagem nodev 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.

    

Answer 7

Adicione X11UseLocalhost no a /etc/ssh/sshd_config e reinicie o servidor SSH.

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

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

    

Answer 8

Para adicionar as respostas excelentes anteriores (configurar ~/.ssh/config e verificar se a variável de ambiente DISPLAY está definida no cliente, configurar /etc/ssh/sshd_config e instalar xauth no servidor), também faça Certifique-se de que xterm esteja instalado no cliente, por exemplo

sudo apt-get install xterm

    

Answer 9

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

    

Answer 10

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 , ele quebrou o bloqueio em xauth . Efetuar logout da sessão ssh após a emissão de xauth -b , em seguida, o login de volta finalmente me permitiu obter echo $DISPLAY . Definitivamente tente isso antes de recriar .Xauthority