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

346

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

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

Каковы необходимые шаги для пересылки X с компьютера с Ubuntu на Fedora через SSH?

Мистер Шикаданс
источник
6
Я знаю, что это довольно часто, но у меня есть проблемы. Окончательный ответ на этот вопрос будет полезен для многих. Многие примеры вокруг, кажется, опускают важные детали.
Мистер Шикаданс

Ответы:

414

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

На стороне клиента , то -X(капитал X) вариант sshвключает перенаправление X11, и вы можете сделать это по умолчанию (для всех соединений или для конкретного Conection) с 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выводе. Обратите внимание, что сервер не будет отвечать никоим образом, в качестве меры предосторожности для сокрытия подробностей от потенциальных злоумышленников.

жилль
источник
31
@user: Нет, тебе никогда не нужно xhost +. xhostиз более мягкой эпохи, когда подключение машины к сети означало, что вы заслуживаете доверия. xhost +означает, что любой, кто может подделать ваш IP, может взять под контроль сеанс вашего X-сервера. ssh -Xустановит все необходимые разрешения. Если пересылка X11 отключена в конфигурации сервера, обратитесь к администратору; если это не сработает, см. Пересылка X11 через SSH, если конфигурация сервера не позволяет этого .
Жиль
6
Спасибо за упоминание xauth! Отсутствие этого на базовом сервере доставляло мне неприятности.
Васи
5
+1 за различие между ~/.ssh/configи /etc/ssh/sshd_configв одном и том же месте. Я не мог сказать, были ли они различными файлами или просто изменением номенклатуры.
Пук
1
@KhurshidAlam Не имеет значения, работает ли на сервере среда графического интерфейса. Проверьте разрешения на .Xauthorityфайл. Если вы используете Red Hat или другую систему с SELinux, проверьте контекст SELinux, см. Unix.stackexchange.com/questions/36540/…
Жиль
8
после ssh -Xзапуска, xterm &чтобы получить графический терминал в качестве окончательного теста, чтобы увидеть, работает ли он.
Александр Тейлор
88

Чтобы заставить пересылку X11 работать через ssh, вам понадобятся 3 вещи.

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

Если у вас есть и № 1, и № 2, но отсутствует № 3, то в итоге вы получите пустую переменную окружения DISPLAY.

Суп-о-о, вот как заставить работать пересылку 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, вы столкнетесь с проблемой «пустая переменная окружения DISPLAY».

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

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

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

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

или вы можете установить это в вашем ~ / .ssh / config.


Я столкнулся с этой пустой переменной среды DISPLAY ранее сегодня, когда ssh'ing на новый сервер, который я не администрирую. Отследить недостающую часть xauth было немного весело. Вот что я сделал, и что вы можете сделать тоже.

На моей локальной рабочей станции, где я являюсь администратором, я проверил, что / etc / ssh / sshd_config был настроен для пересылки X11. Когда я возвращаю ssh -X к localhost, мой DISPLAY устанавливается правильно.

Принудительное отключение DISPLAY не было слишком сложным. Мне просто нужно было посмотреть, что делают 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.

Промойте и повторите с -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 на новом порту в режиме non-detach:

    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 на локальный хост на порт 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

Посмотрите на последние три строки там. Я, к счастью, установил DISPLAY, и у меня были две красивые строки из / usr / bin / xauth.

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

Когда / usr / bin / xauth пропал, я не увидел отображение DISPLAY в моей среде.


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

Belden
источник
1
Вау, спасибо тебе большое за твой ответ. Я делал все хорошо, кроме export DISPLAY=:10. Я никогда не догадывался о таком количестве показа.
erm3nda
Это смещение дисплея 10! : D
41754
34

Убедитесь что:

  • Вы xauthустановили на сервере (см .: xauth info/ xauth list).
  • На сервере ваш /etc/ssh/sshd_configфайл имеет следующие строки:

    X11Forwarding yes
    X11DisplayOffset 10
    X11UseLocalhost no
    
  • На стороне клиента ваш ~/.ssh/configфайл имеет следующие строки:

    Host *
      ForwardAgent yes
      ForwardX11 yes
    
  • На стороне клиента у вас установлен X-сервер (например, macOS: XQuartz; Windows: Xming).


Затем, чтобы выполнить пересылку X11 с использованием SSH, вам нужно добавить -Xв своюssh команду, например,

ssh -v -X user@host

убедитесь , что ваш DISPLAYявляется не пустым путем:

echo $DISPLAY

Если это так, то имея подробный параметр для ssh ( -v), проверьте наличие любых предупреждений, например

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

Если у вас ненадежный X11, как показано выше, попробуйте-Y вместо этого флаг (если вы доверяете хосту):

ssh -v -Y user@host

См .: Что означает «Предупреждение: не удалось установить ненадежную пересылку X11: данные ключа xauth не сгенерированы» при ssh'ing с -X?


