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


10

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

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

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

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

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

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

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

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


В своем вопросе от другого дня вы описываете различные симптомы. Вы все еще страдаете от «Не могу открыть дисплей», или вы решили это? Если вы решили это, и один из ответов на этот вопрос был полезен, вы должны выбрать его в качестве ответа, чтобы вознаградить человека, который помог вам.
Кенстер

Согласен, теперь это другая ошибка, я закрыл этот вопрос.
wkdmarty

Посмотрите, относится ли этот ответ к вашему серверу.
Кенстер

Кенстер, у меня не было ни одного файла rc на сервере, поэтому я создал его и вставил код. Нет разницы.
wkdmarty

В журналах PuTTY это появляется после того, как я пытаюсь запустить программу x (после входа в SSH). 2014-09-01 15:16:38 Получен запрос на подключение X11 от 127.0.0.1:59566 2014-09-01 15:16:38 Успешное открытие прямого подключения X11 2014-09-01 15:16:38 Не осталось ничего для отправки, закрытие канала 2014-09-01 15:16:38 Переадресация перенаправленного соединения X11
wkdmarty

Ответы:


13

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

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

$ ssh -X root@192.168.1.39

2) проверьте, существует ли файл .Xauthority

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

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

[root @ localhost ~] # cp .Xauthority / home / oracle /
cp: перезаписать `/home/oracle/.Xauthority '? Y

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

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

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

[root @ localhost ~] # su - оракул

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

[oracle @ localhost ~] $ echo $ DISPLAY
локальный: 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


2
Часть Xauth добавить .... это трюк
Вэй

шаги 3. и 4. сделали
свое дело

6

Убедитесь, что на сервере 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, к которому вам нужно подключиться. Подойдет любой свободный порт.)


Спасибо. Xauth на сервере может записывать в файл .Xauthority. Но что это должно быть установка? сервер = N40L, клиент = Lin001. Должен ли список xauth на N40L показывать запись для localhost: 10 MIT-MAGIC-COOKIE-1 {Lin001'sHexKey}?
wkdmarty

@wkdmarty: Да, ваш sshd будет прослушивать порт TCP, соответствующий отображению: 10 (или: 11,: 12 ...), и это будет отображаться как «localhost: 10». Что касается шестнадцатеричного ключа, однако, я действительно не знаю, должен ли он использовать тот же ключ - я думаю, что ssh на самом деле генерирует новый и действует как прокси ...
user1686

хорошо, отлично, я вижу, что 0.0.0.0:6011 слушает. Моя переменная DISPLAY имеет состояние N40L: 11.0, что я считаю неправильным, поэтому я изменю это на DISPLAY = localhost: 10.0. Нет, все еще ошибаюсь. В SSH-соединении я заметил эту строку: debug2: x11_get_proto / usr / bin / xauth list: 0.0 2> / dev / null везде, где я видел протоколирование SSH-соединений, эта строка отличается ... показывает генерацию ключа, никогда : 0.0.?
wkdmarty

@wkdmarty: Обычно sshd должен установить правильное значение $ DISPLAY ... и порт 6011 соответствует отображению 11, а не 10, в любом случае.
user1686

1
Msgstr "Моя переменная DISPLAY утверждает N40L: 11.0 ... так что я это изменю". Чтобы быть тупым, оставьте DISPLAY в покое. Если ssh устанавливает пересылку X11, он установит для DISPLAY значение, которое будет работать. Переопределение значения, которое устанавливает ssh, только усложнит процесс устранения неполадок.
Кенстер

3

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

НАКОНЕЦ-ТО.

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

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

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


Это сработало и для меня. Я пробовал все другие методы, но да, видимо, проблема заключалась в ключах.
Вспомогательный

1

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


1
Per man sshd, sshd запускается ~/.ssh/rcвместо xauth@PimpJuiceIT.
Кен Джексон

Спасибо! Для получения дополнительной информации см .: docstore.mik.ua/orelly/networking_2ndEd/ssh/… . Должна быть возможность добавить соответствующие команды для запуска xauth в файле rc, но я не нашел его.
Мэтт Б.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.