X-клиент, переданный по SSH “, не может открыть дисплей: localhost:11.0”

disown самостоятельно достаточно, чтобы позволить программе продолжать бегать за Вами разъединение:

$ command_running_forever
^Z
zsh: suspended  command_running_forever
$ bg
[1]  + continued  command_running_forever
$ jobs
[1]  + running    command_running_forever
$ disown %1
$ logout

disown -h использует аргумент удара, который заставляет задание оставаться на таблице задания и не получает SIGHUP, когда удар получает SIGHUP (согласно удару help disown). Этот аргумент не доступен с zsh.

31
21.09.2018, 22:06
6 ответов

Это - очень простой способ того, как он должен работать:

На клиенте / локальная машина (Xorg, установленный на клиенте), пробуют это:

$ xhost +
access control disabled, clients can connect from any host

Более поздняя попытка:

$ ssh -AY user@host xterm

или

$ ssh -AX user@host xterm

С нестандартными клиентами может быть необходим xhost.

проверьте 9.3.5.6. Нестандартные X-клиенты

19
27.01.2020, 19:38
  • 1
    Насколько я знаю, xhost ACL даже не проверяется, если X передач сделаны по SSH. –  Martin 15.01.2014, 12:20
  • 2
    Вы правы, но по некоторым причинам иногда не работает как ожидалось. можно также попробовать это: - X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost yes больше на: X-передача –  nbari 15.01.2014, 12:27

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

-121--15976-

В униксах имена файлов являются только указателями (inodes), указывающими на память, в которой находится файл (который может быть жестким диском или даже файловой системой, поддерживаемой ОЗУ). Каждый файл записывает количество ссылок на него: ссылки могут быть либо именем файла (множественное число, при наличии нескольких жёстких ссылок на один и тот же файл), а также каждый раз при открытии файла процесс фактически удерживает «ссылку» на одно и то же пространство.

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

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

-121--15973-

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

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

Итак, некоторые сведения о том, как мы попали сюда. X11 не является самым безопасным протоколом. Он был разработан в более дружественные времена, и был ряд усилий, чтобы сделать его более безопасным в течение многих лет, в том числе проехать через безопасный туннель оболочки. X11 туннелирования уменьшает почти все уязвимости X11.Остается риск отображения окон из ненадежных систем. Была предпринята попытка объявить безопасное подмножество протокола, которое препятствовало бы развертыванию шифров ключей и тому подобного. Проект, хотя и технически успешен, имеет некоторые реальные проблемы, такие как странный факт, что найти программы, которые используют только безопасное подмножество, действительно трудно, потому что много отключенных функциональных возможностей очень удобно, и поскольку большинство людей пишут для локальной машины, которая имеет разрешение на использование полного протокола, есть мало диска для создания программ, которые работают с ограниченным подмножеством.

Другая возможность заключается в том, что переадресация X11 включена только на определенном хосте. Самый простой способ проверить, является ли это проблемой, это использовать флаг -Y с ssh для включения переадресации доверенных X11. Если это решение позволяет добавить обе прямые строки в соответствующие разделы хоста файла ssh config.

3
27.01.2020, 19:38

В моей (стандартной) среде Ubuntu я получил сообщение об ошибке xterm over ssh "... программа suid-root ..." (см. Выше), даже со всеми правильными настройками пересылки. Это поведение исчезло, вскоре sshd настроен на использование только IPv4 из-за ошибки пересылки X11 в SSH, если IPv6 в системе отключен.

vi /etc/ssh/sshd_config
AddressFamily inet

service ssh reload
2
27.01.2020, 19:38

Я редактировал

vim /etc/hosts

, добавил следующие строки

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

, и моя проблема исправлена:)

2
27.01.2020, 19:38

У меня была такая же проблема. Xauth отсутствовал на пульте дистанционного управления.

sudo apt-get install xauth

решил проблему.

13
27.01.2020, 19:38

я страдал от той же проблемы, все работало нормально после того, как я сделал следующее

  1. с не -рабочего терминала (корень в моем случае )настраиваю отображение :export DISPLAY=':0'и вы можете добавить его в /etc/environment, чтобы сделать его постоянным
  2. с рабочего терминала (пользовательский терминал в моем случае )запуститьxhost +local:
1
27.01.2020, 19:38

Теги

Похожие вопросы