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

<p>у меня есть машина с ubuntu, к которой я использую ssh со своей машины fedora 14. я хочу переслать x с компьютера с ubuntu обратно в fedora, чтобы я мог запускать графические программы удаленно. обе машины находятся в локальной сети.</p><p>я знаю, что <code>-x</code> опция включает пересылку x11 в ssh, но я чувствую, что пропускаю некоторые шаги.</p><p>каковы необходимые шаги для пересылки x с компьютера с ubuntu на fedora через ssh?</p>

<p>пересылка x11 должна быть включена как на стороне клиента, так и на стороне сервера.</p><p>на <strong> стороне клиента </strong> <code>-x</code> (заглавная x) опция <code>ssh</code> включает переадресацию x11, и вы можете сделать это по умолчанию (для всех соединений или для конкретного соединения) с помощью <code>forwardx11 yes</code> в <a href="http://man.openbsd.org/openbsd-current/man5/ssh\_config.5#forwardx11"><code>~/.ssh/config</code></a> .</p><p>на <strong> стороне сервера </strong> <code>x11forwarding yes</code> должен быть указан в <a href="http://man.openbsd.org/openbsd-current/man5/sshd\_config.5#x11forwarding"><code>/etc/ssh/sshd\_config</code></a> . обратите внимание, что по умолчанию перенаправление отсутствует (некоторые дистрибутивы включают его по умолчанию <code>/etc/ssh/sshd\_config</code>) и что пользователь не может переопределить этот параметр.</p><p>программа <code>xauth</code> должна быть установлена на стороне сервера. если там есть какие-либо программы x11, очень вероятно, что там будет <code>xauth</code>. в маловероятном случае <code>xauth</code> был установлен в нестандартном месте, его можно вызвать через <a href="http://man.openbsd.org/openbsd-current/man8/sshd.8#sshrc"><code>~/.ssh/rc</code></a> (на сервере!).</p><p>обратите внимание, что вам не нужно устанавливать какие-либо переменные среды на сервере. <code>display</code> и <code>xauthority</code> будут автоматически установлены в их правильные значения. если вы запускаете ssh, а <code>display</code> не задано, это означает, что ssh не пересылает соединение x11.</p><p>чтобы убедиться, что ssh пересылает x11, проверьте строку, содержащую <code>requesting x11 forwarding</code> в <code>ssh -v -x</code> вывод. обратите внимание, что <strong> сервер не будет отвечать </strong> в любом случае, что является мерой безопасности, скрывающей детали от потенциальных злоумышленников.</p>

<p>чтобы заставить пересылку x11 работать через ssh, вам понадобятся 3 вещи.</p><ol> <li>ваш клиент должен быть настроен на пересылку x11.</li> <li>ваш сервер должен быть настроен для разрешения пересылки x11.</li> <li>ваш сервер должен быть в состоянии настроить аутентификацию x11.</li> </ol><p>если у вас есть и № 1, и № 2, но отсутствует № 3, то в итоге вы получите пустую переменную окружения display.</p><p>вот как можно сделать так, чтобы x11 работал.</p><ol> <li> <p>на вашем сервере убедитесь, что/etc/ssh/sshd\_config содержит:</p> <pre><code>x11forwarding yes x11displayoffset 10 </code></pre> <p>вам может понадобиться sighup sshd, чтобы он воспринял эти изменения.</p> <pre><code>cat /var/run/sshd.pid | xargs kill -1 </code></pre></li> <li> <p>на вашем сервере убедитесь, что у вас установлен xauth.</p> <pre><code>belden@skretting:~$ which xauth /usr/bin/xauth  если у вас не установлен xauth, вы столкнетесь с проблемой "пустой переменной среды display".   на вашем клиенте подключитесь к вашему серверу. обязательно сообщите ssh, чтобы разрешить пересылку x11. я предпочитаю belden@skretting:~$ ssh -x blyman@the-server </code></pre></li> </ol><p>но тебе может понравиться</p><pre><code> 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. </code></pre><p>промойте и повторите с -t dsa:</p><pre><code> 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 </code></pre><p>ой, лучше исправьте этот путь:</p><pre><code> 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 </code></pre><p>посмотрите на последние три строки там. я, к счастью, установил display, и у меня были две красивые линии из/usr/bin/xauth.</p><p>оттуда была детская игра - переместить мой/usr/bin/xauth в /usr/bin/xauth.old, отключиться от ssh и остановить sshd, затем запустить sshd и ssh обратно на localhost.</p><p>когда/usr/bin/xauth пропал, я не увидел отображение display в моей среде.</p><hr><p>здесь нет ничего блестящего. в основном мне повезло в выборе нормального подхода, чтобы попытаться воспроизвести это на моей локальной машине.</p>

