Как исправить ошибку "невозможно открыть дисплей" при открытии программы X после ssh с включенной переадресацией X11?

Question

После запуска приложения X11 (XQuartz 2.3.6, xorg-server 1.4.2-apple56) на моем Mac (OS X 10.6.8), открытия терминала в X11 и запуска xhost + , я затем ввел ssh -Y в свою Ubuntu 10.04 ВМ (работает на VMware Fusion). Когда я запускаю gedit .bashrc (например), я получаю:

(gedit:9510): Gtk-WARNING **: cannot open display: 

set | grep DISPLAY ничего не возвращает.

Но если я ssh -Y на мою машину с Ubuntu 11.04, gedit .bashrc работает. echo $DISPLAY возвращает "localhost:10.0".

Я попытался export DISPLAY=localhost:10.0 то время как sshed в мою ВМ и затем запустил gedit .bashrc , но я получаю:

(gedit:9625): Gtk-WARNING **: cannot open display: localhost:10.0

Что может отличаться в конфигурации двух разных машин Ubuntu, что объясняет, почему один работает, а другой нет?

Обновление: как предложено Zoredache в комментарии ниже, я запустил sudo apt-get install xbase-clients , но у меня продолжает оставаться та же проблема.

Answer 1

От xhost+: Как исправить ошибку «Cannot Open Display» при запуске графического интерфейса на удаленном сервере:

Ответ: Вы можете исправить ошибку «не могу открыть дисплей», выполнив процедуру xhost, упомянутую в этой статье.

Разрешить клиентам подключаться с любого хоста, используя xhost +

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

$ xhost +

контроль доступа отключен, клиенты могут подключаться с любого хоста

Включить пересылку X11

При выполнении ssh используйте опцию -X для включения пересылки X11.

$ ssh username@hostname -X

Включите доверенную пересылку X11, используя опцию -Y,

$ ssh username@hostname -Y

Откройте приложения GUI на этом хосте

После открытия ssh-соединения с удаленным хостом, как описано выше, вы можете открыть любое приложение с графическим интерфейсом, которое откроет его без каких-либо проблем.

Если вы по-прежнему получаете сообщение об ошибке «Не удается открыть дисплей», установите переменную DISPLAY, как показано ниже.

$ export DISPLAY='IP:0.0'

Примечание. IP - это IP-адрес локальной рабочей станции, на котором вы хотите отобразить приложение с графическим интерфейсом.

Answer 2

Проверьте sshd_config сервера (обычно это /etc/ssh/sshd_config) и убедитесь, что опция X11Forwarding включена со строкой

X11Forwarding yes

Если X11Forwarding не указан, по умолчанию на компьютерах Debian, которые я могу проверить, по умолчанию нет.

Answer 3

У меня была эта проблема при входе в Ubuntu VM из Mac OS X, а также - по некоторым причинам он не похож на localhost в отображаемой переменной. Так что установите IP вручную, как предлагает harrymc:

export DISPLAY="127.0.0.1:10.0"

Тогда программы X11 должны быть в порядке. Не похоже, что нужно указывать ОС, что localhost и 127.0.0.1 эквивалентны, но это работает, по крайней мере.

Answer 4

У меня была эта проблема с моим сервером CentOS KVM, мне не хватало программы "xauth".

Answer 5

Если у вас возникла эта проблема через некоторое время при запуске с -X arg. или просто ForwardX11 в /etc /ssh /ssh_config, затем запустите $ ssh username@hostname -Y , чтобы включить надежную пересылку X11 , не знаю точную причину, но я предполагаю, что с -X некоторые функции устаревают через некоторое время, вероятно повысить безопасность.

Вот что я нашел в Интернете:

Если вы используете ssh -X remotemachine, то удаленный компьютер считается ненадежным клиентом. Таким образом, ваш локальный клиент отправляет команду на удаленный компьютер и получает графический вывод. Если ваша команда нарушает некоторые настройки безопасности, вы получите сообщение об ошибке.

