Как создать файл xauthority

Обновлено: 06.07.2024

Поскольку X Window взаимодействуют с вашей клавиатурой, мышью и экраном, оставлять X Window незащищенным слишком опасно. Это не только даст возможность кому бы то ни было выводить окна на ваш дисплей, но и кто угодно сможет запустить "невидимое" приложение, которое сможет перехватывать информацию от клавиатуры или от мыши. Вы можете использовать два встроенных метода для блокирования X-сервера - xhost и xauth .

Xhost

Xhost позволяет осуществлять контроль за доступом к вашему X-серверу на основе имени хоста/IP-адреса. Чтобы разрешить машине HOST2 использовать HOST1 в качестве дисплея, вам необходимо убедится, что X-сервер машины HOST1 запущен с помощью следующей команды (например, с использованием окна X-терминала):

Если вы хотите явным образом запретить доступ для HOST2 , то попытайтесь сделать это так:

По умолчанию доступ запрещен для всех. Вы можете использовать xhost , чтобы добавить определенные хосты в специальный список доверенных хостов. Вы можете также разрешить доступ на глобальном уровне (отменив контроль доступа) просто запустив команду xhost + . Это делать не рекомендуется, поскольку некто, имеющий доступ к вашей машине по сети, будет иметь возможность запускать приложения на вашем X-сервере. Команда xhost - позволяет вновь включить контроль доступа к использованию X-сервера, разрешая доступ только для хостов, внесенных в список доверенных. Чтобы просмотреть список машин, которым в настоящее время разрешено использовать ваш X-сервер, запустите команду xhost без параметров.

Примечание. Команда xhost запрещает доступ только "на будущее"; эта команда не прерывает текущие соединения.

Тем не менее, Xhost - не слишком эффективный метод обеспечения контроля доступа, поскольку он не требует аутентификации на основе ввода имени пользователя и пароля, а также не использует шифрования. По той же самой причине базовый контроль доступа, основанный на контроле IP-адреса на брандмауэре - не слишком хорошее решение для Виртуальной частной сети (VPN - Virtual Private Network ); вы полагаетесь исключительно на IP-адрес для определения идентичности. Как мы уже видели и увидим в последующих лекциях, имя хоста или IP-адрес могут быть подделаны. Для пользователей, хорошо знакомых с TCP-оболочкой и запуском удаленных служб ( rsh , rlogin и т.д.), это похоже на веру в то, что файлы hosts.allow , hosts.deny и hosts.equiv защитят ваши X-сессии.

Совет. Использование xhost + может переопределить все средства обеспечения безопасности, обсуждающиеся в нескольких следующих разделах. Вам следует всячески избегать запуска этих команд без определения имени хоста.

Xauth

Xauth в действительности является не программой контроля доступа, а скорее, графическим интерфейсом пользователя для доступа к файлу Xauthority , который может использоваться X-сервером для обеспечения безопасности. Xauth позволяет добавлять, удалять, просматривать и объединять списки авторизации для доступа к X-серверу. Элементы списка авторизации для доступа к X-серверу содержат имя хоста X-сервера и номер дисплея, протокол авторизации и секретные данные. X-сервер должен при запуске сгенерировать список авторизации на основе своего файла Xauthority (это делает программа xdm ), а клиенты, желающие получить доступ к этому серверу, должны иметь строку авторизации в своем локальном файле Xauthority . X Window-авторизация поддерживает несколько различных протоколов. В этой книге рассматривается только два из них.

Концепция довольно проста. После запуска X-сервера необходимо сгенерировать запись в файле Xauthority в зависимости от того, какой протокол вы используете. Если вы используете xdm , запись будет сгенерирована автоматически. Многие системы могут автоматически генерировать запись, когда вы вручную запускаете X-сервер. Поговорим о том, как можно сгенерировать Xauthority -запись вручную, чтобы вы представляли себе команды, которые при этом выполняются. Например, будем использовать протокол MIT-MAGIC-COOKIE-1.

