Использование программы xauth
Программа xauth обеспечивает средства аутентификации, скрытые от пользователя. Данная утилита автоматически применяется при регистрации в системе X Window, но при желании вы можете вызывать ее вручную. Несмотря на то что программа xauth менее удобна в работе, чем xhost, она обеспечивает более высокий уровень защиты.
В процессе работы xauth использует файл .Xauthority, расположенный в рабочем каталоге пользователя. Этот файл должен находиться и на клиентской машине, и на сервере. Если данный файл отсутствует, xauth автоматически создает его. В отличие от большинства конфигурационных файлов Linux, . Xauthority не является текстовым файлом. Для изменения его содержимого используется утилита xauth. С помощью xauth можно добавлять, удалять ключи и выполнять с ними другие необходимые действия. Некоторые методы регистрации на удаленном сервере предполагают автоматическую проверку содержимого .Xauthority и добавление необходимого ключа. X-сервер принимает обращения от любого клиента, который обладает соответствующим ключом. (Поскольку . Xauthority содержится в рабочем каталоге пользователя, ключ генерируется тогда, когда данный пользователь регистрируется на компьютере или запускает Х-программу. Различным пользователям могут соответствовать различные файлы . Xauthority.) Чтобы Х-клиент мог работать с Х-сервером, необходимо скопировать ключ из пользовательского файла .Xauthorityна сервере в файл .Xauthorityна клиентской машине. При обращении к серверу клиент автоматически использует этот ключ. Процедура передачи ключа описана ниже.
1. На компьютере, на котором выполняется сервер X Window, введите команду xauth. При этом утилита xauth будет запущена от имени пользователя, который применит систему для взаимодействия с удаленным узлом. Несмотря на то что xauth формально является Х-утилитой, она выполняется в текстовом режиме.
2. Введите команду list. При ее выполнении будет выведена информация о ключах, содержащихся в файле .Xauthority. Каждый ключ начинается с имени дисплея, которое представляет собой имя узла, а за ним следует номер дисплея, напри-мерterm.threeroomco.com:0. Имена некоторых компьютеров сопровождаются символами /unix, кроме того, по команде list будут также выведены записи для localhost. Оба типа записей можно не принимать во внимание. В некоторых записях номера дисплеев будут отличаться от 0. Эти записи соответствуют второму, третьему и последующим сеансам работы с Х-сервером, которые поддерживаются одновременно с первым сеансом. Вас интересует имя основного дисплея? Вероятнее всего, оно будет состоять из имени вашего компьютера, за которым следует номер 0. После имени дисплея в строке будут отображаться также тип кодировки (например, MIT-MAGIC-COOKIE-1) и 32-байтовое шестнадцатеричное число. Несмотря на то что эти данные предназначены для передачи, их можно не учитывать.
3. Введите команду extract имя_файла имя-дисплея. Здесь имя файла может быть любым, а имя дисплея — это имя, которое вы выяснили на предыдущем шаге процедуры. Например, вы можете задать команду extract xfer-auth term. threeroomco.com: 0. В результате запись файла .Xauthorityдля дисплея будет скопирована в указанный файл. Файл используется для передачи ключа на клиентский компьютер.
4. Введите команду exit, чтобы завершить работу с программой xauth.
5. Скопируйте файл, созданный при выполнении команды extract, да клиентский компьютер (удаленный компьютер, на котором расположена программа, предназначенная для выполнения). Сделать это можно различными способами: использовать средства FTP или NFS, перенести файл на дискете и т. д.
6. Зарегистрируйтесь на компьютере, выполняющем функции Х-клиента.
7. Задайте команду xauth, чтобы запустить утилиту xauth на клиентской машине.
8. Введите команду merge имя_файла. В этой команде должно быть указано имя файла, которое вы сгенерировали посредством команды extract и скопировали на клиентский компьютер. (Возможно, вам придется указать путь к файлу.)
9. Задайте команду list. Данная команда, помимо прочих сведений, должна отобразить запись для Х-сервера, которую вы только что включили. Если такая запись отсутствует, это значит, что какие-то из предшествующих действий были выполнены неправильно.
10. Введите команду exit, чтобы завершить работу xauth и сохранить внесенные изменения. (Заметьте, что в xauth также предусмотрена команда quit, которая не сохраняет изменения. Команду quit надо использовать в том случае, если при выполнении данной процедуры были допущены ошибки.)
Если на обоих компьютерах инсталлированы средства SSH, вы можете вместо описанной выше процедуры выполнить единственную команду.
# xauth list х_сервер : 0 | sed -e ‘s/A /add /’ | ssh \ х_клиент -х xauth
В данном случае xauth вызывается в командной строке, sed используется для включения команды add в начало выходных данных, кроме того, утилита xauth запускается также на стороне Х-клиента. При вызове данной команды необходимо учитывать следующее.
— Вместох_сервер надо указать имя компьютера, за которым вы работаете, а вместо х клиент — имя компьютера, на котором должна выполняться клиент-программа.
— Между add и последующей косой чертой (/) должен быть пробел. Эта команда передается утилите xauth на клиентском компьютере, и пробел должен отделять add от имени дисплея.
— Если конфигурация SSH предполагает ввод пароля либо фразы пароля, вам придется ввести соответствующие данные.
С этого момента Х-сервер будет принимать обращения от Х-клиентов, но, чтобы эти программы могли работать совместно, вам придется установить на клиентском компьютере опцию, позволяющую взаимодействовать с Х-сервером (этот вопрос будет подробнее рассмотрен в следующем разделе). При установлении соединения клиент X Window обратится к файлу . Xauthority за ключом, соответствующим серверу.
Поскольку работа xauth основана на применении ключа, который известен только серверу и авторизованному клиенту, она обеспечивает более высокий уровень защиты, чем xhost. Кроме того, при использовании xauth доступ к серверу предоставляется только отдельным пользователям. Х-сервер становится более устойчивым к атакам, осуществляемым путем подмены IP-адреса. Недостатком данного способа является передача ключей в незакодированном виде. Если локальная сеть не обеспечивает безопасность передаваемых данных либо если клиент с сервером взаимодействуют по Internet, ключ может быть похищен и злоумышленник получит доступ к Х-серверу. Если при обмене данными в системе X Window необходимо обеспечить высокий уровень защиты, надо использовать SSH-соединение. Вопросы поддержки Х-взаимодействия посредством SSH будут подробно рассмотрены в следующем разделе.
ЗАМЕТКУ
средством XDM, GDM или KDM. Если вы запускаете Х-сервер с помощью startx, поддержка xauth в ряде систем будет отсутствовать. В некоторых случаях вам придется отредактировать сценарий startx (он обычно располагается в каталоге /usr/XHR6/bin) так, чтобы в нем присутствовала опция -auth файл_авторизации; в качестве файла авторизации обычно указывается файл .Xauthority, находящийся в рабочем каталоге. Часто в редактировании startx нет необходимости.
Форум русскоязычного сообщества Ubuntu
Увидели сообщение с непонятной ссылкой, спам, непристойность или оскорбление?
Воспользуйтесь ссылкой «Сообщить модератору» рядом с сообщением!
- Форум русскоязычного сообщества Ubuntu »
- Архив »
- Архив »
- Архив тем до 2018г »
- Удалив файл .Xauthority и перезагрузившись, он создался заного но пустой.
Страницы: [1] Вниз
Автор Тема: Удалив файл .Xauthority и перезагрузившись, он создался заного но пустой. (Прочитано 8223 раз)
0 Пользователей и 1 Гость просматривают эту тему.
Страницы: [1] Вверх
- Форум русскоязычного сообщества Ubuntu »
- Архив »
- Архив »
- Архив тем до 2018г »
- Удалив файл .Xauthority и перезагрузившись, он создался заного но пустой.
Страница сгенерирована за 0.108 секунд. Запросов: 23.
- Сайт
- Об Ubuntu
- Скачать Ubuntu
- Семейство Ubuntu
- Новости
- Форум
- Помощь
- Правила
- Документация
- Пользовательская документация
- Официальная документация
- Семейство Ubuntu
- Материалы для загрузки
- Совместимость с оборудованием
- RSS лента
- Сообщество
- Наши проекты
- Местные сообщества
- Перевод Ubuntu
- Тестирование
- RSS лента
© 2012 Ubuntu-ru — Русскоязычное сообщество Ubuntu Linux.
© 2012 Canonical Ltd. Ubuntu и Canonical являются зарегистрированными торговыми знаками Canonical Ltd.
Xauthority что это
Сервер не принимает соединения просто так, откуда угодно. Да вам и не нужно, чтобы кто-нибудь выводил окна на экране. Или читал, что вы набираете (помните! клавиатура это часть дисплея).
Слишком мало людей, кажется, понимают, что подобный доступ к вашему дисплею снижает степень безопасности. Кто-нибудь, кто имеет доступ к вашему дисплею, может, что угодно посмотреть и написать на ваш экран , считывать нажатия клавиш и действий мыши.
Большинство серверов знают два пути аутентификации: механизм, основанный на списке машин (xhost), и механизм, основанный на magic cookie (xauth). Кроме того, есть ssh, оболочка с шифрованием, которая может обслуживать X-соединения.
Xhost
Xhost открывает доступ, основанный на названиях машин. Сервер поддерживает список машин, которым позволено подключаться к нему. Он же может отключить проверку имен полностью. Осторожно: это значит, что не будет выполняться никаких проверок, так что может подключиться любая машина!
Вы можете изменять список машин при помощи программы xhost. Чтобы использовать этот механизм для предыдущего примера, сделайте:
light$ xhost +dark.matt.er
Это открывает доступ ко всем соединениям с машины dark.matt.er . Как только ваш X-клиент подключится к X-серверу (появятся окна), закройте доступ при помощи:
light$ xhost -dark.matt.er
Вы можете отключить проверку вообще:
Это отключает проверку и позволяет подключиться кому угодно . Вы никогда не должны этого делать в сети, в которой вы доверяете не всем пользователям (напр. Internet). Вы можете снова включить проверку:
«xhost -» не удаляет все машины из списка доступа (это было бы бесполезно — вы не смогли бы подсоединиться ниоткуда, даже со своей же машины).
Xhost — очень небезопасный механизм. Он не различает пользователей на удаленной машине между собой. Кроме того, имена машин (а тем более адреса) можно подделать. А это плохо, если вы находитесь в сети, которой не доверяете (например, уже при PPP доступе к Internet).
Xauth
Xauth открывает доступ всем, кто знает «секрет». Этот секрет называется «авторизационная запись» или «magic cookie» (волшебная печенька). Эта схема авторизации формально названа MIT-MAGIC-COOKIE-1.
Эти записи для разных дисплеев хранятся вместе в файле ˜/.Xauthority . Ваш ˜/.Xauthority должен быть недоступен для других пользователей. Программа xauth управляет этими записями, т.е. xauth — псевдонимная система аутентификации.
В начале сеанса сервер считывает запись из файла, указанного в аргументе -auth . После этого сервер позволяет соединения только тем клиентам, которые имеют ту же запись. Если запись в ˜/.Xauthority меняется, сервер не считает изменение .
Новые сервера могут генерировать такие записи на лету для клиентов, которые запрашивают их. Хотя записи содержатся внутри сервера, они не запишутся в ˜/.Xauthority , если только клиент это не сделает сам. Согласно David Wiggins:
«Одна штучка была добавлена в X11R6.3, которой вы можете заинтересоваться. Через новую систему безопасности, сам X-сервер может сгенерировать и передать новые авторизационные записи на лету. Кроме того, запись может быть определена как «ненадежная», ограничивая функционирование приложений. Например, они не могут узнать содержимое окна или ввод с клавиатуры/мыши от других «надежных» клиентов. В xauth введена новая подкоманда «generate», чтобы сделать это средство, по крайней мере, возможным (если не легким) в использовании.»
Xauth имеет большое преимущество в безопасности перед xhost. Вы можете ограничить доступ специфических пользователей на специфических компьютерах. В отличии от xhost, его невозможно обмануть, подделав адрес компьютера. И если хотите, вы можете по прежнему пользоваться xhost.
Создание авторизационной записи
Если вы хотите использовать xauth, запустите X-сервер с аргументом -auth authfile . Если вы пользуетесь скриптом startx, лучше это сделать в нем. Создайте авторизационную запись, как показано ниже в вашем скрипте startx.
Отрывок из /usr/X11R6/bin/startx :
mcookie|sed -e ‘s/^/add :0 . /’|xauth -q xinit — -auth «$HOME/.Xauthority»
Mcookie — это простая программа в пакете util-linux ( ftp://ftp.math.uio.no/pub/linux/ ). Кроме того, вы можете использовать md5sum для преобразования случайных данных (например, из /dev/urandom или ps -axl ) в формат авторизационной записи:
dd if=/dev/urandom count=1|md5sum|sed -e ‘s/^/add :0 . /’|xauth -q xinit — -auth «$HOME/.Xauthority»
Если вы не можете отредактировать скрипт startx (если вы не root), скажите своему системному администратору, чтобы он настроил startx правильно, или пусть установит xdm. Если он не хочет или не может, вы можете создать скрипт ˜/.xserverrc . Если он у вас есть, он запускается через xinit, а не через X-сервер. Затем вы можете запустить X-сервер из этого скрипта с правильными аргументами:
#!/bin/sh mcookie|sed -e ‘s/^/add :0 . /’|xauth -q exec /usr/X11R6/bin/X «$@» -auth «$HOME/.Xauthority»
Если для управления сеансами вы используете xdm, то можно легко использовать xauth. Определите ресурс DisplayManager.authDir в /etc/X11/xdm/xdm-config . Во время запуска X-сервера xdm сам укажет аргумент -auth , а когда вы войдете в систему, xdm положит авторизационную запись в ваш ˜/.Xauthority . Для дополнительной информации читайте xdm(1). Например, мой /etc/X11/xdm/xdm-config содержит следующую строчку:
Передача авторизационных записей
Теперь, когда вы запустили X-сервер на машине light.uni.verse и у вас есть файл ˜/.Xauthority , нужно передать авторизационную запись на машину клиента dark.matt.er .
Самое простое, если у вас один и тот же сетевой домашний каталог на машинах light и dark. Файл ˜/.Xauthority один и тот же и авторизационная запись передается моментально. Тем не менее, здесь есть одна проблема: когда вы кладете авторизационную запись для :0 в ˜/.Xauthority , машина dark думает, что эта запись для нее, а не для light. Поэтому вам нужно явно указывать имя компьютера во время создания записи. Можно установить одинаковую запись для :0 и light:0 при помощи:
#!/bin/sh cookie=`mcookie` xauth add :0 . $cookie xauth add «$HOST:0» . $cookie exec /usr/X11R6/bin/X «$@» -auth «$HOME/.Xauthority»
Если домашний каталог не разделяется между машинами, вы можете передать авторизационную запись при помощи rsh:
light$ xauth nlist «$:0» | rsh dark.matt.er xauth nmerge —
Извлечь запись из ˜/.Xauthority ( xauth nlist :0 ).
Передать на dark.matt.er ( | rsh dark.matt.er ).
Поместить ее в ˜/.Xauthority there ( xauth nmerge — ).
Замечу насчет $ . Вам нужно передать авторизационную запись, явно ассоциированную с локальной машиной. Удаленное приложение может интерпретировать :0 как ссылку на удаленную машину, а это не то, что вы хотите!
Возможно, что rsh не разрешен для вас. Кроме того, rsh имеет недостаток с точки зрения безопасности (можно подделать имя машины, если я правильно помню). Если вы не можете или не хотите использовать rsh, передайте авторизационную запись вручную. Примерно так:
light$ echo $DISPLAY :0 light$ xauth list $DISPLAY light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926 light$ rlogin dark.matt.er Password: dark% setenv DISPLAY light.uni.verse:0 dark% xauth add $DISPLAY . 076aaecfd370fd2af6bb9f5550b26926 dark% xfig & [15332] dark% logout light$
Для дополнительной информации см. rsh(1) и xauth(1x).
Есть возможность передать авторизационную запись в переменных окружения TERM или DISPLAY . Это делается таким же образом, как и передача переменной DISPLAY . См. раздел «Говорим клиенту:». Это моя точка зрения, но я заинтересован в том, чтобы кто-нибудь подтвердил или опроверг ее.
Использование авторизационной записи
X-приложение на машине dark.matt.er, такое как xfig, автоматически заглядывает в файл ˜/.Xauthority и ищет нужную запись для авторизации.
Есть небольшая проблема во время использования localhost:D . X-клиент во время поиска записи может перевести localhost:D как host/unix:D . На самом деле это означает, что авторизационная запись для localhost:D в ˜/.Xauthority не имеет эффекта.
Ssh
Авторизационные записи передаются по сети без шифрования. Если вы боитесь, что кто-нибудь будет подглядывать за вашим соединением, используете ssh, безопасную оболочку. Она обеспечит зашифрованное соединение сервера и клиента. И кроме того, она полезна и для других случаев. Это хорошее структурное улучшение вашей системы. Просто сходите на http://www.cs.hut.fi/ssh/
Кто знает еще какие-нибудь методы аутентификации или шифрования X-соединений? Может быть kerberos?
| Пред. | Начало | След. |
| Говорим клиенту: | Запуск приложения от другого пользователя |
What is the .Xauthority file?
What is this .Xauthority file in the first place? Why does changing the ownership of the file fix my problem of being unable to log in?
69.6k 56 56 gold badges 217 217 silver badges 328 328 bronze badges
asked May 27, 2013 at 14:50
1,013 2 2 gold badges 10 10 silver badges 15 15 bronze badges
sudo -H nautilus does not work with 17.10. Wish there was a real answer how to create .Xauthority when none exists.
Feb 9, 2018 at 5:16
Feb 9, 2018 at 5:46
1 Answer 1
The .Xauthority (not .xAuthority ) file can be found in each user home directory and is used to store credentials in cookies used by xauth for authentication of X sessions. Once an X session is started, the cookie is used to authenticate connections to that specific display. You can find more info on X authentication and X authority in the xauth man pages (type man xauth in a terminal).
So, if you are not the owner of this file you can’t login since you can’t store your credentials there.
This situation usually arises when you execute a GUI application (for instance nautilus) with root permissions by typing sudo nautilus . You can avoid it (for 12.10 and older versions) by invoking the app with gksudo nautilus , or in any version using sudo -H nautilus .