Говорим серверу:

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

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

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

Xhost

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

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

light$ xhost +dark.matt.er

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

light$ xhost -dark.matt.er

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

light$ xhost +

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

light$ xhost -

"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 содержит следующую строчку:

DisplayManager.authDir: /var/lib/xdm

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

Теперь, когда вы запустили 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 "${HOST}:0" | rsh dark.matt.er xauth nmerge -

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

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

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

Замечу насчет ${HOST}. Вам нужно передать авторизационную запись, явно ассоциированную с локальной машиной. Удаленное приложение может интерпретировать :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?