На машине, где запущен X-сервер, запустите xterm . Наберите следующие команды.

Совет. Точка в конце команды generate находится в том месте, где следовало бы определить протокол аутентификации, который вы бы хотели использовать для xauth . Если использовать только точку, то будет использоваться протокол MIT-MAGIC-COOKIE-1 . Создание записи для другого протокола обычно требует дополнительной информации, которую необходимо добавить в конце командной строки. Обычно это делается не вручную, а с использованием внешней программы или скрипта.

Теперь у вас есть запись для авторизации (которая не должна быть доступна для чтения кому-либо еще в системе) для вашего X-сервера. Теперь попробуем запустить графическое приложение с удаленной машины на вашем X-сервере. Вам понадобится сообщить удаленной машине о ключе доступа. Вы можете сделать это, добавив в файл

/.Xauthority запись и скопировав туда информацию.

Или вы можете слегка автоматизировать этот процесс.

Команда xauth извлечет ключ для хоста, названного в переменной $DISPLAY и пошлет его на стандартный вывод. Мы перенаправим этот вывод на remotebox с использованием ssh и добавим эту информацию к команде xauth . Это эффективный способ передачи ключа для авторизации с сервера в Xauthority -файл на удаленной машине. Вы можете подтвердить это, запросив список авторизационных записей на удаленной машине. Удаленная машина теперь может свободно использовать X-сервер с машины myxserver , поскольку ей известен ключ для авторизации. Только хосты, которым известен ключ авторизации, могут использовать X-сервер.

Совет. Предыдущая команда предполагает, что в переменной DISPLAY содержится IP-адрес или имя хоста. Имейте в виду, что переменная DISPLAY может ссылаться на другое, нежели интернет, семейство адресов. Если переменная DISPLAY установлена в :0 и вы запускаете команду, то можете обнаружить, что записи в файле Xauthority удаленной машины ссылаются на myxserver по только ей известному имени (имени нет в базе DNS), или, что еще хуже, по адресу, принадлежащему другому семейству адресов (например, по адресам сокетов локального домена вместо адресов TCP/IP). Поэтому наилучшим можно признать однозначное задание IP-адреса в переменной DISPLAY (например, в виде 192.168.1.50:0).

Передача записей из файла Xauthority от сервера клиенту одинакова независимо от типа используемого протокола авторизации. Некоторые из более продвинутых протоколов включают процедуру SUN-DES-1 , которая использует систему Secure RPC от фирмы Sun, и MIT-KERBEROS-5, которая использует аутентификацию пользователей по протоколу Kerberos. Эти методы авторизации более безопасны, но они также и более сложны для первоначальной настройки. За подробной информацией обращайтесь к man-страницам по процедурам xauth , xdm , и по файлу Xsecurity .

В этот документе описываются способы запуска удаленных приложений под X. То есть представлена информация о том, как заставить программу выводить результат на дисплей другого компьютера, а не того, на котором она запущена. Или наоборот: как заставить программу работать на другом компьютере так, как будто вы сидите за ним. И как запустить приложение от другого пользователя на этом же компьютере. Основное внимание здесь уделяется безопасности.

Содержание 1. Введение 2. Аналогичные решения 3. Постановка задачи 4. Немного теории 5. Говорим клиенту: 6. Говорим серверу: 6.1. Xhost 6.2. Xauth 6.2.1. Создание авторизационной записи 6.2.2. Передача авторизационных записей 6.2.3. Использование авторизационной записи 6.3. Ssh 7. Запуск приложения от другого пользователя 7.1. Разные пользователи на одной машине 7.2. Root-клиент 8. Запуск удаленного менеджера окон 9. Распространенные ошибки 10. Авторские права

В этом документе описываются способы запуска удаленных приложений под X. Он был написан по нескольким причинам.

В конференциях Usenet появилось много вопросов о том, как запускать удаленные приложения под X.

