ssh повертає повідомлення "Помилка запиту на переадресацію X11 на каналі 1"


33

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

$ ssh user@server
X11 forwarding request failed

$ ssh user@server ls
X11 forwarding request failed on channel 1
file1
file2
...

Як я можу позбутися цих повідомлень?

Відповіді:


38

Ці повідомлення можна усунути за допомогою 1 із 3 методів, використовуючи лише параметри SSH. Ви завжди можете надсилати повідомлення /dev/nullтакож, але ці методи намагаються розібратися з повідомленням через конфігурацію, а не просто захоплювати їх і скидати.

Спосіб №1 - встановіть xauth

Сервер, до якого ви віддаляєтесь, скаржиться, що він не може створити запис у .Xauthorityфайлі користувача, оскільки xauthвін не встановлений. Таким чином, ви можете встановити його на кожному сервері, щоб позбутися цього прикрого повідомлення.

У Fedora 19 ви встановлюєте xauthтак:

$ sudo yum install xorg-x11-xauth

Якщо ви спробуєте зайти sshна сервер, ви побачите повідомлення про те, що в .Xauthorityфайлі користувача створюється запис .

$ ssh root@server
/usr/bin/xauth:  creating new authority file /root/.Xauthority
$

Подальші реєстрації більше не показуватимуть це повідомлення.

Спосіб №2 - відключіть його за допомогою ForwardX11

Ви можете доручити sshклієнту не намагатися включити переадресацію X11, включивши параметр SSH ForwardX11.

$ ssh -o ForwardX11=no root@server

Те ж саме можна зробити і з -xперемикачем:

$ ssh -x root@server

Це повідомлення лише тимчасово відключить, але це хороший варіант, якщо ви не можете або не бажаєте встановити його xauthна віддалений сервер.

Спосіб №3 - відключіть його через sshd_config

Зазвичай це за замовчуванням, але, якщо це не так, ви можете налаштувати свій sshdсервер так, щоб X11Forwarding вимкнено, в /etc/ssh/sshd_config.

X11Forwarding no

З трьох методів я зазвичай використовую №2, тому що я часто хочу X11Forwardingввімкнути більшість своїх серверів, але потім не хочу бачити X11....попередження

$ HOME / .ssh / config

Значну частину часу це повідомлення навіть не з’являється. Зазвичай вони присутні лише у наступних записах у вашому $HOME/.ssh/configфайлі вгорі.

ServerAliveInterval 15
ForwardX11 yes
ForwardAgent yes
ForwardX11Trusted yes

GatewayPorts yes

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

Безпека

Зазвичай не рекомендується постійно працювати ForwardX11 yes. Тож якщо ви хочете керувати своїми SSH-з'єднаннями в найбільш безпечній садибі, краще зробити наступне:

  1. Не включайте ForwardX11 yesу свій $HOME/.ssh/configфайл
  2. Використовуйте ForwardingX11 лише тоді, коли вам потрібно ssh -X user@server
  3. Якщо можете, відключіть X11Forwardingповністю на сервері, щоб це заборонено

Список літератури


Чи можете ви мені допомогти з unix.stackexchange.com/questions/470331/… ?
переобмін обмін

Для запису, я отримав це повідомлення , коли я був намагаюся запустити клієнт X на віддаленому сервері. Вони не запускаються, оскільки $ DISPLAY не було встановлено. Мені вдалося виправити це за допомогою вашої першої пропозиції: встановити xauth.
Том Елліс

13

У моєму випадку додавання цього рядка для /etc/ssh/sshd_configвирішення проблеми:

X11UseLocalhost no

Це працювало для мене (на сервері вже встановлено xauth). Спасибі.
Пол Хіггінс

Це, мабуть, вирішило моє питання, але я не розумію, чому це стосується. У мене є три однакові машини Debian 7, одна з яких раптово перестала приймати locahostпересилання X11. Переадресація X11 на двох інших все ще працює. Будь-яка ідея, що могло змінитися?
Кайл Странд

12

Сьогодні перебігав це і бив головою на деякий час, поки я не наткнувся на налаштування ssh:

Якщо це RHEL 7 (centOS, OEL тощо), і у нього відключений ipv6, йому потрібно:

AddressFamily inet

встановити в / etc / ssh / sshd_config.


якщо тільки повідомлення про помилку, пов’язане з цим ...
Джек Уейсі

ти знаєш, що смішного? Я сьогодні зіткнувся з цим і поглянув на нього, знайшов цю статтю і знайшов власний коментар від чотирьох років тому і сказав: "О, так це проблема".
Systempoet

