Соединение X11 отклонено из-за неправильной аутентификации

#x11 #x11-forwarding

#x11 #x11-переадресация

Вопрос:

Я получаю сообщение об ошибке при доступе к firefox с использованием X11Forwarding.

 [root@station2 ~]# firefox
KiTTY X11 proxy: wrong authorisation protocol attemptedKiTTY X11 proxy: wrong authorisation protocol attemptedError: cannot open display: localhost:10.0
  

установите следующие значения: /etc/ssh/sshd_config

 X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
  

** Установлен пакет**

 #yum install xorg-x11-xauth
#yum -y install xauth

[root@station2 .ssh]# echo $DISPLAY
localhost:10.0

#mkxauth -c
adding key for station2.example.com to /root/.Xauthority ... done
  

Комментарии:

1. Ответ от Майкла правильный. Это лучший учебник, который я нашел: blog.linuxjunkie.com/blog/2012/09/26 /…

2. Обратите внимание, что переполнение стека предназначено только для вопросов о написании программного обеспечения; вопросы об использовании вашей системы UNIX относятся к Unix amp; Linux .

3. Откуда поступает команда «mkxauth»? Вы имели в виду «xauth»? «mkxauth» недоступен ни в моей fedora, ни в ubuntu, тогда как xauth работает на обоих (хотя опция «-c» отсутствует)

Ответ №1:

 export XAUTHORITY=$HOME/.Xauthority
  

Это исправление сработало для меня

Комментарии:

1. Я не смог включить перенаправление X на свой Raspberry Pi 4 под управлением Ubuntu 20.04, и это исправило это.

2. спасибо, это работает для моего случая. (Включение ssh X в RHEL 8 на AWS EC2)

3. Не могли бы вы объяснить, как это решает проблему?

4. Это сработало для меня. Было бы неплохо узнать, почему. По какой-то причине для XAUTHORITY было установлено значение /tmp/kde-<имя пользователя>/xauth-<числа>.

5. Перенаправление X11, как в 1990 году

Ответ №2:

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

Предварительное примечание: тема этого ответа не обсуждается, является ли безопасность risc или вообще рекомендуется использовать графический рабочий стол в качестве root на удаленном веб-сервере без отображения.

Сценарий:

  • Удаленный подключенный к Интернету Linux-сервер S присвоил доменное имя example.com на его общедоступный IP4-адрес 192.0.2.1.
  • Файл /etc/hostname на S содержит одну строку example .
  • Файл /etc/hosts на S содержит строку 127.0.0.1 localhost example.com example .
  • (Удаленный) ssh-доступ к S по (sshd-) конфигурации (на S) запрещен для root строкой DenyUsers root в /etc/ssh/sshd_config, но разрешен для фиктивного пользователя user1 . С клиентского компьютера C устанавливается ssh-соединение, использующее параметр ssh -X или -Y , для S в качестве пользователя user1 .

Затем, в удаленном терминале на S, принадлежащем user1, если какая-либо команда, связанная с X11, пытается быть выполнена как root, может ли это быть с помощью

su , затем пытается запустить среду рабочего стола X11

или, как в конкретном случае, выполнение скрипта, содержащего

 #!/bin/bash
su --preserve-environment -c "xfce4-session amp;" root
  

сообщение об ошибке

Соединение X11 отклонено из-за неправильной аутентификации.

выводится, и запуск любой связанной с X11 программы завершается ошибкой. Отображаемая переменная среды root содержит

пример.com: 10.0

затем.

Одним из решений проблемы в этом особом случае является изменение строки

 127.0.0.1 localhost example.com example
  

в /etc/hosts для

 127.0.0.1 localhost
  

Комментарии:

1. Чувак, твой ответ спас меня! Проблема заключалась в моем файле хоста, и теперь она исправлена! Не могли бы вы упомянуть об этом в верхней части своего ответа, чтобы другие могли найти решение?

2. @Ho1: Как я сам испытал при поиске в Интернете «моей» причины этого сообщения об ошибке, не очень полезно просто читать заголовки. Поскольку многие параметры могут вступить в силу, всегда требуется тщательное чтение. Я не считаю, что отказываться от помощи, но сначала необходимо детально изучить случай, чтобы можно было решить для себя, попробовать ли то, что было решением для других.

3. Вы спасаете жизнь, просто переходя к решению там, эта строка волшебна!

Ответ №3:

Решение: запустите приложение с тем же пользователем, с которым вы связываетесь.

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

Источником моей проблемы было то, что я использовал SSH с моим собственным именем пользователя (которое не было root).

Затем, после входа в систему, я устал работать с X11, выполняя «su» или «sudo», проблема в том, что сеанс SSH настроен с вашим собственным именем пользователя — например: Raj, но затем вы переключаетесь на пользователя root, который не является частью сеанса X11.

Итак, что вам нужно сделать, это просто попытаться запустить приложение (firefox в вашем случае) с тем же пользователем, с которым вы запустили сеанс X11.

Надеюсь, это поможет.

Talel.

Ответ №4:

Я столкнулся с этим gvim ssh -t -Y , и решение, которое сработало для меня, было:

 xauth add $(xauth -f ~<logon_user>/.Xauthority list | tail -1) ; export NO_AT_BRIDGE=1 # gvim X11 fix for remote GUI failure after su
  

Я не знаю, где я наткнулся на этот ответ, поэтому я не могу отдать должное автору.