nixp.ru v3.0

23 января 2017,
понедельник,
07:38:55 MSK

DevOps с компанией «Флант»
Anarchist написал 21 августа 2007 года в 13:34 (1323 просмотра) Ведет себя как мужчина; открыл 258 тем в форуме, оставил 4097 комментариев на сайте.

Есть сервер FreeBSD 6.2.

Надо организовать на него доступ по ssh с X11Forwarding с виндовой рабочей станции (запускается xterm).

В конфиге sshd прописаны все необходимые опции.

С моей рабочей станции (Gentoo Linux)

$ ssh -i .ssh/id_rsa -X $SERVERNAME /usr/local/bin/xterm -display $MYWORKSTATION:0.0

работает замечательно (естественно если сервер добавлен в список xhosts и файрволл не режет соединение).

Следовательно со стороны сервера всё настроено правильно.

Для случая рабочей станции выньдоуз (X Server стоит, xterm с обсуждаемого сервера пускается на ура, используется клиент Xmanager Enterprise 2.1 (Build 0021)) — ошибка форвардинга.

Genie

а это разве FORWARDING? убери -X и с твоей линуксовой станции тоже будет работать.

при ssh-x-fowrawd ssh-клиент создаёт дополнительный редиркт порта REMOTE:X+10 => LOCAL:X и настраивает должным образом аутентификацию дла этого типа соединений.

после этого в переменных окружения сессии выставляет DISPLAY=localhost:X+10

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

соответственно, давай, показывай как у тебя работает

$ ssh -X $SERVERIP /usr/local/bin/xterm
Anarchist
Genie
а это разве FORWARDING? убери -X и с твоей линуксовой станции тоже будет работать.

Справедливо.

Genie
соответственно, давай, показывай как у тебя работает

$ ssh -X $SERVERIP /usr/local/bin/xterm



$ ssh -X $SERVERIP /usr/local/bin/xterm
Enter passphrase for key '/home/ftn/.ssh/id_rsa':
/usr/local/bin/xterm Xt error: Can't open display:
/usr/local/bin/xterm:  DISPLAY is not set
Anarchist

Но в таком случае вопрос: какого … указанный виндовый клиент ломится с явным указанием этой опции?

Genie
/usr/local/bin/xterm Xt error: Can’t open display:

/usr/local/bin/xterm: DISPLAY is not set

собственно, надо смотреть ssh-конфигурацию как сервера, так и клиента на предмет ForwardAgent, ForwardX11, ForwardX11Trusted.

Но в таком случае вопрос: какого … указанный виндовый клиент ломится с явным указанием этой опции?

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

Anarchist
Genie
собственно, надо смотреть ssh-конфигурацию как сервера

Дык там из параметров относящихся к X11 форвардингу и присутствует лишь параметр 'X11Forwarding yes’.

Ну ещё из страницы руководства следует, что необходима постановка 'UseLogin no’.

Больше по серверу никаких параметров не нашёл.

Genie
так и клиента на предмет ForwardAgent, ForwardX11, ForwardX11Trusted.

После задания этих параметров в конфиге ssh на моей рабочей станции результат не изменился.

Anarchist

Вообще ситуация выглядит всё чудесатее и чудесатее.

ssh X11 forwarding not working on FreeBSD 6.2

На FreeBSD 4.11-RELEASE #0

С практически идентичным конфигом — утверждается, что работает (мне проверять лень).

Anarchist

Анализ проблемы (thanks to Genie) показал что причиной данного явления заключена в самой сути FreeBSD, а именно — в наличии двух параллельных наборов ПО: базового и устанавливаемого из портов.

В данном конкретном случае: при обновлении дерева портов была произведена смена версии Х-сервера (на отличную от той, с которой линковался дистрибутивный sshd).

Следовательно решение очевидно: пересобрать sshd. Как будет время и физическая возможность (опыты с доработкой напильником вспомогательной и реально не шибко необходимой функциональности на боевом сервере — занятие для истинных джидаев, к которым я себя не отношу).

Anarchist

Предположения относительно способа решения проблемы оказались неверными.

Точнее — таким способом она решается не так просто, как хотелось бы.

Использован обходной путь:

# cd /usr/X11R6/bin/
# ln -s /usr/local/bin/xauth xauth

Всё работает.

Правильная формулировка вопроса: «FreeBSD 6.2: sshd X11 Forwarding && Xorg 7.2».

Источник вдохновения.

Genie

ну, тут явно различия в том, с какими флагами что пересобиралось…

возможно, при сборке бинарников для дистрибутивных CD используется дополнительное окружение.

Anarchist
Genie
ну, тут явно различия в том, с какими флагами что пересобиралось…

И путями.

Безусловно.

Genie
возможно, при сборке бинарников для дистрибутивных CD используется дополнительное окружение.

Нет.

Просто при сборке бинарников в дистрибутиве использовались другие пути для команд.

В очередной версии XOrg (и/или поворотом извилин мэйнтейнера порта) пути поменялись. И скомпиллированные бинарники не находят нужных им команд по зашитым путям.

Для sshd X11 Forwarding это — xauth. Можно было решить проблему правкой конфига, но кто знает кто ещё ищет эту команду по указанному пути. Поэтому посчитал более правильным создание символической ссылки. Что не решает проблемы в случае поиска каким-либо другим приложением другой команды XOrg в /usr/X11R6/bin. Ну да ладно, проблемы надо решать по факту их возникновения.

Anarchist

По состоянию на срез портов примерно месячной давности для случая разворачиваемой с нуля системы эту фичу сломали уже иначе:

Каталог /usr/X11R6 ещё создаётся, но в нём кроме пустых каталогов уже ничего нет.

Каталог /usr/X11R6/bin отсутствует.

На всякий случай после удаления каталога /usr/X11R6 я создал символическую ссылку /usr/X11R6 указывающую на /usr/local.

После установки xterm’а симптомы наблюдались идентичные исходным.

Проблема уже была выявлена. В данном случае всё выглядело круче: xauth в системе просто отсутствовал.

Соответственно решением проблемы явилось:

# cd /usr/ports/x11/xauth
# make && make install && make clean
ecobeingecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.