Как передать X по SSH для запуска графических приложений удаленно?

У меня есть машина под управлением Ubuntu который я SSH к от моей машины Fedora 14. Я хочу передать X от машины Ubuntu назад к Fedora, таким образом, я могу запустить графические программы удаленно. Обе машины находятся на LAN.

Я знаю что -X опция включает передачу X11 в SSH, но я чувствую, что пропускаю некоторые шаги.

Что необходимые шаги должны передать X от машины Ubuntu до Fedora по SSH?

365
23.03.2017, 16:17
4 ответа

Передача X11 должна быть включена и на стороне клиента и на стороне сервера.

На стороне клиента, -X (капитал X) опция к ssh включает передачу X11, и можно сделать это значением по умолчанию (для всех соединений или для определенного соединения) с ForwardX11 yes в ~/.ssh/config.

На стороне сервера, X11Forwarding yes должен указанный в /etc/ssh/sshd_config. Обратите внимание, что значение по умолчанию не является никакой передачей (некоторые дистрибутивы включают его в своем значении по умолчанию /etc/ssh/sshd_config), и что пользователь не может переопределить эту установку.

xauth программа должна быть установлена на стороне сервера. Если существуют какие-либо программы X11 там, это вероятно это xauth будет ли. В маловероятном случае xauth был установлен в нестандартном месте, это можно назвать через ~/.ssh/rc (на сервере!).

Обратите внимание, что Вы не должны устанавливать переменные среды на сервере. DISPLAY и XAUTHORITY будет автоматически установлен на их собственные значения. Если Вы выполняете ssh и DISPLAY не установлен, это означает, что ssh не передает соединение X11.

Чтобы подтвердить, что ssh передает X11, проверьте на строку, содержащую Requesting X11 forwarding в ssh -v -X вывод. Обратите внимание, что сервер не ответит так или иначе, предосторожность безопасности сокрытия деталей от потенциальных взломщиков.

429
27.01.2020, 19:28
  • 1
    @user: Нет, Вам никогда не нужно xhost +. xhost с более нежной эры, когда подключение машины к сети означало, что Вы были защищены. xhost + средства любой, кто может имитировать Ваш IP, может взять под свой контроль Вашу сессию X-сервера. ssh -X настроит все необходимые полномочия. Если передача X11, отключенная в конфигурации сервера, говорите со своим администратором; если это не работает, посмотрите Передачу X11 по SSH, если конфигурация сервера не позволяет его. –  Gilles 'SO- stop being evil' 07.05.2011, 01:52
  • 2
    Спасибо за упоминание xauth! Отсутствие этого на базовом сервере вызывало меня проблема. –  vasi 09.04.2013, 09:53
  • 3
    +1 для того, чтобы сделать различие между ~/.ssh/config и /etc/ssh/sshd_config в том же месте. Я не мог сказать, были ли они различными' файлами или просто изменением в номенклатуре. –  puk 13.11.2013, 09:48
  • 4
    @KhurshidAlam не имеет значения, выполняет ли сервер также среду GUI. Проверьте полномочия .Xauthority файл. При использовании Red Hat или другой системы с SELinux, проверьте контекст SELinux, см. unix.stackexchange.com/questions/36540 / … –  Gilles 'SO- stop being evil' 06.01.2014, 14:30
  • 5
    после ssh -X выполненный xterm & заставить графический терминал как окончательный тест видеть, работает ли это. –  Alexander Taylor 29.05.2014, 20:18

X11Forwarding должен быть установлен на сервере SSH (в Вашем случае поле Ubuntu) в sshd_config, и необходимо позволить X11 быть переданным для клиента SSH (поле Fedora) путем передачи -X опция или редактирование ssh_config файл для добавления ForwardX11 значение по умолчанию.

1
27.01.2020, 19:28
  • 1
    Вам также нужно xauth установленный на удаленной машине, иначе x материал полномочий не будет работать. –  Faheem Mitha 06.05.2011, 21:22
  • 2
    Что относительно установки DISPLAY? –  Mr. Shickadance 06.05.2011, 21:36
  • 3
    ssh автоматически установит $DISPLAY если X11Forwarding включен и xauth присутствует в клиентской системе. –  Shadur 06.05.2011, 21:58
  • 4
    @Shadur Не для меня. Это работает когда я export DISPLAY=:10.0 но не иначе. Иначе это жалуется, что не может найти :0. Возможно, что-то еще необходимо, чтобы это произошло автоматически? –  cfr 06.03.2017, 19:39