Но если вы используете ssh -Y remotemachine, удаленный компьютер считается доверенным клиентом. Этот последний вариант может открыть проблемы безопасности. Потому что другой графический (X11) клиент может прослушивать данные с удаленного компьютера (делать снимки экрана, делать кейлоггинг и другие неприятные вещи), и даже можно изменить эти данные.

Если вы хотите узнать больше об этих вещах, я предлагаю прочитать справочную страницу Xsecurity или спецификацию расширения X Security. Кроме того, вы можете проверить параметры ForwardX11 и ForwardX11Trusted в вашем /etc /ssh /ssh_config.

источники:

• в чем разница между ssh -Y и ssh -X
• предупреждение cygwin/X: не удалось открыть дисплей X

Answer 6

Только что протестировано на моем Mac, другие системы могут быть в порядке:

1. Разрешить клиентам подключаться с любого хоста, используя xhost +

   $ xhost +

2. Вы должны иметь среду, которая поддерживает дисплей X11

   [Mac System] Установите X11 для Mac https://www.xquartz.org/

3. Вы должны позволить вашему ssh-серверу пересылать x11 дисплей

   обновите /etc/ssh/sshd_config и установите X11Forwarding yes , затем перезапустите ваш ssh-сервер

4. Вы должны позволить вашему сеансу SSH пересылать x11 с параметром -X

   $ ssh -X user @ ip

5. Как открыть приложение X11 в PyCharm?

   • откройте сеанс ssh с поддержкой дисплея X11 (не забудьте сохранить этот сеанс)
   • запустите echo $DISPLAY в этом сеансе SSH
   • установить переменную окружения DISPLAY для вашего PyCharm

Answer 7

При запуске UXTERM или XTERM просто выдайте

export $DISPLAY 

Переменная будет там. Затем просто установите его и экспортируйте.

Answer 8

Я должен был поместить в /etc/ssh/sshd_config следующее:

X11UseLocalhost no

Скорее тогда установив это "да". Странно, если по умолчанию "НЕТ". Пользователи, использующие замазку с XMing под Windows Я использую прямой SSH над Fedora. Иногда это начало давать нам

error can't open display localhost

Перезагрузка сервера обычно исправляет это, но это глупо. Сделал вышеописанное, перезапустил службу sshd на сервере и предустановил новые соединения, снова работает нормально.

Answer 9

Я также имел эту проблему с Solaris 10 и обнаружил, что слушатель не был настроен.

svccfg –s /application/x11/x11-server listprop options/tcp_listen
svccfg –s /application/x11/x11-server setprop  options/tcp_listen = true

Answer 10

На CentOS 6.5 я внезапно потерял удаленный доступ к X-программам после работы с /etc /hosts. Тот же признак пустой переменной $ DISPLAY (не помогает установка / экспорт вручную).

Запись 127.0.0.1, указывающая на фактическое имя хоста, необходима; на самом деле, порядок, похоже, тоже актуален (поставьте последний, и он не будет работать ...)

[root@poseidon /etc]$ cat hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain localhost
::1     localhost6.localdomain6 localhost6
127.0.0.1 poseidon.mycampus.edu poseidon
1XX.XXX.XXX.208 poseidon.mycampus.edu poseidon

После исправления этой проблемы xeyes, xclock и другие тестовые игрушки X снова работают, поэтому мой нужный virt-manager также вернулся в строй.

Answer 11

открыть терминал $ ssh username @ hostname -X

$ ssh username@hostname -Y

$ export DISPLAY='IP:0.0'

export DISPLAY = "127.0.0.1:10.0" все должно работать.

Answer 12

Если вы используете Konsole, просто переключитесь на другой эмулятор терминала, такой как Xfce Terminal, и попробуйте снова с помощью root.

Answer 13

Я только что нашел хороший сбой в моей настройке, который предотвращал переадресацию x: мой брандмауэр блокировал все соединения от localhost, таким образом препятствуя достижению туннеля

Answer 14

После большого разочарования я обнаружил, что запись для имени хоста сервера в его файле /etc /host была неправильной.