Удаленный x-сервер с ssh -X

12

Я пытаюсь запустить сеанс удаленного гнома с помощью: ssh -X username@192.168.1.107 gnome-session

И клиент, и сервер имеют версию Ubuntu 12.04

Я получаю следующее (и не так много происходит) ...

GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
GNOME_KEYRING_PID=3573
GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
SSH_AUTH_SOCK=/tmp/keyring-3aeNAh/ssh
GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
SSH_AUTH_SOCK=/tmp/keyring-3aeNAh/ssh

(gnome-settings-daemon:3572): color-plugin-WARNING **: failed to get contents of /sys/class/dmi/id/board_version: Failed to open file '/sys/class/dmi/id/board_version': No such file or directory

** (gnome-settings-daemon:3572): WARNING **: You can only run one xsettings manager at a time; exiting

** (gnome-settings-daemon:3572): WARNING **: Unable to start xsettings manager: Could not initialize xsettings manager.
compiz (core) - Error: Screen 0 on display "localhost:10.0" already has a window manager; try using the --replace option to replace the current window manager.
Initializing nautilus-gdu extension
Created new window in existing browser session.
** Message: applet now removed from the notification area
** Message: using fallback from indicator to GtkStatusIcon

(gnome-settings-daemon:3572): keyboard-plugin-WARNING **: Failed to set the keyboard layouts: GDBus.Error:org.freedesktop.Accounts.Error.PermissionDenied: Not authorized

** (gnome-settings-daemon:3572): WARNING **: Failed to connect context: Connection refused

(gnome-settings-daemon:3572): clipboard-plugin-WARNING **: Clipboard manager is already running.

(gnome-settings-daemon:3572): color-plugin-WARNING **: failed to create device: GDBus.Error:org.freedesktop.ColorManager.Failed: failed to obtain org.freedesktop.color-manager.create-device auth

(gnome-settings-daemon:3572): color-plugin-WARNING **: GDBus.Error:org.freedesktop.ColorManager.Failed: failed to obtain org.freedesktop.color-manager.create-profile auth

(gnome-settings-daemon:3572): color-plugin-WARNING **: no xrandr-Samsung Electric Company-SAMSUNG device found: Failed to find output xrandr-Samsung Electric Company-SAMSUNG
Shutting down nautilus-gdu extension

** (gnome-settings-daemon:3572): WARNING **: Failed to connect context: Connection refused
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
ssh xserver benlad
источник
Я хотел получить удаленный доступ к машине с Ubuntu, используемой в качестве медиасервера / плеера, без изменения того, что происходит на дисплее удаленной машины. Также я просто хотел поиграть с этим материалом, чтобы посмотреть, на что он способен. :-)
Бенлад
1
Если вы хотите поиграть, я ввел ответ с некоторыми советами по использованию базового ssh из командной строки, включая генерацию ключа и его копирование на удаленный хост. Когда вы научитесь использовать ssh, вы можете быть удивлены тем, как много можно сделать, используя его.
Марти Фрид

Ответы:

12

Я предполагаю, что вы пытаетесь запустить полный сеанс удаленного просмотра Gnome на вашем локальном компьютере. Это терпит неудачу, потому что у вас уже есть локальный менеджер сеанса, управляющий отображением вашего X-сервера.

Ваши варианты:

  1. Просто запустите отдельные удаленные приложения, используя ssh -X user@192.168.1.107 xclock

  2. Предполагая, что XDMCP включен на удаленной машине ...

    2а. Используйте Xnest -query 192.168.1.107 -geometry 1024x768 :1для запуска сеанса удаленного входа в локальное окно.

    2b. Используйте Xephyr :1 -screen 1024x768 -query 192.168.1.107лучший сервер X, чемXnest

  3. Также предполагая XDMCP на удаленном компьютере, настройте локальный компьютер на использование переключателя XDMCP вместо стандартного приветствия при запуске.

Включение XDMCP - это просто случай

[xdmcp]
Enable=true

в /etc/gdm/custom.confи перезапуска gdmили перезагрузки (если вы работаете gdm).

