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.