Я вижу многие, многие ответы типа ``используйте xhost +hostname '' или даже `` xhost + '', чтобы разрешить доступ к X-серверу. Это очень небезопасно, есть лучшие методы.

Я не знаю о существовании простого документа, описывающего эти возможности. Если вы знаете, то напишите мне по адресу zweije@xs4all.nl.

Описание в этом документе рассчитано на системы Unix. Если ваша локальная или удаленная операционная система из другой серии, то, по крайней мере, вы ,поймете как это работает в принципе, или же сами переведете примеры на свою систему.

Это версия 0.6.1. Без гарантий, но с хорошими намерениями. Всегда рад вашим предложениям, идеям, дополнениям, полезным указаниям, исправлениям опечаток, и т.п. Я хочу оставить этот документ в простой форме, но и в лучшем стиле HOWTO. Все негодования буду препровождать в /dev/null .

Содержание обновлено 19 ноября 1999 Vincent Zweije

X System Window System Vol. 8 X ``Window System Administrator's Guide'' от O'Reilly and Associates также привлек мое внимание в качестве хорошего источника информации. К сожалению, я не смог проверить его.

Вы используете два компьютера. Первый, с графической оболочкой X, используется в качестве графического терминала. Второй - для некоторых важных работ с графикой. Вы хотите работать на втором компьютере, находясь за первым. X-windows предоставляет эту возможность.

Чтобы достигнуть этого, необходимо две вещи:

Скомандовать X-серверу, чтобы он работал с удаленным компьютером.

Скомандовать удаленному компьютеру (клиенту), чтобы он посылал информацию на ваш дисплей.

Волшебное слово это DISPLAY (ДИСПЛЕЙ). В X-windows под дисплеем понимается (упрощенно) клавиатура, мышь и экран. Дисплей управляется программой-сервером, известной как X-сервер. Сервер обслуживает вывод программ, подключенных к нему.

Дисплей указывается именем, например:

Название дисплея содержит имя компьютера (напр. light.uni.verse или localhost ), двоеточие и номер (напр. 0 или 4). Имя компьютера в названии дисплея - это имя машины, на которой запущен X-сервер. Неуказанное имя компьютера подразумевает localhost. Номер дисплея обычно ``0'', и может варьироваться, если к компьютеру подключено несколько дисплеев.

Если вы когда-либо сталкивались в названии дисплея с дополнительным .n в конце, это номер экрана. Хотя обычно есть только один экран с номером n=0 по умолчанию.

Существуют другие формы описания дисплея, но для наших целей достаточно вышесказанного.

hostname:D.S означает экран S на дисплее D машины hostname ; X-сервер для этого дисплея находится на TCP порту 6000+D .

host/unix:D.S означает экран S на дисплее D машины host ; X-сервер для этого дисплея находится на UNIX domain socket /tmp/.X11-unix/XD (т.е. доступном только с машины host ).

:D.S эквивалент host/unix:D.S , где host это имя локальной машины.

Клиентская программ (например, ваше графическое приложение) знает, какой дисплей использовать из переменной окружения DISPLAY . Ее можно переопределить, либо использовать аргумент -display hostname:0 во время запуска вашей программы. Рассмотрим это на примере.

Наш компьютер известен в сети как light, в домене uni.verse. Если мы запустим обычный X-сервер, переменная DISPLAY будет равна light.uni.verse:0 . Но мы хотим запустить программу для рисования xfig на удаленном компьютере dark.matt.er , а в качестве дисплея использовать машину light.

Полагаю, что вы уже вошли на удаленный компьютер dark.matt.er .

Если вы используете csh в качестве оболочки на нем:

Если вы используете sh в качестве оболочки:

Кажется, некоторые версии telnet автоматически передают переменную DISPLAY на удаленный компьютер. Если у вас как раз такая, считайте, что вам повезло, и не надо указывать ее вручную. В противном случае, большинство версий telnet передают переменную окружения TERM ; можно установить переменную DISPLAY , основываясь на переменной TERM .

