xauth не створює .Xauthority файл


28

Коли я впадаю в безголову систему Linux Mint 17, вона не створює оновлення / створення .Xauthority файла.

Більше того, коли я бігаю, xauthя отримую відповідь:

marty@N40L ~ $ xauth
xauth:  file /home/marty/.Xauthority does not exist
Using authority file /home/marty/.Xauthority
xauth>exit
marty@N40L ~ $ xauth
xauth:  file /home/marty/.Xauthority does not exist
Using authority file /home/marty/.Xauthority
xauth>

Він не створює файл.

Редагувати:

Коли я підключаю монітор, а потім входжу локально, файл створюється, але коли я намагаюся додати запис (оскільки мій SSH не робить це для мене):

marty@N40L ~ $ xauth list
N40L/unix:0  MIT-MAGIC-COOKIE-1  34eee3b15cdb281021502d40dfba1cf2
localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  34eee3b15cdb281021502d40dfba1cf2
marty@N40L ~ $ ls -d .X*
-rw------- 1 marty marty 115 Sep  3 12:03 .Xauthority
marty@N40L ~ $ xauth generate $DISPLAY .
PuTTY X11 proxy: wrong authorisation protocol attemptedxauth: (argv):1:  unable to open display "localhost:10.0".

До речі, роблячи netstat --listenшоу, слухаючи порт:

tcp 0 0 localhost:6010 *:* LISTEN

AGH, більше інформації. Я вийшов із сеансу X на сервері, і тепер файл .Xauthority зник. Здається, що файл є ТІЛЬКИ там, коли входить локально. Хтось може мені сказати, чому, або як я можу це виправити?

НОВИЙ РОЗВИТОК:

Я створив користувача virgin в системі під назвою "test". Потім я ввійшов у систему, і без БУДЬ-яких інших команд запустив xeyes. Який працював! Так що ТОЛЬКО користувач "marty" не може xforward. Як скопіювати налаштування з тесту на марти?


Ви сказали це створити файл? ssh -Xдозволяє переадресувати X11.
— user1686

Так, я використовую Putty в Windows, налаштування для переадресації (працює при підключенні до іншого сервера Mint). Але файл не створений, тому я думав, що додаю його вручну, xauth також не створює його вручну.
— wkdmarty

Місцевий Xwindows створює файл .Xauthority, але сеанс Putty SSH не робить. Незважаючи на те, що він показує, що він слухає з'єднання.
— wkdmarty

Відповіді:


34

Тільки щоб повідомити, у мене була подібна проблема. Але в моєму випадку я просто виконую ці кроки :

Виконайте ці дії, щоб створити $HOME/.Xauthorityфайл.

Увійдіть як користувач та підтвердьте, що ви перебуваєте у домашній довідці користувача.

# Rename the existing .Xauthority file by running the following command
mv .Xauthority old.Xauthority 

# xauth with complain unless ~/.Xauthority exists
touch ~/.Xauthority

# only this one key is needed for X11 over SSH 
xauth generate :0 . trusted 

# generate our own key, xauth requires 128 bit hex encoding
xauth add ${HOST}:0 . $(xxd -l 16 -p /dev/urandom)

# To view a listing of the .Xauthority file, enter the following 
xauth list 

Після цього проблем із .Xauthorityфайлом більше не виникає .

Дякуємо та заслуговуємо на srinivasan .


1
в моєму випадку у мене була змінна середовище XAUTHORITY, яка вказує на інше місце (необережна помилка), використовуючи цю [ prefetch.net/blog/index.php/2011/11/01/… нитку, яку я зміг виявити і вирішити помилка. Використовуючи strace xauth, він вказав на невірний шлях, вказаний у змінній. Слід також додати, що я отримував помилки щодо блокування, серед інших
— Cybex

1
У моєму випадку мені потрібно було зробити лише крок 1 - 3. Крок 4 і 5 фактично змусили його не працювати.
— Річард Айотта

Я повинен робити xauth generate :0 . trustedпісля кожної команди, як userвідкрити дисплей як root. Чи можу я виправити це?
— Тимо

xhost +допомогли відкрити x-програми як root.
— Тимо

7
крок 3 дає мені помилку:xauth: (argv):1: unable to open display ":0".
— simpleuser

4

Просто на додаток до відмінної тонний «s відповідь .

У мене колись була точно така ж проблема, тому що мій домашній каталог став на 100% заповнений. Після підключення sshстворив порожній ~/.Xauthorityі не зміг написати жодного запису до нього (так що xauth listвін завжди давав порожній вихід).

Тому я пропоную завжди перевіряє наявність вільного місця (наприклад: df -h) і перевіряє , що xauth generateі xauth addсправді мали ніякого ефекту ( xauth list).


1

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

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

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


1

Переміщення .ssh каталогу з шляху змусило X переадресацію працювати для мене.

В процесі усунення я знайшов файл у ~ / .ssh, який називався "rc", і містив:

echo "Wecome to $(hostname), $(whoami)"

Я ніколи цього не створював і поняття не маю, звідки це взялося. Видалення його виправили проблему, і мої authorized_keys, known_hostsі ключові файли можуть все перебування недоторканою.


1

Під правами root відкрийте /etc/ssh/sshd_configта коментуйте такі рядки, якщо їх коментують:

X11Переміщення так

X11DisplayOffset 10

X11UseLocalhost так

Потім вийдіть із системи та знову увійдіть із -Xпрапором ssh. Вам не доведеться встановлювати чи скасовувати DISPLAYзмінну середовища.


0

Я натрапив на цю саму проблему на двох серверах, які технічно були сестринськими вузлами. Біль у моєму хвості, так як я не міг зрозуміти, що відрізняється. Виявляється, / home каталог було повним, тому файли .Xauthority не могли заповнитись належним чином. Як тільки я знайшов файли, що займають занадто багато місця, і очистив їх, нові файли .Xauthority були створені належним чином.

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