Як налагодити "З’єднання X11 відхилено через неправильну аутентифікацію"

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

Зараз я беру інший такт. Мені хотілося б знати, як я б налагоджував помилки?

Які журнали слід шукати, які додаткові прапори потрібно встановити (-v тощо) і що слід шукати?

Далі редагувати:

Якщо я ввійду в Putty на сервер і спробую xeyes, я отримаю:

Проксі PuTTY X11: спроба протоколу авторизації спробаПомилка: Не вдається відкрити дисплей: localhost: 10.0

Якщо xauth generate $DISPLAYя отримаю:

Проксі PuTTY X11: спроба невідомого протоколу авторизації спробаxauth: (argv): 1: не вдається відкрити екран "localhost: 10.0"

Моє рішення крок за кроком:

1) вхід з опцією -X віддалений корінь входу хоста

$ 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 '? у

4) встановити дозволи для цього файлу

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

5) увійти користувач Oracle

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

6) налаштування дисплея в localhost: 10.0

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

7) перелічує файли cookie xauth

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

8) додавання

[oracle @ localhost ~] $ xauth додати localhost.localdomain / unix: 10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb75

9) тест

[oracle @ localhost ~] $ xclock

Сподіваюся, вони служать! @wcaraza

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

Це працює, працює. ха-ха.

ОКОНЧНО.

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

Жоден з файлів не відрізнявся, тому наступне я видалив .ssh каталог користувачів. Коли я входив, я застогнав над "Сервер відмовився від нашого ключа", але я міг увійти, використовуючи пароль. Після входу в систему я міг x передати ідеально.

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

Ще одна річ, яка може викликати цю проблему, - це існування ~/.ssh/rcфайлу на сервері - машині, до якої ви підключаєтесь. Видаліть його (або перейменуйте), щоб вирішити проблему.

rm ~/.Xauth* а потім знову підключитися.

Це працює для мене. Для отримання більш докладної інформації