SSH X11, не работающий

T610 также поддерживает системные сборки от встроенного Контроллера Жизненного цикла, и это должно поддерживать W2K8 со всеми включенными драйверами. Это работает от встроенной флэш-памяти, просто нажмите F10 при начальной загрузке и выберите сборку W2K8.

15
задан 6 March 2012 в 20:35
4 ответа

Причина, по которой пересылка ssh X не работала, заключалась в том, что у меня есть конфигурационный файл / etc / ssh / sshrc .

Конец sshd (8) страница руководства сообщает:

Если существует ~ / .ssh / rc , запускает его; иначе, если / etc / ssh / sshrc существует, запускает его; в противном случае запускается xauth

Поэтому я добавляю следующие команды в / etc / ssh / sshrc (также со страницы руководства sshd) на стороне сервера:

if read proto cookie && [ -n "$DISPLAY" ]; then
        if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                # X11UseLocalhost=yes
                echo add unix:`echo $DISPLAY |
                    cut -c11-` $proto $cookie
        else
                # X11UseLocalhost=no
                echo add $DISPLAY $proto $cookie
        fi | xauth -q -
fi

И это работает!

21
ответ дан 2 December 2019 в 20:50

Ваши конфигурации, кажется, в порядке, но действительно пробуют "ssh-X домой" как предложенный Agemen.

Кроме того, если все остальное перестало работать, попробуйте это:

После Вас ssh к Вашей домашней машине от работы, на "домашнем" типе:

xauth list

Затем на "работе" ввести

xauth

Который даст Вам "xauth>" подсказка. Отсюда, тип "добавляют", затем копируют, вставляют вывод "xauth список", одна строка за один раз (каждая строка, снабженная предисловием, "добавляют"). Например:

someguy@work:~$ xauth
Using authority file /var/run/gdm/auth-for-someguy-4MYV85/database
xauth> add work/unix:0  MIT-MAGIC-COOKIE-1  781cc753194fd55ecdf6c4cf105c40e3
xauth> 

Сообщите нам.

1
ответ дан 2 December 2019 в 20:50

Я не понимаю ясно, если Вы хотите отобразить свои удаленные приложения на Вашем локальном дисплее (work), или если Вы хотите отобразить их в удаленной системе (home).

В первом случае я думаю ssh -X host должен быть достаточно, без любой потребности использовать xhost.

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

xhost +work
export DISPLAY=:0.0

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

-1
ответ дан 2 December 2019 в 20:50

Каждый раз, когда у вас возникают проблемы с ssh, первое, что вам нужно сделать, это запустить клиент с опцией -v , чтобы предоставить этот вывод для проверки другими:

ssh -v user@somewhere

Я предполагаю, что проблема в вашей локальной системе. Как вы вызываете команду ssh? Вы запускаете его вручную в оболочке? Или он выполняется как часть сценария? В любом случае вы захотите убедиться, что в вашей локальной системе правильно настроена среда DISPLAY . Его также необходимо правильно установить на удаленной стороне, но это значение будет отличаться на удаленной стороне от локальной.

Из того, что вы написали, похоже, что оно устанавливается правильно на удаленном хосте (и, следовательно, пересылка X11 правильно настроена ssh). В удаленной системе у вас есть:

$ echo $DISPLAY
localhost:10.0

Что это показывает на местной стороне? Это должно быть легко проверить, если вы находитесь в оболочке, как путем повторения значения, так и запуска приложения X из этой оболочки ... вы всегда можете использовать почтенный xeyes для такого рода тестирования , конечно! :)

С другой стороны, если вы вызываете команду ssh из сценария или прикрепляете к горячей клавише, она может не унаследовать ожидаемую вами среду, поэтому переменная среды DISPLAY на локальной стороне может не устанавливается вообще.

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

На локальной стороне вы должны увидеть:

$ echo $DISPLAY
:0.0

В правильно настроенной системе, если вы открываете оболочку, вам не нужно устанавливать ее с помощью стороны, он должен быть унаследован от среды, в которой запущена ваша оболочка. Однако я видел конфигурации оконного менеджера / горячих клавиш, которые неправильно обрабатывают наследование переменных среды. Если в вашей системе Linux запущен gnome-session или kde-session , который вы используете для запуска своих оболочек или скриптов, тогда переменные среды X-сеанса должны быть установлены правильно, как описано в Документация Ubuntu о наследовании переменных среды :

