Система X Window

Обеспечение безопасности X Window, часть вторая: направление X Window трафика через SSH

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

Протокол SSH (Secure Shell) дает возможность перенаправить TCP-соединения через SSH-туннель. Если в вашем распоряжении имеется SSH-клиент, который поддерживает перенаправление по протоколу X11, то вы можете зашифровать свои X Window-соединения.

Вновь вернемся к упоминавшемуся ранее примеру с машинами HOST1 и HOST2. Предположим, что мы запустили сервер X Window на машине HOST1, и хотим выполнить клиентское приложение на HOST2 и передавать информацию для отображения на HOST1. Реализация протокола SSH на обеих машинах должна допускать перенаправление X11-трафика (обычно это допускается по умолчанию). Далее следует убедиться, что на SSH сервере на машине HOST2 включена поддержка перенаправления X11 трафика, и для SSH-клиента на машине HOST1 также включена такая поддержка. Вы можете это проверить, просмотрев файлы ssh_config и sshd_config в соответствующей директории (размещающейся в разных местах в зависимости от типа используемой системы, но обычно в директории /etc/ssh ). Проверьте строки X11Forwarding или ForwardX11 и установите параметр "yes", если хотите, чтобы это работало.

С помощью флага -x определим использование перенаправления трафика X11 от HOST1 к HOST2 через SSH. Теперь просмотрим содержимое переменной DISPLAY на HOST2, воспользовавшись командой setenv | grep DISPLAY (для интерпретатора csh и tcsh ) или set | grep DISPLAY (для интерпретатора sh и bash ). Вы должны увидеть нечто похожее на строку

DISPLAY=HOST2:10.0

Но минуточку! Номер дисплея равен 10, а хост - HOST2. Но вы хотели отображать вывод X Window приложения на HOST1. Переменная DISPLAY устанавливается автоматически, как только вы осуществите SSH-соединение с флагом -x. Дисплей номер 10 на HOST2 автоматически назначается на локальный X-сервер, чтобы отображать информацию через SSH на реальном X-сервере на HOST1. Попытайтесь теперь выполнить приложение xclock на HOST2, и вы увидите часики на экране HOST1. Все ваши действия с приложением будут передаваться через шифрованный туннель. Шифрование не строго обязательно, когда вы запускаете удаленно часы, но это может оказаться важным, когда вы используете удаленный запуск редактора xemacs.

Перенаправление X11-трафика через SSH также касается и аутентификации. Вдобавок к автоматическому определению "доверенного" X-сервера, SSH клиент определяет фиктивный идентификационный набор информации и направляет его SSH-серверу. Сервер, в свою очередь, записывает идентификационную информацию в Xauthority файл на удаленной машине, автоматически предоставляя вам доступ к вашему X серверу. Другими словами, если вы запускаете X-сервер на HOST1, SSH-клиент должен сообщить "доверенному" X-серверу на SSH-сервере о необходимости создать следующую запись в Xauthority -файле на HOST2.

HOST2:10 MIT-MAGIC-COOKIE-1 121812483b0b3f19367c1541062b472b

Это предохраняет от передачи реальной идентификационной информации через сеть. В обоих направлениях пересылается только фиктивная идентификационная информация (да и та зашифрованная). Соединения, которые проходят через прокси, могут поставить в соответствие фиктивную идентификационную информацию для HOST2:10 реальным данным для HOST1:0. Это позволяет осуществить перенаправление X-трафика через SSH-туннель к серверу только авторизованному X-клиенту, который запустил X-сервер и SSH-клиент на HOST1.

Вы все еще здесь? Все это может показаться весьма сложным - ниже приведена диаграмма, которая иллюстрирует, что происходит.

увеличить изображение