2

Ще однією незначною зміною було б, якщо ви хочете перестати бачити це повідомлення (тобто перестати намагатися переслати X11) для певних серверів, але все ж зберегти за замовчуванням ForwardX11 так для всіх інших з'єднань.

У цьому випадку ви можете відключити перенаправлення X11 для конкретного хоста (або діапазону) у вашому ~ / .ssh / config. Щось на зразок цього:

host 10.1.1.*
ForwardX11 no 

Подяка: Це незначне прикрашення існуючої (і дуже повної) існуючої відповіді - оскільки я не міг прокоментувати!


2

Якщо ви запускаєте клієнта у багатослівному режимі ( ssh -v user@host), це дає вам

debug1: Remote: No xauth program; cannot forward with spoofing.

але xauthнасправді встановлено на сервері, то, мабуть, тому, що sshd шукає xauth, який виконується в неправильному місці ( / usr / X11R6 / bin / xauth зазвичай). Це можна виправити, встановивши

XAuthLocation /usr/bin/xauth

в / etc / sshd / sshd_config (або все, на чому налаштовано ваш сервер).


Це працювало для мене на CentOS 7. Це саме те повідомлення про помилку, яке я бачив.
Брайан Мінтон

Це була моя проблема, намагаючись дистанційно увійти до Mac. Там правильним закликом було XAuthLocation / opt / X11 / bin / xauth
Леон Евери

1

Налаштування X11 переадресації на основі хоста

На додаток до всіх відмінних відповідей, які вже є тут, ви можете конфігурувати ForwardX11на основі кожного хоста, тому, якщо тільки такий serverне вдасться, ви можете додати запис у свій ~/.ssh/configфайл наступної форми:

Host server server.domain.dom
    ForwardX11 no

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

Host my.server
    HostName server.domain.dom
    User user
    Port 1234
    ForwardX11 no

Це особливо корисно, якщо ви встановили імена серверів автозаповнення для SSH та SCP .


1

Я натрапив на це питання після того, як натрапив на sshd-xauthпомилку майже десятиліття. Повідомляється про два рішення: перше - в обхід xauth, у другому - про помилку.


Рішення 1 - обхід xauth

  • local - локальна машина, яка обслуговує Xserver.
  • remote - віддалена машина, що обслуговує додаток, який передає дані, що надходять до Xserver

Віддалене /etc/ssh/sshd_config:

X11Forwarding no
X11DisplayOffset 10
X11UseLocalhost yes

Віддалений ~/.Xauthorityпустий або не існує

Місцеві:

Xephyr -ac -screen 1280x800 -br -reset   :2 &
DISPLAY=:2 ssh  -fR 6010:/tmp/.X11-unix/X2  user@remote "DISPLAY=:10 xeyes"

У тесті, локальний під керуванням Ubuntu 18.05, дистанційним керував Debian Jesse.

Я також розмістив це рішення як відповідь на інше питання.


Рішення 2 - вирішити помилку sshd / xauth

Це рішення є близьким до рішення @systempoet вище , хоча одного цього було недостатньо.

На додаток до змін /etc/ssh/sshd_configна віддаленому:

AddressFamily inet

/etc/hosts на віддаленому пристрої також було змінено:

::1     localhost ip6-localhost ip6-loopback

Якщо будь-який був прокоментований, повідомлення про помилку

X11 forwarding request failed on channel 0

з'явився після ssh -X ...дзвінка. Крім того, /var/log/auth.logпоказана помилка:

sshd[...]: error: Failed to allocate internet-domain X11 display socket

Тест, щоб створити помилку (перед виправленням):

Місцева машина:

$ Xephyr -ac -screen 1280x800 -br -reset -terminate  :2 &
$ DISPLAY=:2 ssh -X  user@remote
X11 forwarding request failed on channel 0

0

Одним важливим моментом, який слід зазначити після внесення змін у конфігурацію, є те, що вам доведеться вбити sshd, щоб він підбирав зміни:

cat /var/run/sshd.pid | xargs kill -1

будучи кореневим користувачем.


-2
  1. Встановіть наступні 2 варіанти /etc/ssh/sshd_configу своєму хості RHEL

    X11Forwarding yes X11UseLocalhost no

  2. sudo /etc/init.d/sshd reload

  3. sudo yum install xauth
  4. ssh назад до хоста RHEL за допомогою перемикача -X: ssh -X yourname@rhelbox
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.