Когда родительский процесс создает дочерний процесс, например, когда мы запускаем

На локальной стороне вы должны увидеть следующее:

$ echo $DISPLAY
:0.0

В правильно сконфигурированной системе, если вы открываете оболочку, вам не нужно устанавливать ее вручную, она должна быть унаследована от среды, в которой запущена ваша оболочка. Однако я видел конфигурации оконного менеджера / горячих клавиш, которые неправильно обрабатывают наследование переменных среды. Если в вашей системе Linux запущен gnome-session или kde-session , который вы используете для запуска своих оболочек или скриптов, тогда переменные среды X-сеанса должны быть установлены правильно, как описано в Документация Ubuntu о наследовании переменных среды :

Когда родительский процесс создает дочерний процесс, например, когда мы запускаем

На локальной стороне вы должны увидеть следующее:

$ echo $DISPLAY
:0.0

В правильно сконфигурированной системе, если вы открываете оболочку, вам не нужно устанавливать ее вручную, она должна быть унаследована от среды, в которой запущена ваша оболочка. Однако я видел конфигурации оконного менеджера / горячих клавиш, которые неправильно обрабатывают наследование переменных среды. Если в вашей системе Linux запущен gnome-session или kde-session , который вы используете для запуска своих оболочек или скриптов, тогда переменные среды X-сеанса должны быть установлены правильно, как описано в Документация Ubuntu о наследовании переменных среды :

Когда родительский процесс создает дочерний процесс, например, когда мы запускаем он должен быть унаследован от среды, в которой запущена ваша оболочка. Однако я видел конфигурации оконного менеджера / горячих клавиш, которые неправильно обрабатывают наследование переменных среды. Если в вашей системе Linux запущен gnome-session или kde-session , который вы используете для запуска своих оболочек или скриптов, тогда переменные среды X-сеанса должны быть установлены правильно, как описано в Документация Ubuntu о наследовании переменных среды :

Когда родительский процесс создает дочерний процесс, например, когда мы запускаем он должен быть унаследован от среды, в которой запущена ваша оболочка. Однако я видел конфигурации оконного менеджера / горячих клавиш, которые неправильно обрабатывают наследование переменных среды. Если в вашей системе Linux запущен gnome-session или kde-session , который вы используете для запуска своих оболочек или скриптов, тогда переменные среды X-сеанса должны быть установлены правильно, как описано в Документация Ubuntu о наследовании переменных среды :

Когда родительский процесс создает дочерний процесс, например, когда мы запускаем команда "gedit" из терминала и "bash" (родительский процесс) создает "gedit" (дочерний процесс), дочерний процесс наследует все переменные среды и значения, которые имел родительский процесс.

...

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

ОБНОВЛЕНО

Спасибо за публикацию вывода из ssh -vvv . В этом случае полезна дополнительная многословность -vvv по сравнению с просто -v . Отладочные данные говорят мне, что пересылка X11 настроена правильно:

debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 1: request x11-req confirm 1

Но : 0 в первой строке наводит меня на мысль, что на локальной стороне все еще существует ошибка конфигурации в том, как вы ' повторный вызов ssh. Во многих системах значение по умолчанию для ДИСПЛЕЙ составляет : 0,0 , а не : 0 . Вы каким-то образом устанавливаете значение DISPLAY вручную перед вызовом команды ssh?

На этом этапе будет полезно получить дополнительную информацию о вашей локальной системе и о том, как вы вызываете команду ssh.

  • Пожалуйста, укажите ваш дистрибутив Linux и номер версии.
  • Используете ли вы среду GNOME или KDE по умолчанию для X или что-то еще, что вы настроили самостоятельно?
  • Вы вызываете ssh непосредственно в командной строке из окна терминала?
  • Какой терминал вы используете? xterm, gnome-terminal или?
  • Как вы запустили терминал в среде X? Из меню? Горячая клавиша? или?
  • Можете ли вы запустить xeyes из того же окна терминала, где произошел сбой ssh -X ?
  • Вы вызываете команду ssh от имени того же пользователя, что и вы вошел в сеанс X как?

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

2
ответ дан 2 December 2019 в 20:50

Теги

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