<p>убедись в том, что:</p><ul> <li>вы <code>xauth</code> установлены на сервере (см .: <code>xauth info</code>/<code>xauth list</code>).</li> <li> <p>на сервере твой <code>/etc/ssh/sshd\_config</code> файл имеет следующие строки:</p> <pre><code>x11forwarding yes x11displayoffset 10 x11uselocalhost no </code></pre></li> <li> <p>на стороне клиента ваш <code>~/.ssh/config</code> файл имеет следующие строки:</p> <pre><code>host * forwardagent yes forwardx11 yes </code></pre></li> <li> <p>на стороне клиента у вас установлен x-сервер (например, macos: xquartz; windows: xming).</p> </li> </ul><hr><p>затем, чтобы выполнить пересылку x11 с использованием ssh, вам необходимо <strong> добавить <code>-x</code> к вашей <code>ssh</code> </strong> команде, например.</p><pre><code>ssh -v -x user@host </code></pre><p>затем убедитесь, что ваш <code>display</code> <strong> не </strong> пуст:</p><pre><code>echo $display если это так, то иметь подробный параметр для ssh (-v), проверьте наличие любых предупреждений, например,.debug1: no xauth program. warning: untrusted x11 forwarding setup failed: xauth key data not generated если у вас  - ненадежный x11 как показано выше, тогда <strong> попробуйте -y флаг </strong> вместо этого (если вы доверяете хосту):ssh -v -y user@host см .: <a href="https://serverfault.com/q/273847/130437">что означает "предупреждение: сбой установки ненадежного x11: данные ключа xauth не сгенерированы", когда ssh'ing с -x? если вы  предупреждение: нет данных xauth, вы можете попытаться сгенерировать новый .xauthority файл, например.xauth generate :0 . trusted xauth list смотрите: <a href="http://justaix.blogspot.co.uk/2011/01/createrebuild-new-xauthority-file.html">создать/восстановить новый файл .xauthority если вы получили предупреждения, отличные от указанных выше, следуйте дальнейшим подсказкам.

исправление - добавить эту строку в ваш /etc/ssh/sshd_config:x11uselocalhost no  <a href="https://joshua.hoblitt.com/rtfm/2013/04/how_to_fix_x11_forwarding_request_failed_on_channel_0/">https://joshua.hoblitt.com/rtfm/2013/04/how_to_fix_x11_forwarding_request_failed_on_channel_0/ 

разрешение 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 как администратор (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, 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</code>, добавить <code>export display=localhost:0</code> на ваш <code>.bashrc</code> файл и сохраните его.</p><pre><code># ~/.bashrc ... ... export display=localhost:0 </code></pre><ul> <li>прошлой</li> </ul><p>мы почти закончили. перезапустите командную консоль bash, откройте программу <code>xming</code> и используйте <code>ssh -x yourusername@yourhost</code>. тогда наслаждайтесь средой gui.</p><pre><code>ssh -x yourusername@yourhost </code></pre><p>проблема также в подсистеме ubuntu на windows, и ссылка находится на</p><p> <a href="https://gist.github.com/destinyone/f236f71b9cdecd349507dfe90ebae776">https://gist.github.com/destinyone/f236f71b9cdecd349507dfe90ebae776</a> </p>

<p>добавить <code>x11uselocalhost no</code> до <code>/etc/ssh/sshd\_config</code> и перезапустите сервер ssh.</p><p>если у вас нет дисплея, проверьте, правильно ли установлен xauth, и попробуйте снова.</p><p>у rhe/centos такой проблемы нет, это ubuntu!</p>

<p>для меня проблема была в <strong>nodev</strong> опция монтирования для/tmp файловой системы. x11 нужен специальный файл для создания там.</p><p>так что проверьте, какие параметры монтирования для файловой системы/tmp, если вы используете для этого отдельный раздел или диск.</p>

<p>чтобы добавить к предыдущим отличные ответы (настройка <code>~/.ssh/config</code> и проверяет, установлена ли переменная окружения <code>display</code> на клиенте, настраивая <code>/etc/ssh/sshd\_config</code> и установив <code>xauth</code> на сервер), также убедитесь, что <code>xterm</code> установлено на клиенте, например,.</p><pre><code>sudo apt-get install xterm </code></pre>

<p><code>xauth</code> может быть заблокирован.</p><pre><code> -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. </code></pre><p>с помощью</p><pre><code>xauth -b </code></pre><p>на компьютере, на котором я пытался <code>ssh</code>, сломалась блокировка <code>xauth</code>. выход из сеанса <code>ssh</code> после выдачи <code>xauth -b</code> затем повторный вход позволил мне успешно <code>echo $display</code>. обязательно попробуйте это перед воссозданием <code>.xauthority</code></p>

<p><code>x11forwarding</code> должен быть установлен на ssh-сервере (в вашем случае на ubuntu box) в его <code>sshd\_config</code>, и вы должны разрешить пересылку x11 для клиента ssh (ваш ящик fedora), передав <code>-x</code> опция или редактирование <code>ssh\_config</code> файл для добавления <code>forwardx11</code> дефолт.</p>