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

Для получения передачи 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 закончился, я не видел ДИСПЛЕЙ, отраженный в моей среде.

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

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

X11UseLocalhost no

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

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

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

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

Если вы не видите ДИСПЛЕЙ, проверьте, правильно ли установлен xauth, а затем повторите попытку.

RHE / CEntos не имеет этой проблемы, это вещь Ubuntu!

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

• На сервере установлен xauth (см .: информация о xauth / список xauth ).

• На сервере ваш файл / 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

затем убедитесь, что ваш ДИСПЛЕЙ не пуст:

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 с параметром -X?}

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

xauth generate :0 . trusted
xauth list

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

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

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

sudo apt-get install xterm

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

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

• Первый

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

sudo apt install ssh xauth xorg

• Второй

Перейдите в папку, содержащую ssh_configфайл, у меня /etc/ssh.

• Третий

Редактировать ssh_configкак администратор (ИСПОЛЬЗОВАТЬ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, XauthLocation /usr/bin/xauth, не забудьте написать ваш собственный путь к файлу xauth.

# /etc/ssh/ssh_config

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

• Пятый

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

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

• Последний

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

ssh -X yourusername@yourhost

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

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

Если вы выполняете ssh из Windows (10 )в систему Linux -, сделайте себе одолжение и используйте SSH-клиент, такой как Putty (обычный ssh ​​-X и т. д. не работает ).

Шаг 1 :Установка XServer в Windows :Пример сервера XMing (прослушивает локальный хост :0.0)

Шаг 2 :В putty включить переадресацию X11

Шаг 3 :Подключиться к удаленному серверу Linux

Убедитесь, что на сервере Linux соблюдены все условия -, то есть X11Forwarding — да, и xauth присутствует, как объяснено в ответеhttps://unix.stackexchange.com/a/12772/121634

Запустите XClock и подождите минуту, пока дисплей не появится на вашем компьютере с Windows

Примечание. -Если с этого сервера Linux вы подключаетесь к другому серверу и хотите перенаправить X11 обратно на Windows, вам просто нужно подключиться к следующему в цепочке с помощью ssh -X.

То есть

[Windows] Putty (с X11forwarding)--> [Сервер1] (xclock работает)--> ssh -X [Сервер 2] (xclock работает)