2014-09-03 10:44:44 +0000 2014-09-03 10:44:44 +0000
30
30

xauth не создает файл .Xauthority

Когда я вхожу в безголовую систему 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>

Он не создает файл.

EDIT:

Когда я подключаю монитор, затем вхожу в систему локально, файл создается, но когда я пытаюсь добавить запись (потому что мой 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 исчез. Похоже, что этот файл находится ТОЛЬКО там при локальном входе в систему. Кто-нибудь может сказать мне почему, или как я могу это исправить?

NEW DEVELOPMENT:

Я создал девственного пользователя в системе под названием “test”. Затем я вошел в систему, и без всяких других команд запустил xeyes. Что сработало! Так что это ТОЛЬКО пользователь “Marty” не может xforward. Как скопировать настройки из “test” в “marty”?

Ответы (6)

35
35
35
2015-07-16 04:15:44 +0000

Просто чтобы доложить, у меня была похожая проблема. Но в моем случае я просто следую эти шаги :

Следуйте этим шагам, чтобы создать файл $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 .

4
4
4
2018-02-20 15:30:16 +0000

Просто в дополнение к отличному ton ’s answer .

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

Поэтому я предлагаю всегда проверять свободное место (например: df -h) и проверять, что xauth generate и xauth add действительно имели какой-то эффект (xauth list).

1
1
1
2015-05-20 14:06:07 +0000

Удаление каталога .ssh из пути заставило X forwarding работать на меня.

В процессе удаления я нашел файл в ~/.ssh, который назывался “rc” и содержал:

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

Я никогда не создавал этого файла, и понятия не имею, откуда он взялся. Удаление его исправило проблему, и мои authorized_keys, known_hosts и ключевые файлы могут остаться нетронутыми.

1
1
1
2014-09-04 08:33:25 +0000

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

Ни один из этих файлов не отличался, поэтому затем я удалил каталог users .ssh. Когда я вошёл, он стонал о том, что “Сервер отказался от нашего ключа”, но я мог войти, используя пароль. Войдя в систему, я мог x идеально переслать.

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

1
1
1
2019-09-17 06:35:46 +0000

Под привилегиями root откройте /etc/ssh/sshd_config и, если они закомментированы, прокомментируйте следующие строки:

X11Forwarding yes

X11DisplayOffset 10

X11UseLocalhost yes

Затем выйдите из системы и снова войдите в нее с флагом -X в ssh. Вам не нужно устанавливать или снимать переменную окружения DISPLAY.

0
0
0
2019-01-11 14:16:32 +0000

Я наткнулся на эту же проблему на двух серверах, которые технически были сестринскими узлами. Боль в хвосте, так как я не мог понять, что изменилось. Оказалось, что каталог /home был переполнен, поэтому файлы .Xauthority не могли заполняться должным образом. Как только я обнаружил, что файл(ы) занимают слишком много места и очистил их, новые файлы .Xauthority были созданы должным образом.

Похожие вопросы

6
10
19
12
13