Для получения передачи X11, работающей по ssh, Вам будут нужны 3 вещи на месте.

  1. Ваш клиент должен быть настроен для передачи X11.
  2. Ваш сервер должен быть настроен для разрешения передачи X11.
  3. Ваш сервер должен смочь настроить аутентификацию X11.

Если Вы будете иметь в распоряжении и № 1 и № 2, но пропустите № 3, то Вы закончите с пустой переменной среды ДИСПЛЕЯ.

Суп к гайкам, вот то, как получить передающую работу X11.

  1. На Вашем сервере удостоверьтесь, что/etc/ssh/sshd_config содержит:

    X11Forwarding yes
    X11DisplayOffset 10
    

    Вам, возможно, понадобится к SIGHUP sshd, таким образом, он берет эти изменения.

    cat /var/run/sshd.pid | xargs kill -1
    
  2. На Вашем сервере удостоверьтесь, что у Вас есть установленный xauth.

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

    Если у Вас не будет xauth установленным, то Вы столкнетесь с "пустой проблемой" переменной среды ДИСПЛЕЯ.

  3. На Вашем клиенте соединитесь со своим сервером. Обязательно скажите ssh позволять передачу X11. Я предпочитаю

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

но можно понравиться

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

или можно настроить это в ~/.ssh/config.


Я сталкивался с этой пустой переменной среды ДИСПЛЕЯ ранее сегодня, когда ssh'ing в новый сервер, который я не администрирую. Разыскивание пропавших без вести xauth часть было небольшой забавой. Вот то, что я сделал, и что можно сделать также.

На моей локальной рабочей станции, где я - администратор, я проверил, что/etc/ssh/sshd_config был настроен для передачи X11. Когда я, ssh-X въезжают задним ходом к localhost, я действительно устанавливал свой ДИСПЛЕЙ правильно.

Принуждение ДИСПЛЕЯ быть сброшенным не было слишком трудно. Я просто должен был наблюдать то, что sshd и ssh делали для получения его набор правильно. Вот полный вывод всего, что я сделал по пути.

    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

Вместо того, чтобы использовать sudo для принуждения копирования моего ssh_host_ {dsa, rsa} _key файлы в место, я использовал ssh-keygen для создания фиктивных для меня.

    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.

Rinse-repeate с-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

Отредактируйте ~/dummy-sshd/sshd_config для указания на корректные новые ssh_host файлы ключей.

    # 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

Разожгите sshd на новом порте в режиме неотсоединения:

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

Возгласы, лучше исправьте тот путь:

    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.

Быстро всуньте новый терминал и ssh к localhost на порте 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

Посмотрите на последние три строки там. Я случайно имел набор ДИСПЛЕЯ и имел те две привлекательных строки от/usr/bin/xauth.

Оттуда это были детские игрушки, чтобы переместить в сторону мой/usr/bin/xauth в/usr/bin/xauth.old, разъединение от ssh и остановить sshd, затем запустить sshd, и ssh въезжают задним ходом к localhost.

Когда/usr/bin/xauth закончился, я не видел ДИСПЛЕЙ, отраженный в моей среде.


Нет ничего блестящего продолжения здесь. Главным образом я стал удачливым в выборе нормального подхода, чтобы попытаться воспроизвести это на моей локальной машине.

95
27.01.2020, 19:28
  • 1
    Ничего себе, огромное спасибо за Ваш anwer. Я делал все хорошее кроме export DISPLAY=:10. Я никогда не предполагал то количество дисплея. –  m3nda 01.11.2015, 00:34

Фиксация должна добавить эту строку к Вашему /etc/ssh/sshd_config:

X11UseLocalhost no

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

17
27.01.2020, 19:28
  • 1
    у меня есть 2 сервера Ubuntu. На том мне был нужен он набор к да, на другом это должно было быть нет. Я уверен, что существует объяснение, но стоит для попытки обоих. –  alfonx 19.08.2015, 16:08
  • 2
    Эта фиксация работала на меня!! –  rigon 12.12.2016, 14:23
  • 3
    разъяснитесь, означаете ли Вы помещать эту установку в клиентское –  Klik 09.03.2018, 04:35