Недопустимый MIT -MAGIC -COOKIE -1 keyxhost :невозможно открыть дисплей «:0»
Это связано с соглашением OpenBSD, упомянутым в книге "Абсолютная OpenBSD, 2-е издание :Unix для практических параноиков" (с. 103):
_username
If you take a look at /etc/passwd, you’ll see that many unprivileged users have an underscore before their name, such as _syslogd, _ldapd , and _dhcp.
This is an OpenBSD convention for identifying unprivileged users. Most add-on software also uses unprivileged usernames beginning with an underscore, such as _mysql and _postgresql.
Not all unprivileged usernames start with an underscore, however. Some of these are legacy users that OpenBSD retains for compatibility reasons, such as nobody. Others have a long history or support inflexible software, and changing them would be more annoyance than it’s worth.
The presence of an underscore means that a user is unprivileged. The absence of an underscore means nothing; the user might be a normal or it might be unprivileged. If you create your own unprivileged users, you don’t need to include a leading underscore, but doing so will help other system administrators understand what the user does.
Invalid MIT-MAGIC-COOKIE-1 keyxhost: unable to open display ":0"
На самом деле это два сообщения об ошибках, которые были напечатаны в одной строке:
Invalid MIT-MAGIC-COOKIE-1 key
xhost: unable to open display ":0"
Когда вы входите в систему с помощью графического интерфейса пользователя X11, этому сеансу автоматически присваивается DISPLAYпеременная среды и специальный ключ доступа (для сеанса -, который хранится либо в ~/.Xauthority, либо в файле, указанном в XAUTHORITY. ] переменная окружения ).
Входы в консоль отделены от входа в GUI, поэтому сеанс входа в консоль не будет автоматически получать ничего из этого. И вы не можете использовать xhostдля настройки управления доступом к сеансу GUI, если у вас нет доступа к сеансу GUI в первую очередь.
Когда сеанс GUI завершается и сервер X11 перезапускается, на стороне сервера X11 создается новый ключ сеанса, который автоматически делает предыдущий ключ недействительным. Но старый сеансовый ключ можно оставить в пользовательском файле .Xauthority. Он будет автоматически заменен при следующем входе в GUI. Таким образом, наличие ключа MIT -MAGIC -COOKIE -1 в файле .Xauthorityне означает, что это обязательно текущий ключ.
Если вы запустите pgrep -a Xorg, вы можете увидеть параметры строки команды -процесса X-сервера как что-то вроде Xorg -nolisten tcp -auth <some path> <other options...>. Путь, указанный параметром -auth, является файлом ключа сеанса на стороне текущего сервера -:, если у вас есть root-доступ, вы можете просмотреть его, например, с помощью. xauth -f <some path> listи сравните его с содержимым собственного файла .Xauthority, который лучше всего просматривать с помощью xauth list. На выходе будет одна или несколько строк, подобных этой:
debian/unix:0 MIT-MAGIC-COOKIE-1 <actual key in hexadecimal>
Файл ключа на стороне сервера -всегда должен содержать ровно 1 строку, но если вы использовали SSH-соединения с переадресацией X11, у вас могут быть другие строки в вашем собственном файле .Xauthority, начиная, например, с. debian/unix:10или более высокие цифры дисплея.
Если вывод xauth listиз вашего файла .Xauthorityсодержит строку, точно совпадающую с единственной строкой, отображаемой xauth -f <some path> list, вы сможете получить доступ к X-серверу; если нет соответствующей строки,X-сервер отклонит ваши запросы с ошибкой Invalid MIT-MAGIC-COOKIE-1 key.
Я предполагаю, что у вас может быть команда xhostв вашем ~/.profile, ~/.bashrcили любом подобном сценарии входа в систему. Вы должны обернуть его в тест, который будет проверять наличие переменной $DISPLAYперед запуском xhost, поэтому вместо, например.:
xhost +local:
у вас будет, например.
if [ "$DISPLAY" != "" ]
then
xhost +local:
fi
Но если используется расположение по умолчанию для файла ~/.Xauthority, и вы делаете это только , чтобы разрешить использование инструментов администрирования с графическим интерфейсом при использовании sudoдля получения корневого доступа, может быть более безопасный способ. Вместо добавленияxhost +local:(= позволяет всем, кто, например. SSH на тот же хост для доступа к вашему сеансу графического интерфейса ), вы можете добавить что-то подобное в свой~/.bashrc:
if [ "$SUDO_USER" != "" ] && [ "$DISPLAY" != "" ]
then
export XAUTHORITY=$(grep "^${SUDO_USER}:" /etc/passwd | cut -d : -f 6)/.Xauthority
fi
Вместо ослабления безопасности вашего сеанса графического интерфейса используется тот факт, что root может читать все (, поэтому он не будет работать, если ваш домашний каталог является монтированием NFS -, которое экспортируется с root_squashопция ). Когда вы используете sudo, он устанавливает переменную XAUTHORITYтак, чтобы она указывала непосредственно на файл .Xauthorityв домашнем каталоге вашей личной учетной записи пользователя.
(Кроме того, этот трюк не работает, если вы используете sudo su -. Вместо этого используйте sudo -iи добавьте аналогичный фрагмент в /root/.bashrcили /root/.profile. Но будьте осторожны при редактировании этих файлов :: досадная ошибка может затруднить повторное получение рабочей корневой оболочки.)