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

Question

У меня проблема с переадресацией X через SSH. Я боролся целую вечность, но никто не может помочь.

Сейчас я беру другой такт. Я хотел бы знать, как я буду отлаживать ошибки?

Какие журналы я должен посмотреть, какие дополнительные флаги я должен установить (-v и т.д.) и что я должен искать?

Дальнейшее редактирование:

Если я захожу в Putty на сервер и пытаюсь выполнить xeyes , я получаю:

Прокси PuTTY X11: попытка неверного протокола авторизации Ошибка: Не удается открыть дисплей: localhost: 10.0

Если я xauth generate $DISPLAY я получу:

Прокси PuTTY X11: попытка неверного протокола авторизации xauth: (argv): 1: невозможно открыть экран «localhost: 10.0».

Answer 1

Мое решение шаг за шагом:

1) войти с опцией -X удаленный хост, вход в систему root

$ ssh -X root@192.168.1.39

2) проверить, если есть.Xauthority file

[root@localhost ~]# ls -al
[root@localhost ~]# vim .Xauthority

3) копия.Xauthority файл в каталог другого пользователя

[root@localhost ~]# cp .Xauthority /home/oracle/
cp: overwrite `/home/oracle/.Xauthority'? y

4) установить разрешения для этого файла

[root@localhost ~]# chown oracle:oinstall .Xauthority
[root@localhost ~]# chmod 0600 .Xauthority

5) логин оракула пользователя

[root@localhost ~]# su - oracle

6) настройка отображения в localhost:10.0

[oracle@localhost ~]$ echo $DISPLAY
localhost:10.0
[oracle@localhost ~]$ ls -al

7) список существующих файлов cookie Xauth

[oracle@localhost ~]$ xauth list
localhost.localdomain/unix:11  MIT-MAGIC-COOKIE-1  310f1b02c1080e73059391c193a1881b
localhost.localdomain/unix:10  MIT-MAGIC-COOKIE-1  41843db100830a2aa352641ac47bb759

8) добавление

[oracle@localhost ~]$ xauth add localhost.localdomain/unix:10  MIT-MAGIC-COOKIE-1  41843db100830a2aa352641ac47bb75

9) тест

[oracle@localhost ~]$ xclock

Надеюсь, они служат! @wcaraza

Answer 2

Убедитесь, что на сервере SSH установлен инструмент xauth , и что ваш ~/.Xauthority файл доступен для записи. (С несуществующим тоже все в порядке, пока xauth может его создать.)

Проверьте, обновляются ли данные xauth:

server$ xauth list

Попробуйте вручную добавить фиктивные данные xauth (снова на сервере SSH) и посмотрите, есть ли у xauth какие-либо проблемы (например, невозможность создать файл блокировки или изменить сам файл Xauthority):

server$ xauth add localhost:123 MIT-MAGIC-COOKIE-1 d7e2e4a8c5aa4430bfcc2abb436940d2

Если необходимо, перезапустите под strace .

Запустите службу SSH в режиме отладки, установив LogLevel DEBUG2 в конфигурации сервера (/etc/ssh/sshd_config) или запустив sshd в режиме отладки напрямую:

server$ sshd -rddp 12234

(В этом примере 12234 - это временный порт SSH, к которому вам нужно подключиться. Подойдет любой свободный порт.)

Answer 3

Это работает, это работает. ха-ха.

В КОНЦЕ КОНЦОВ.

Узнав, что это не система, добавив тестового пользователя (который x перенаправлял "из коробки"), я подумал, что начну копировать файлы запуска .bash *, чтобы девизировать "испорченного" пользователя.

Ни один из файлов не был другим, поэтому я удалил каталог .ssh пользователей. Когда я входил в ssh, он жаловался на то, что "Сервер отказал нашему ключу", но я мог войти в систему, используя пароль. Зайдя в систему, я мог отлично переслать x.

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

Answer 4

Еще одна вещь, которая может вызвать эту проблему, - это наличие файла ~/.ssh/rc на сервере - компьютере, к которому вы подключаетесь. Удалите его (или переименуйте), чтобы решить проблему.