Если вы собираетесь запускать только несколько приложений удаленно, то вариант 1 является наиболее простым и продолжает использовать зашифрованный трафик SSH, чего не делают другие (поэтому их лучше всего использовать только в доверенной локальной сети).

Если вам нужно что-то более сложное, то 2b (Xephyr) может быть лучше, но я обычно считаю достаточным использование только ssh -X ... &нескольких удаленных приложений.

Если вы все делаете удаленно, то есть локальный компьютер - это просто сервер отображения и ничего не делает сам по себе, тогда вам нужно использовать вариант 3, запускающий средство выбора XDMCP вместо стандартного входа в систему.

PS: Как отмечено в комментариях, оба Xnestи Xephyrявляются приложениями, которые обрабатывают протокол X-сервера и помещают весь сеанс в окно. Xnestиспользует функции, предоставляемые локальным X-сервером, и в то же время Xephyrобрабатывает гораздо больше самого протокола сервера, поэтому является более надежным. Они не могут быть установлены по умолчанию, потому что средний пользователь не будет их использовать.

PPS: После небольшого размышления становится очевидным, как зашифровать Xephyrили Xnestсеанс ...

ssh -X username@192.168.1.107 Xephyr :1 -query localhost -screen 1280x1024
StarNamer
источник
1
Может быть полезно указать, что делает Xnest / Xephyr и почему, поскольку они не установлены по умолчанию, я не думаю. Я никогда не находил необходимости использовать xdmcp, поэтому я понятия не имею сам. Я использую простой ssh -Yиз терминала, а затем запустить то, что мне нужно оттуда.
Марти Фрид
@MartyFried: похоже, что оба X-сервера могут работать в окне. Похоже, что пользователь хочет перенаправить весь сеанс / дисплей. Лично я бы просто использовал VNC, который создает новый дисплей на существующем X-сервере и избавил меня от головной боли.
иш
@izx: В прошлом я использовал VNC для систем Windows, но с двумя системами Ubuntu мне обычно нравится встроенный ssh, хотя иногда я запутываюсь при запуске приложений с графическим интерфейсом, поскольку трудно отличить локальные от удаленных приложений. Но то, что я делаю (в основном редактирование с сервера или администрирование), кажется, работает лучше всего.
Марти Фрид
1
@MartyFried Недостатком VNC является то, что вы просто управляете дисплеем удаленного компьютера. Таким образом, невозможно, чтобы один пользователь вошел в систему на этом экране, а другой пользователь подключился удаленно. Решения XDMCP содержат абсолютно отдельные сеансы, позволяющие двум или более пользователям использовать один и тот же компьютер.
StarNamer
Ваше решение 2b сработало. Я попробовал версию ssh, но у меня была проблема с ключами ssh. Сообщение слишком длинное для размещения здесь. Я буду использовать метод, который работает на данный момент.
benlad
0

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

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

генерировать ключ (при необходимости можно использовать dsa вместо rsa)

ssh-keygen -t rsa

передать ключ на удаленный хост

ssh-copy-id <username>@<host>

если не стандартный порт 22, используйте это: Примечание кавычки вокруг аргумента

ssh-copy-id "<username>@<host> -p <port_nr>"

Если используется dsa, есть немного другая команда, добавляющая -i <homedirectory>/.ssh/id_dsa

Где-то после этого вам нужно будет ввести пароль, который отличается от вашего обычного пароля для входа. Это было давно, и я забыл точную последовательность, но это должно быть очевидно. Затем при первом подключении вам будет предложено ввести пароль один раз. Я использую то же имя для входа, поэтому мне не нужно вводить имя пользователя (оно предполагает то же самое, что и удаленное имя пользователя). Кроме того, для серверов вашей локальной сети вы можете ввести «.local» вместо IP-адреса, я считаю (работает для меня).

Вы даже можете смонтировать удаленную файловую систему, используя sshfs (при условии, что sshfs установлен); подставьте путь к каталогу для local-mount-directory:

sshfs remote-host: local-mount-directory

(размонтировать используя fusermount -u local-mount-directory)

Я думаю, что он будет использовать ваш домашний каталог по умолчанию, если вы не включите local-mount-directory. `

Копирование файлов может быть сделано с помощью scp.

Марти Фрид
источник