Основная идея состоит в том, чтобы при помощи скрипта сделать следующее: перед запуском telnet, добавляем значение переменной DISPLAY к переменной TERM . На другом конце в скрипте .*shrc устанавливаем значение DISPLAY из переменной TERM .

Сервер не принимает соединения просто так, откуда угодно. Да вам и не нужно, чтобы кто-нибудь выводил окна на экране. Или читал, что вы набираете (помните! клавиатура это часть дисплея).

Слишком мало людей, кажется, понимают, что подобный доступ к вашему дисплею снижает степень безопасности. Кто-нибудь, кто имеет доступ к вашему дисплею, может, что угодно посмотреть и написать на ваш экран , считывать нажатия клавиш и действий мыши.

Большинство серверов знают два пути аутентификации: механизм, основанный на списке машин (xhost), и механизм, основанный на magic cookie (xauth). Кроме того, есть ssh, оболочка с шифрованием, которая может обслуживать X-соединения.

6.1. Xhost

Xhost открывает доступ, основанный на названиях машин. Сервер поддерживает список машин, которым позволено подключаться к нему. Он же может отключить проверку имен полностью. Осторожно: это значит, что не будет выполняться никаких проверок, так что может подключиться любая машина!

Вы можете изменять список машин при помощи программы xhost. Чтобы использовать этот механизм для предыдущего примера, сделайте:

Это открывает доступ ко всем соединениям с машины dark.matt.er . Как только ваш X-клиент подключится к X-серверу (появятся окна), закройте доступ при помощи:

Вы можете отключить проверку вообще:

Это отключает проверку и позволяет подключиться кому угодно. Вы никогда не должны этого делать в сети, в которой вы доверяете не всем пользователям (напр. Internet). Вы можете снова включить проверку:

"xhost -" не удаляет все машины из списка доступа (это было бы бесполезно - вы не смогли бы подсоединиться ниоткуда, даже со своей же машины).

Xhost - очень небезопасный механизм. Он не различает пользователей на удаленной машине между собой. Кроме того, имена машин (а тем более адреса) можно подделать. А это плохо, если вы находитесь в сети, которой не доверяете (например, уже при PPP доступе к Internet).

6.2. 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.

6.2.1. Создание авторизационной записи

Если вы хотите использовать xauth, запустите X-сервер с аргументом -auth authfile . Если вы пользуетесь скриптом startx, лучше это сделать в нем. Создайте авторизационную запись, как показано ниже в вашем скрипте startx.

Отрывок из /usr/X11R6/bin/startx :