Если вы предупреждаете: нет данных xauth , вы можете попробовать создать новый .Xauthorityфайл, например

xauth generate :0 . trusted
xauth list

См .: Создание / перестройка нового файла .Xauthority.


Если вы получили предупреждения, отличные от указанных выше, следуйте дальнейшим подсказкам.


kenorb
источник
1
Полное руководство: Конфигурация на стороне клиента
пометила разницу
2
и X11UseLocalhost нет на стороне сервера
user2928048
17

Исправление заключается в добавлении этой строки в ваш /etc/ssh/sshd_config:

X11UseLocalhost no

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

туз
источник
У меня есть 2 сервера Ubuntu. На одном мне нужно было установить да, на другом - нет. Я уверен, что есть объяснение, но стоит попробовать оба.
alfonx
1
Это исправление сработало для меня!
Ригон
3
Пожалуйста, уточните, хотите ли вы установить этот параметр на сервере или клиенте
Klik
5

Запуск Ubuntu bash в Windows 10 ssh -X для получения среды графического интерфейса на удаленном сервере.

  • Первый

Установите все следующее. В окне установите Xming. В Ubuntu bash используйте sudo apt installдля установки ssh xauth xorg.

sudo apt install ssh xauth xorg
  • второй

Зайдите в папку с ssh_configфайлом, мой есть /etc/ssh.

  • Третий

Изменить ssh_configкак администратор (USE sudo). Внутри ssh_config, удалить хэш #в строках ForwardAgent, ForwardX11, ForwardX11Trustedи установить соответствующие аргументы yes.

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes
  • вперед

В ssh_configфайле удалите передний хеш #до Port 22и Protocol 2, а также добавьте новую строку в конце файла, чтобы указать местоположение файла xauth, не XauthLocaion /usr/bin/xauthзабудьте написать собственный путь к файлу xauth.

# /etc/ssh/ssh_config

#   IdentifyFile ...
    Port 22
    Protocol 2
#   Cipher 3des
#   ...
#   ...
    ...
    ...
    GSSAPIDelegateCredentials no
    XauthLocaion /usr/bin/xauth
  • пятый

Теперь, когда мы закончили редактирование ssh_configфайла, сохраните его, когда мы покинем редактор. Теперь перейдите в папку ~или $HOMEдобавьте export DISPLAY=localhost:0в свой .bashrcфайл и сохранить его.

# ~/.bashrc
...
...
export DISPLAY=localhost:0
  • Прошлой

Мы почти закончили. Перезапустите оболочку bash, откройте свою Xmingпрограмму и используйте ssh -X yourusername@yourhost. Тогда наслаждайтесь средой GUI.

ssh -X yourusername@yourhost

Проблема также в подсистеме Ubuntu на Windows, и ссылка находится на

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

DestinyOne
источник
3

Добавить X11UseLocalhost noк /etc/ssh/sshd_configи перезапустить сервер SSH.

Если у вас нет DISPLAY, проверьте, правильно ли установлен xauth, и попробуйте снова.

У RHE / CEntos такой проблемы нет, это Ubuntu!

Стивен Кук
источник
1

Для меня проблема была в опции монтирования nodev для / tmp файловой системы. X11 нужен специальный файл для создания там.

Так что проверьте, какие параметры монтирования для файловой системы / tmp, если вы используете для этого отдельный раздел или диск.

yakovpol
источник
1
Я думаю, что вы, возможно, захотите увидеть другие ответы на исходный вопрос и уделить минутку, чтобы подумать, как ваш собственный ответ улучшит их.
Сами Лэйн
1

Чтобы добавить к предыдущим отличным ответам (настройка ~/.ssh/configи проверка, установлена ​​ли DISPLAYпеременная окружения на клиенте, настройка /etc/ssh/sshd_configи установка xauthна сервере), также убедитесь, что xtermна клиенте установлена, например,

sudo apt-get install xterm
Ализ Рао
источник
1

xauth может быть заблокирован.

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

С помощью

xauth -b

На машине, на которой я пытался sshвзломать замок xauth. Выход из sshсеанса после выдачи, а xauth -bзатем повторный вход, наконец, позволил мне успешно echo $DISPLAY. Обязательно попробуйте это перед воссозданием.Xauthority

Бартон Читтенден
источник
0

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

Калеб
источник
1
Вам также необходимо xauthустановить его на удаленном компьютере, иначе программа x authorization не будет работать.
Фахим Митха
Как насчет настройки DISPLAY?
Мистер Шикаданс
1
ssh автоматически установит, $DISPLAYесли X11Forwardingон включен и xauthприсутствует в клиентской системе.
Шадур
1
@ Шадур Не для меня. Это работает, когда я, export DISPLAY=:10.0но не иначе. В противном случае он жалуется, что не может найти :0. Может быть, нужно что-то еще, чтобы это произошло автоматически?
ср