SSL предоставляет новый механизм удобного, безопасного доступа к удаленным рабочим столам при помощи VNC и стандартных Web-браузеров.
Хотите увидеть рабочий стол удаленно, с большим удобством, чем это возможно при использовании проприетарных решений, и с большей безопасностью, чем при использовании ssh? Вот хороший способ добиться этого. Описания этой методики ранее мы не встречали.
Идея состоит в использовании SSL для обеспечения безопасности использования простого клиента VNC, встроенного в Web-страницу. Это означает, что практически любой Java-совместимый Web-браузер может видеть удаленный рабочий стол и взаимодействовать с ним; это обеспечивает эффективное решение в типовых ситуациях, включая удаленную совместную работу, осуществление технической поддержки и инициализацию.
Компьютер там, рабочий стол здесь
Компьютер где-то выполняет какие-то операции, человек где-то в другом месте хочет видеть результат выполнения этих операций. Диапазон ситуаций, которые попадают под это описание, огромен, и число средств, позволяющих успешно выполнить такую задачу, почти так же велико. Один из вариантов, особенно подходящий для людей, не являющихся специалистами в области программного обеспечения, — опубликовать обычный рабочий стол в виде адреса URL, защищенного протоколом HTTPS. “Обычным” пользователям удобно выбирать гиперссылки для доступа к рабочему столу или вводить URL в поле адреса браузера.
Приложив небольшое усилие, через несколько минут вы сможете настроить свой собственный удаленный рабочий стол. Решающее функциональное отличие такого подхода состоит в механизме осуществления аутентификации: вместо того чтобы базироваться на обычных учетных записях, что типично для удаленных механизмов, базирующихся на ssh, IPv6, OpenVPN и множестве проприетарных продуктов, сейчас мы увидим как настроить пары учетная запись/пароль для SSL. Это чрезвычайно “легкий” вариант — защитить хост с рабочим столом от иных вариантов использования. В то же время, технология широко используется через Web и близка многим разработчикам.
Хотя для настройки VNC-через-SSL требуется выполнить всего несколько действий, в настройке основной конфигурации есть тонкий момент: Java VNC клиенты не будут соединяться с сайтами SSL, имеющими самостоятельно подписанный сертификат. Точнее, JVM, обычно используемые популярными браузерами, требуют сертификатов, подтвержденных “уполномоченными сторонними” центрами сертификации (certificate authority, CA).
На самом деле это относится к читателям этой статьи, склонным к систематизации. Если вы обслуживаете или разрабатываете безопасные Web-сайты, вы, вероятно, уже работаете с SSL. В таком случае вы можете использовать имеющийся Web-сервер и подписанный сертификат для вашего проекта VNC-через-SSL. Если вы не имеете опыта работы с SSL, предлагаемая нами технология — не лучшее решение для начинающих. Более традиционные ssh-туннели, или Hamachi, или коммерческие решения, вероятно, позволят вам с большей легкостью приобщиться к миру удаленных рабочих столов. Более подробно об этом см. во врезке Сертификаты и SSL.
Первый шаг — установка VNC-сервера(ов) и соответствующих туннелей. Для этого вам необходимо иметь сертификат, позволяющий создавать корректные файлы ключей, включая закрытый и открытые ключи. Ключи размещаются в файле /etc/ssl/certs/stunnel.pem. Вот пример использования TightVNC-сервера на display :5.
Листинг 1. Запуск TightVNC-сервера и туннеля
$ tightvncserver :5
$ stunnel -d 5705 -r 5905 -p /etc/ssl/certs/stunnel.pem
Несмотря на то, что большинство Linux-хостов настроены так, что пользователь может запустить vncserver, весьма вероятно, что для эффективного использования stunnel вам понадобятся привилегии root’а. В зависимости от модели механизма защиты, используемой на вашем хосте, может быть вам лучше использовать sudo stunnel ….
На этом этапе сервер предложит выполнить нешифрованное соединение с адресом there:5905 и шифрованное соединение с адресом there:5705. Проверить можно с помощью любого удобного VNC viewer’а, указав yourhost:5. Чтобы убедиться, что stunnel запустился и выполняется, обратитесь к системному журналу при помощи следующей команды:
Листинг 2. Проверяем, что stunnel выполняется успешно
# grep stunnel /var/log/syslog|tail -24
Aug 21 18:58:17 there stunnel[5453]: Using '5905' as
tcpwrapper service name
Aug 21 18:58:17 there stunnel[5453]: stunnel 3.26 on
i386-pc-linux-gnu PTHREAD+LIBWRAP with OpenSSL 0.9.7e 25 Oct 2004
Aug 21 18:58:17 there stunnel[5454]: FD_SETSIZE=1024,
file ulimit=1024 -> 500 clients allowed
Возможные ошибки — неправильный файл ключа, несоответствие прав доступа, порт уже используется — отображаются в том же журнале. Например, в случае отсутствия ключа в журнале появится следующее сообщение:
Aug 21 18:58:17 there stunnel[5453]: /etc/ssl/certs/stunnel.pem: No such file or directory (2)
Этот сервер успешно работает и на нешифрованных, и на шифрованных портах, мы сосредоточим свое внимание на VNC Web-клиенте. Для этого необходимо загрузить с x11vnc-проекта Java VNC viewer с поддержкой SSL. После загрузки архива Java-код доступен в x11vnc-X.Y.Z/classes/ssl/VncViewer.jar и x11vnc-X.Y.Z/classes/ssl/SignedVncViewer.jar. Задайте каталог для содержимого VNC и скопируйте туда VncViewer.jar, затем создайте страницу HTML. Вот пример файла HTML, предоставляющего соединение с there:5705 через SSL:
Листинг 3. Соединение с there:5705 <html> <body> <applet code="VncViewer.class" archive="VncViewer.jar" width="800" height="600"> <param name="PORT" value="5705" /> <param name="HOST" value="there" /> <param name="Open New Window" value="no" /> <!-- the following helps in Opera: <param name="Cursor shape updates" value="Disable" /> --> </applet> </body> </html>
И HTTP, и HTTPS могут обслуживать этот апплет. Использование HTML и Jar-файлов происходит через HTTP на порту 80, под URI /vnc, затем адрес http://there/vnc появится на рабочем столе. Не забудьте разрешить вашему браузеру использовать Java! Кроме того, обратите внимание, что необходимо использовать одно и то же имя хоста и в параметре HOST, и в исходном адресе; этого в сущности требует модель механизма защиты Java-апплетов.
Несколько дополнительных замечаний по использованию
Одно из преимуществ использования стандартных компонентов и протоколов состоит в том, что они довольно легко могут быть заменены. Например, большинство наших разработок было сделано с применением Xvnc VNC-сервера и некоторые из них могут быть заменены на TightVNC с помощью метода, описанного выше. Обратите внимание, что для запуска этих вариантов аргументы командной строки будут несколько отличаться; тем не менее в любом случае идея остается прежней. Почти во все дистрибутивы Linux входят VNC-серверы, собранные в соответствии со стандартами этого дистрибутива, и некоторые VNC-проекты с открытыми исходными кодами могут быть легко установлены из исходников. Наиболее сложное в инсталляции любого VNC-сервера — необходимость наличия по умолчанию определенных шрифтов. Тем не менее, даже в этом случае по крайней мере средство обозначено четко.
Есть как минимум одно препятствие в использовании VNC viewer’а с поддержкой SSL через браузер. Он может использоваться со всеми основными браузерами, в том числе Mozilla Firefox, Internet Explorer и Opera, но все эти браузеры требуют Java runtime версии 1.4 или выше. Проблема возникает при использовании операционных систем Microsoft Windows, которые все еще зависят от Microsoft JVM 1.1. В таких случаях VNC viewer не запустится в Internet Explorer и выдаст сообщение, что класс VncViewer не найден. Единственное решение состоит в том, чтобы предложить использовать не SSL-соединение с VNC-сервером и обновить Java до любого свежего Java Runtime.
По умолчанию большинство VNC-серверов не предоставляют возможность совместного использования рабочего стола, то есть любое новое соединение прерывает предыдущее. Для совместной работы, технической поддержки и других подобных целей запустите сервер из командной строки с аргументом -alwaysshared или другим подобным (как указано в документации). Это позволит одновременно подсоединиться к одному и тому же рабочему столу нескольким пользователям.
Хотя вы, может, и работали с VNC, Web-сервисами, Java, SSL, браузерами и так далее, вы, возможно, никогда не использовали их одновременно таким способом. Что именно вы имеете теперь?
На самом деле, довольно много. Для начала, это похоже на screen в GUI; то есть, вы можете запустить графическую сессию на работе, использовать, как обычно, в течение дня всю ее производительность и функциональность, оставить ее в текущем состоянии и вновь подключиться к той же самой сессии через любой Web-браузер с поддержкой Java! Это очень мощный инструмент.
Однако вы получаете не только это. VNC очень удобен для телеконференций. Мы используем его, например, для настройки демонстрации сложных графических приложений для зрителей, не являющихся специалистами в сфере компьютерных технологий. В принципе, удаленный X-сервер может исполнять почти такие же функции, но VNC предоставляет некоторые преимущества:
-Его технология обеспечения безопасности лучше поддается настройке.
-При наличии установленных firewall’ов получить доступ к VNC часто легче, чем к X.
-VNC viewer’ы проще в установке, чем X-серверы — особенно это касается базирующихся на браузерах viewer’ов, которые не требуют дополнительных установок.
-Он легко позволяет предоставить рабочий стол через VNC нескольким пользователям.
-VNC обычно менее чувствителен к задержкам в сети.
Несмотря на то, что X-аутентификация (и ssh-туннелирование) обычно основаны на учетных записях из /etc/passwd, доступ при помощи Web использует HTTP(S)-аутентификацию. Имеется богатый опыт в создании и обслуживании таких учетных записей, даже с кратковременными целями, например, для демонстрации телеконференций.
VNC viewer’ы гораздо менее требовательны к памяти и аппаратным ресурсам, чем X-серверы.
В VNC-серверах обычно предусмотрена такая полезная конфигурация, как предоставление доступа только для чтения.
Кроме того, ключом к части этой технологии является то, что основная вычислительная нагрузка, связанная с криптографией, выполняется с использованием “родного” кода вместо Java run-time. В большинстве случаев в качестве первой апроксимации для определения производительности могут быть приняты сетевые задержки, но шифрование и дешифрование достаточно дороги и делают альтернативные методы непригодными, за исключением случаев применения на высокопроизводительных компьютерах. В технологии VNC-через-SSL вызывает наше восхищение то, что клиенты могут использовать стандартное программное обеспечение на старом и довольно простом оборудовании, чтобы получить вполне приемлемую ответную реакцию.
Вы, вероятно, ограничены определенными условиями и имеете доступ к определенным реурсам. Вы должны решить для себя, насколько VNC сопоставим с коммерческими предложениями от Citrix, Windows Terminal services, WebEx, Hamachi и другими “удаленными” решениями. Однако мы видели, что технология VNC-через-SSL позволяет решать поразительный диапазон проблем.
В следующей статье мы покажем, как объединить VNC с другими виртуальными средами для достижения мощных методов распределения ресурсов. Однако, прежде чем завершить это введение, важно напомнить читателям, что VNC имеет серьезные проблемы безопасности. Разумно предположить, что грубые атаки на стандартный сервис VNC, защищенный только одним паролем сессии, взломают его за несколько часов или дней. Интерес “плохих парней” к VNC быстро растет; убедитесь, что вы используете для VNC качественный пароль, состоящий из как минимум восьми символов, предпочтительно смеси цифр, букв и других символов. SSL повышает степень защищенности, и вам следует воспользоваться этим, если вы часами оставляете сессию открытой. В дальнейшем аспекты обеспечения безопасности будут рассмотрены подробнее.
Рецепт, приведенный выше, предоставляет несколько основанных на открытых кодах средств, но почти не затрагивает собственно программирование. Нас удивило, что, кажется, никто не документировал этот же набор компонентов и что они были так легко собраны. Более подробную информацию о VNC и SSL вы найдете в разделе Ресурсы.
В следующей статье мы рассмотрим подробнее пару специфических рабочих мест, использующих технологию VNC-через-SSL, и расскажем, как вы можете применить эту технологию в ваших условиях, а также рассмотрим распространенные методы использования firewall’ов и серверов прокси. Мы также объясним, при каких условиях вы можете получить выгоду от использования “родных” VNC viewer’ов во взаимодействии с клиентами, работающими через браузер, как это описано в данной статье.
Особую благодарность мы выражаем Мэту Кеннелу (Matt Kennel), который заботится о безопасности и обсуждает с нами возможности использования технологии VNC-через-SSL на деле.
Оригинал статьи на developerWorks.