Mcookie - это простая программа в пакете util-linux (ftp://ftp.math.uio.no/pub/linux/). Кроме того, вы можете использовать md5sum для преобразования случайных данных (например, из /dev/urandom или ps -axl ) в формат авторизационной записи:

Если вы не можете отредактировать скрипт startx (если вы не root), скажите своему системному администратору, чтобы он настроил startx правильно, или пусть установит xdm. Если он не хочет или не может, вы можете создать скрипт ˜/.xserverrc . Если он у вас есть, он запускается через xinit, а не через X-сервер. Затем вы можете запустить X-сервер из этого скрипта с правильными аргументами:

Если для управления сеансами вы используете xdm, то можно легко использовать xauth. Определите ресурс DisplayManager.authDir в /etc/X11/xdm/xdm-config . Во время запуска X-сервера xdm сам укажет аргумент -auth , а когда вы войдете в систему, xdm положит авторизационную запись в ваш ˜/.Xauthority . Для дополнительной информации читайте xdm(1). Например, мой /etc/X11/xdm/xdm-config содержит следующую строчку:

6.2.2. Передача авторизационных записей

Теперь, когда вы запустили X-сервер на машине light.uni.verse и у вас есть файл ˜/.Xauthority , нужно передать авторизационную запись на машину клиента dark.matt.er .

Самое простое, если у вас один и тот же сетевой домашний каталог на машинах light и dark. Файл ˜/.Xauthority один и тот же и авторизационная запись передается моментально. Тем не менее, здесь есть одна проблема: когда вы кладете авторизационную запись для :0 в ˜/.Xauthority , машина dark думает, что эта запись для нее, а не для light. Поэтому вам нужно явно указывать имя компьютера во время создания записи. Можно установить одинаковую запись для :0 и light:0 при помощи:

Если домашний каталог не разделяется между машинами, вы можете передать авторизационную запись при помощи rsh:

Извлечь запись из ˜/.Xauthority ( xauth nlist :0 ).

Передать на dark.matt.er ( | rsh dark.matt.er ).

Поместить ее в ˜/.Xauthority there ( xauth nmerge - ).

Замечу насчет $ . Вам нужно передать авторизационную запись, явно ассоциированную с локальной машиной. Удаленное приложение может интерпретировать :0 как ссылку на удаленную машину, а это не то, что вы хотите!

Возможно, что rsh не разрешен для вас. Кроме того, rsh имеет недостаток с точки зрения безопасности (можно подделать имя машины, если я правильно помню). Если вы не можете или не хотите использовать rsh, передайте авторизационную запись вручную. Примерно так:

Для дополнительной информации см. rsh(1) и xauth(1x).

Есть возможность передать авторизационную запись в переменных окружения TERM или DISPLAY . Это делается таким же образом, как и передача переменной DISPLAY . См. раздел "Говорим клиенту:". Это моя точка зрения, но я заинтересован в том, чтобы кто-нибудь подтвердил или опроверг ее.

6.2.3. Использование авторизационной записи

X-приложение на машине dark.matt.er, такое как xfig, автоматически заглядывает в файл ˜/.Xauthority и ищет нужную запись для авторизации.

Есть небольшая проблема во время использования localhost:D . X-клиент во время поиска записи может перевести localhost:D как host/unix:D . На самом деле это означает, что авторизационная запись для localhost:D в ˜/.Xauthority не имеет эффекта.

6.3. Ssh

Кто знает еще какие-нибудь методы аутентификации или шифрования X-соединений? Может быть kerberos?

Предположим, что вам нужно запустить графическую утилиту конфигурации, которая требует привилегий root. Тем не менее, ваш сеанс под X запущен от обычного пользователя. Это может показаться странным, но X-сервер не даст утилите доступа к вашему экрану. Как это может быть возможным, если обычно root может делать все что угодно? И как мне решить эту проблему?

Давайте обобщим ситуацию. Итак, вы хотите запустить X-клиент от другого пользователя clientuser , а X-сервер запущен пользователем serveruser . Если вы внимательно читали раздел, посвященный авторизационным записям, вам ясно, почему clientuser не имеет доступа к дисплею: ˜clientuser/.Xauthority не содержит правильной авторизационной записи для доступа к вашему дисплею. Правильная авторизационная запись находится в ˜clientuser/.Xauthority .

7.1. Разные пользователи на одной машине

Конечно, все что работает на удаленной машине, аналогично работает для другого пользователя на той же машине. Просто клиент и сервер это одна и та же машина. Тем не менее, в данном случае существует несколько кратчайших путей передать авторизационную запись.

Допустим, что вы используете su для переключения между пользователями. То есть все, что вы должны сделать, это написать скрипт, запускающий su с командами, необходимыми для запуска X-клиента: установить переменную DISPLAY и передать авторизационную запись.

Установить переменную DISPLAY сравнительно просто; надо определить DISPLAY="$DISPLAY" перед запуском команды su. Итак, вы можете просто сделать:

Это пока не сработает, потому что мы все еще не передали авторизационную запись. Мы можем извлечь запись при помощи команды xauth list "$DISPLAY" . Эта команда выдает список авторизационных записей в формате, в котором их можно загрузить обратно в xauth ; то что нам нужно! Так что нам осталось передать авторизационную запись в xauth и установить переменную DISPLAY в команде su .

Вы можете написать скрипт, похожий на этот, указав правильные clientuser и clientprogram . Но давайте улучшим скрипт, сделав его менее удобочитаемым, но более универсальным:

Я думаю, он достаточно универсален и работает для большинства случаев. Единственный недостаток, который я могу найти прямо сейчас, это использование одинарных кавычек вместе с двойными кавычками в аргументах команды su ( '$*' ). Если это считается совершенно неправильным, напишите мне.

Назовите скрипт /usr/local/bin/xsu и попробуйте запустить его:

Просто, не правда ли?

7.2. Root-клиент

Очевидно, все, что работает для обычных пользователей, будет работать и для root. Тем не менее, в случае с root вы можете сделать это даже проще, т.к. root может прочитать чей угодно ˜/.Xauthority . Так что нет необходимости передавать записи авторизации. Все, что вам нужно сделать, это установить переменную DISPLAY и указать XAUTHORITY на ˜serveruser/.Xauthority . Примерно так:

Помещаем это в скрипт:

Называем его /usr/local/bin/xroot и пробуем запустить:

Еще проще, не правда ли?

Менеджер окон (такой как twm , wmaker , или fvwm95 ) это такое же приложение, как другие. Должна сработать та же процедура.

Хорошо, почти. В одно и тоже время на дисплее может работать только один менеджер окон. Если у вас уже запущен локальный менеджер окон, вы не можете запустить еще и удаленный (он поругается и закончит работу). Необходимо сначала снять (используя kill или просто выйти) локальный менеджер.

К сожалению, большинство X-сессий заканчиваются командой

а это значит, что когда (локальный) менеджер окон заканчивает работу, сеанс заканчивается, и X-сервер завершает работу.

По ходу вам придется решить еще парочку не очень сложных проблем. Просто поиграйтесь со скриптом X-сеанса (обычно это ˜/.xsession или ˜/.xinitrc ), чтобы настроить его так, как вы хотите.

Только будьте осторожны. Менеджер окон часто предоставляет различные способы запуска программ, и, если они запускаются на локальной машине, запущен локальный менеджер окон. Если запущен удаленный менеджер окон, он запускает приложения, находящиеся на удаленной машине, а это может быть не то, что вы хотите. Конечно, они будут отображаться на вашем дисплее.

Нет переменной DISPLAY в окружении, и вы не указали программе параметр -display . Приложение принимает по умолчанию пустую строку, а это синтаксически не правильно. Установите переменную DISPLAY (при помощи setenv или export в зависимости от оболочки).

Errno = 101 это ``Сеть не доступна''. Приложение не может выполнить сетевое соединение с сервером. Проверьте, правильно ли установлена переменная DISPLAY , и доступен ли сервер с вашего клиента (сеть должна работать, в конце концов, вы только что вошли на удаленную машину через сеть).

Errno = 111 это ``В соединении отказано (Connection refused)''. Машина сервера, к которой вы хотите подсоединиться доступна, но указанный сервер на ней не запущен. Проверьте, правильное ли имя машины и номер дисплея вы используете.

Клиент подключился к серверу, но сервер не позволяет клиенту пользоваться им (не авторизован). Убедитесь, что передана правильная авторизационная запись, и она не устарела (сервер использует новую запись каждый раз во время запуска).

Этот документ является частью проекта Linux HOWTO.

Авторские права на документы Linux HOWTO принадлежат их авторам, если явно не указано иное. Документы Linux HOWTO, а также их переводы, могут быть воспроизведены и распространены полностью или частично на любом носителе, физическом или электронном, при условии сохранения этой заметки об авторских правах на всех копиях. Коммерческое распространение разрешается и поощряется; но, так или иначе, автор текста и автор перевода желали бы знать о таких дистрибутивах.

Все переводы и производные работы, выполненные по документам Linux HOWTO, должны сопровождаться этой заметкой об авторских правах. Это делается в целях предотвращения случаев наложения дополнительных ограничений на распространение документов HOWTO. Исключения могут составить случаи получения специального разрешения у координатора Linux HOWTO, с которым можно связаться по адресу приведенному ниже.

Xhost

light$ xhost +dark.matt.er

light$ xhost -dark.matt.er

Вы можете отключить проверку вообще:

Это отключает проверку и позволяет подключиться кому угодно . Вы никогда не должны этого делать в сети, в которой вы доверяете не всем пользователям (напр. Internet). Вы можете снова включить проверку:

Xauth

Отрывок из /usr/X11R6/bin/startx :

mcookie|sed -e 's/^/add :0 . /'|xauth -q xinit -- -auth "$HOME/.Xauthority"

dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q xinit -- -auth "$HOME/.Xauthority"

light$ xauth nlist "$:0" | rsh dark.matt.er xauth nmerge -

Для дополнительной информации см. rsh(1) и xauth(1x).

Кто знает еще какие-нибудь методы аутентификации или шифрования X-соединений? Может быть kerberos?

Многие пользователи Linux сталкивались с проблемой, когда после ввода пароля вместо загрузки графического окружения и рабочего стола появляется чёрный экран, а потом снова запрос ввода пароля. Такая ситуация называется Login loop или ещё её можно описать как ошибка входа в систему. Часто она вызвана неверно выполненным обновлением или экспериментами с системой, хотя у неё могут быть и другие причины.

Почему не входит в систему Ubuntu

Но сначала надо попасть в терминал. Для этого на экране входа нажмите сочетание клавиш Ctrl+Alt+F2, затем введите логин и пароль:

Перед вами откроется командная строка в которую уже можно вводить команды терминала. Теперь вы можете просмотреть лог с ошибками:

Если здесь этого файла нет, что можно попытаться найти его по такому пути:

1. Нет места на диске

2. Проблемы с обновлением

Если вы раньше выполняли обновление и оно прошло неудачно, попробуйте его завершить. Для этого выполните такие команды:

sudo apt update
sudo apt -y full-upgrade

Затем очистите систему от лишних пакетов:

sudo apt -y autoremove
sudo apt -y clean

3. Неверные права на

Убедитесь, что права на файл

/.Xauthority верные. Владельцем этого файла должен быть пользователь, от имени которого вы пытаетесь войти в систему и у этого владельца должны быть все права на файл. В старых дистрибутивах этот файл находился в домашней папке:

В современной Ubuntu он находится по пути /run/user/id_пользователя/gdm/Xauthority и создается он уже после успешного входа в систему:

ls -l /run/имя_пользователя/id_пользователя/gdm/Xauthority

Во втором случае проблема с правами вряд-ли возникнет, но в первом она вполне может быть. Для её исправления выполните:

sudo chown имя_пользователя:имя_пользователя

4. Неверные права на /tmp

Папка /tmp предназначена для записи временных файлов и поэтому она должна быть доступна всем пользователям в системе как для чтения, так и для записи. Проверьте какие сейчас установлены права на эту папку:

ls -l / | grep /tmp

Затем установите правильные права если надо:

sudo chmod 1777 /tmp

5. Проблема с проприетарными драйверами

Ещё одной причиной проблем может стать проприетарный драйвер видеокарты. Возможно он сломался после обновления или каких-либо действий с ядром. Его можно обновить до новой версии, переустановить или удалить вовсе. Для удаления драйвера Nvidia используйте команду:

sudo apt remove nvidia-*

Затем очистить конфигурацию Xorg:

нужно переустановить свободный драйвер Nouveau:

sudo apt install --reinstall xserver-xorg-video-nouveau

Подробнее про удаление видео драйвера Nvidia читайте тут. Про установку драйвера Nvidia - здесь.

6. Перезапуск менеджера входа

После того, как вы проверили все методы надо вернуться в графический режим и попробовать войти в систему снова. Для этого используйте сочетание клавиш Ctrl+Alt+F1 или Ctrl+Alt+F7 в старых системах. Также вы можете полностью перезагрузить компьютер или только менеджер входа:

sudo systemctl restart display-manager

Выводы

Нет похожих записей

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.

Читайте также: