SSH X11 не працює


15

У мене домашній і робочий комп'ютер, домашній комп'ютер має статичну IP-адресу.

Якщо я перебуваю з робочого комп'ютера на домашній комп'ютер, ssh-з'єднання працює, але програми X11 не відображаються.

У мене /etc/ssh/sshd_configвдома:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

На роботі я спробував такі команди:

xhost + home HOME_IP
ssh -X home
ssh -X HOME_IP
ssh -Y home
ssh -Y HOME_IP

Моя /etc/ssh/ssh_configна роботі:

Host *
ForwardX11 yes 
ForwardX11Trusted yes

Моя ~/.ssh/configна роботі:

Host home
HostName HOME_IP
User azat
PreferredAuthentications password
ForwardX11 yes

Моя ~/.Xauthorityна роботі:

-rw------- 1 azat azat 269 Jun  7 11:25 .Xauthority

Моя ~/.Xauthorityвдома:

-rw------- 1 azat azat 246 Jun  7 19:03 .Xauthority

Але це не працює

Після того, як я встановлю ssh-з'єднання додому:

$ echo $DISPLAY
localhost:10.0

$ kate
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
kate: cannot connect to X server localhost:10.0

Я використовую iptablesвдома, але дозволений порт 22. Відповідно до прочитаного, це все, що мені потрібно.

UPD. З-vvv

...
debug2: початок зворотного виклику
debug2: x11_get_proto: / usr / bin / xauth list: 0 2> / dev / null
debug1: запит на переадресацію X11 з підробкою аутентифікації.
debug2: канал 1: запит x11-req підтвердження 1
debug2: client_session2_setup: id 1
debug2: fd 3 налаштування TCP_NODELAY
debug2: канал 1: запит pty-req підтвердження 1
...

При спробі запуску kate:

debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: запит від 127.0.0.1 55486
debug2: fd 8 налаштування O_NONBLOCK
debug3: fd 8 - O_NONBLOCK
debug1: канал 2: новий [x11]
debug1: підтвердити x11
debug2: підключення X11 використовує різні протоколи аутентифікації.
З’єднання X11 відхилено через неправильну аутентифікацію.
debug2: X11 відхилено 2 i0 / o0
debug2: канал 2: читання не вдалося
debug2: канал 2: close_read
debug2: канал 2: вхід відкритий -> злив
debug2: канал 2: ibuf порожній
debug2: канал 2: надіслати eof
debug2: канал 2: вхідний стік -> закрито
debug2: канал 2: запис не вдалося
debug2: канал 2: close_write
debug2: канал 2: вихід відкритий -> закритий
debug2: X11 закрито 2 i3 / o3
debug2: канал 2: надіслати закрити
debug2: канал 2: закрити rcvd
debug2: канал 2: мертвий
debug2: канал 2: збирання сміття
debug1: канал 2: безкоштовно: x11, nchannels 3
debug3: канал 2: статус: відкриті наступні з'єднання:
  №1 клієнт-сеанс (t4 r0 i0 / 0 o0 / 0 fd 5/6 cc -1)
  # 2 x11 (t7 r2 i3 / 0 o3 / 0 fd 8/8 cc -1)

# Те саме, що вище, повторіть приблизно 7 разів

kate: не вдається підключитися до X-сервера localhost: 10.0

UPD2 Укажіть свій номер дистрибуції та версії Linux.
Ви використовуєте середовище GNOME або KDE за умовчанням для X чи щось інше, яке ви самостійно налаштували?

azat: ~ $ kded4 -версія
Qt: 4.7.4
Платформа розвитку KDE: 4.6.5 (4.6.5)
KDE Daemon: $ Id $

Ви викликаєте ssh безпосередньо в командному рядку з вікна терміналу?
Який термінал ви використовуєте? xterm, gnome-terminal, або?
Як ви запустили термінал, що працює в середовищі X? З меню? Гаряча клавіша? або?

Від термінального емулятора `yakuake`
Вручну натисніть `Ctrl + N` і запишіть команди

Чи можете ви запустити xeyes з того самого вікна терміналу, де не вдалося виконати ssh -X?

`xeyes` - не встановлено
Але запущено `kate` або інший додаток kde

Ви викликаєте команду ssh як того самого користувача, з яким ви ввійшли в X сесію?
From the same user

UPD3

Я також завантажую sshджерела, і, використовуючи debug2()написати, чому він повідомляє, що версія відрізняється.
Він бачить деякі файли cookie, і один з них порожній, інший -MIT-MAGIC-COOKIE-1

Відповіді:


21

Причина переадресації ssh X не працювала в тому, що у мене є /etc/ssh/sshrcфайл конфігурації.

У кінці sshd(8)сторінки man вказано:

Якщо ~/.ssh/rcіснує, запускає його; інше, якщо /etc/ssh/sshrcіснує, виконує його; інакше працює xauth

Тому я додаю наступні команди до /etc/ssh/sshrc(також із сторінки sshd man) на стороні сервера:

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

І це працює!


Ви робите це на клієнті або на стороні сервера?
alfonx

На стороні сервера. (/ etc / ssh / sshrc виконується при підключенні клієнта)
azat

