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


15

У мене виникає дратівлива проблема.

Коли я входжу на певний хост через SSH, повідомлення

X11 connection rejected because of wrong authentication.

трапляється три рази, здавалося б, випадково приблизно раз на хвилину. Я поняття не маю, звідки воно походить.

Насправді, навіть з невеликою проблемою з перенаправленням X11 немає, це працює як шарм. Але це повідомлення постійно з’являється, і це мене зводить з розуму.

Хтось має уявлення, як від нього позбутися?

Я стикаюся з проблемою, незалежно від того, звідки я берусь, це відбувається з мого Gnome-Desktop, а також із Windows-системи, що використовує PuTTY, MobaXterm, Cygwin, що завгодно.


Після щедрінгу ще раз я виявив причину агента моніторингу (check_mk). Це перевіряє деякі параметри виконання запущених завдань, повідомлення з’являлося кожного разу, коли цей агент був запущений із системи моніторингу, саме коли перевіряється статус PostgreSQL. Здається, цей процес намагається відкрити з'єднання X11, але не вдається. Потім повідомлення перекидається на мій термінальний сеанс, коли він намагався використовувати мій пересланий X11-сеанс.

Чи є спосіб взагалі відключити це повідомлення?

Відповіді:


21

Переконайтеся, що у вас не вистачає місця на диску

Запустіть df і переконайтеся, що у вас є достатньо місця на диску, якщо у вас мало місця на диску, видаліть із системи непотрібні файли:

$ df -h

Якщо в файлових системах встановлені квоти, перевірте, чи не перевищили ви квоти:

$ quota -s

Переконайтесь, що ~ / .Xauthority належить вам

Виконайте наступну команду, щоб знайти власність:

$ ls -l ~/.Xauthority

Запустіть chown та chmod, щоб виправити проблеми з дозволом [замініть користувача: група вашим фактичним іменем користувача та іменем групи]:

$ chown user:group ~/.Xauthority
$ chmod 0600 ~/.Xauthority

Переконайтесь, що X11 SSHD Переадресація включена

Переконайтеся, що у файлі sshd_config існує наступний рядок:

$ grep X11Forwarding /etc/ssh/sshd_config

Вибірка зразка:

X11Forwarding yes

Якщо вимкнено X11, додайте наступний рядок до sshd_cofing та перезапустіть ssh-сервер:

X11Forwarding yes

Переконайтесь, що переадресація клієнта X11 включена

Переконайтеся, що ваш локальний ssh_config має такі рядки:

Host *
ForwardX11 yes

Нарешті, увійдіть на віддалений сервер і запустіть X11 так, як випливає з вашої настільної системи Mac OS X або Linux:

ssh -X user@remote-host.com

Кредит для інформації належить тут: http://www.cyberciti.biz/faq/x11-connection-rejected-berely-of-wrong-authentication/

Сподіваюся, що це допомагає.


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

Як було сказано, це в цьому випадку не має значення. Проблема не в тому, що моя спроба переслати X11-з'єднання не вдалася. Проблема полягає в тому, що інший користувач намагається використовувати мій X11-Forwarding і те, що повідомлення перекидається на мій активний термінальний сеанс те, що я не хочу. Питання "Чи є спосіб взагалі відключити це повідомлення?".
Крістіан

Я оновив свою відповідь для користувача, який попросив її, після чого видалив його коментар. Для вашого питання спробуйте відключити доступ стіни до всіх, крім кореня (якщо припустити, що процес не запускається користувачем root): $ sudo chmod gs / usr / bin / wall $ echo foo | стіна
devnull

Я видав "mesg n", що пригнічує стінні повідомлення, але все одно продовжував отримувати такі :(
Крістіан

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

4

Це може бути ненадійний час очікування пересилання X11. Використання ForwardX11Timeoutпараметра з великим тайм-аутом може допомогти, як було запропоновано на веб-сторінці https://bugzilla.mindrot.org/show_bug.cgi?id=1718 (у мене була ця проблема раніше, але IIRC вона зникла після деякого оновлення).


На жаль , немає, і коли я явно встановлений ForwardX11Trusted yesв /etc/ssh_config.
Крістіан

2

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



0

Встановіть XQuartz на mac, якщо потрібно, та увійдіть безпосередньо з користувачем. Приклад - Під час встановлення oracledb я намагався увійти з root, а потім запустив команду від користувача oracle після sudo su - oracle.

Увійдіть безпосередньо через oracle ssh -X oracle @ ім'я хоста

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.