2

Кожен раз, коли у вас виникають проблеми з ssh, перше, що вам потрібно зробити, це запустити клієнт з -vможливістю надати цей вихід іншим особам для перевірки:

ssh -v user@somewhere

Я збираюся здогадатися, що проблема у вашій локальній системі. Як ви викликаєте команду ssh? Ви запускаєте його вручну в оболонці? Або він виконується як частина сценарію? В будь-якому випадку ви хочете переконатися, що у вашій місцевій системі DISPLAYправильно встановлено середовище. Його також потрібно правильно встановити на віддаленій стороні, але це значення буде відрізнятися на віддаленій стороні, ніж на локальній.

З того, що ви написали, здається, що він встановлений правильно на віддаленому хості (а за допомогою розширення X11 переадресація налаштована правильно). У віддаленій системі у вас є:

$ echo $DISPLAY
localhost:10.0

Що це за показ на місцевій стороні? Це має бути легко перевірити, чи перебуваєте ви в оболонці, як повторюючи значення, так і запускаючи додаток X із цієї оболонки ... Ви, звичайно, завжди можете використовувати поважну xeyesдля такого випробування! :)

З іншого боку, якщо ви викликаєте команду ssh із скрипту або додаєте до гарячої клавіші, вона може не успадкувати очікуване DISPLAYсередовище , тому змінна середовище на локальній стороні може взагалі не встановлюватися.

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

Що ви повинні побачити на місцевій стороні:

$ echo $DISPLAY
:0.0

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

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

...

Примітка: у графічному середовищі Gnome на робочому столі gnome-сесія є батьківським процесом усіх процесів, що працюють на робочому столі. Цей факт (поряд із принципом Успадкування) є ключовим фактором нашої здатності сильно впливати на роботу нашого робочого столу із змінними середовища. Еквівалентний процес у KDE - це kde-сесія.

ОНОВЛЕНО

Дякуємо, що опублікували вихід з 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. У багатьох системах значенням за замовчуванням DISPLAYє :0.0, ні :0. Ви якось самі встановлюєте значення DISPLAYвручну перед тим, як викликати команду ssh?

Додаткову інформацію про вашу локальну систему та те, як ви викликаєте команду ssh, було б корисно в цей момент.

  • Введіть свій номер дистрибуції та версії Linux.
  • Ви використовуєте середовище GNOME або KDE за умовчанням для X чи щось інше, яке ви самостійно налаштували?
  • Ви викликаєте ssh безпосередньо в командному рядку з вікна терміналу?
  • Який термінал ви використовуєте? xterm, gnome-terminal, або?
  • Як ви запустили термінал, що працює в середовищі X? З меню? Гаряча клавіша? або?
  • Чи можете ви запустити xeyesз того самого вікна терміналу, де ssh -Xвиходить з ладу?
  • Ви викликаєте команду ssh як того самого користувача, з яким ви ввійшли в X сесію?

Цей останній пункт важливий. Якщо ви запускаєте ssh як інший користувач (наприклад, якщо ви відкрили вікно кореневого терміналу замість вікна терміналу користувача), ви зіткнетеся з цією проблемою, навіть якщо ви явно налаштовуєте, DISPLAY=:0оскільки у вас немає дозволів на підключіться до сервера X за замовчуванням як інший користувач (навіть як root!)


Оновити орган запитання
азат

Я додав новий ОНОВЛЕНИЙ розділ з проханням отримати більше інформації, щоб допомогти налагодити цю проблему.
aculich

Я не t set вмикаю DISPLAY` вручну. Насправді я думаю, що я розумію, чому це не працює, тому що X -nolistenна локальній машині
azat

-nolistenне має нічого спільного з цією проблемою. Що стосується X, він нічого не знає про ваше віддалене з'єднання ssh. Для X це схоже на будь-яку іншу локальну програму.
aculich

1
sshdможна також запустити на передньому плані з додатковою багатослівністю, якщо проблема лежить на стороні сервера.
0xC0000022L

1

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

Крім того, якщо все інше не вдалося, спробуйте це:

Після того, як ви переходите на роботу до домашньої машини, наберіть "домашній":

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> 

Дайте нам знати.


Я вже пробував ssh -X home(пишу в дописі). Про xauth я спробую завтра.
азат

Я намагаюся xauth list & xauth add, але все ще не працює
азат

Я додав цей запис через xauth add azat/unix:10 MIT-MAGIC-COOKIE-1 ad01c582768c832ff591277b27863bc7(тому що $ DISPLAY = localhost: 10.0), якщо це може допомогти
azat

-1

Я не розумію чітко, чи потрібно відображати віддалені програми на локальному дисплеї ( work), чи ви хочете відображати їх у віддаленій системі ( home).

У першому випадку, я думаю, цього ssh -X hostмає бути достатньо, без потреби використовувати xhost.

У другому випадку система, де потрібно використовувати xhost, є home, а її недостатньо, вам також потрібно експортувати змінну дисплея.

xhost +work
export DISPLAY=:0.0

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


Я вже пробував ssh -X home(пишу в дописі). Так, я хочу відображати віддалені програми на своєму локальному дисплеї.
азат
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.