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

Также можно пробросить RDP-шный трафик через SSH-туннель. Для этого нужно поправить конфигурационный файл xrdp:

$ vi /etc/xrdp/xrdp.ini
В секцию нужно добавить строку: address=127.0.0.1

$ systemctl restart xrdp
Проверить, что всё правильно, можно так:

$ nmap -p 3389 Starting Nmap 6.47 (http://nmap.org) at 2016-10-04 13:07 MSK Nmap scan report for unspecified.mtw.ru () Host is up (0.0087s latency). PORT STATE SERVICE 3389/tcp closed ms-wbt-server
Затем если вы используете cygwin или mingw, linux или mac os:

Ssh root@ -L 3389:localhost:3389
Если PuTTY:

Запустите PuTTY. В древовидном меню слева Connection → SSH → Tunnels. Далее добавляем новый Forwarded Port (Source port: 3389, Destination: localhost:3389). Нажимаем Add.

VNC

Клиент:

Для примера поставим эту DE:

$ apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E $ echo "deb http://packages.x2go.org/debian jessie main" > /etc/apt/sources.list.d/x2go.list $ echo "deb-src http://packages.x2go.org/debian jessie main" >> /etc/apt/sources.list.d/x2go.list $ apt-get update $ apt-get install x2go-keyring && apt-get update $ apt-get install x2goserver x2goserver-xsession
Вывод следующей команды должен показать, что x2go готов к работе:

$ systemctl status x2goserver ● x2goserver.service - LSB: Start and stop the X2Go daemon Loaded: loaded (/etc/init.d/x2goserver) Active: active (running) since Tue 2016-10-11 22:05:51 MSK; 30min ago ...
А теперь важный момент, подключиться без этого фикса не получится! Нужно найти в файле.profile строку «mesg n» и заменить её на «tty -s && mesg n».

$ vi .profile
Следующая команда выведет путь до исполняемого файла startfluxbox, понадобится при настройке клиента:

$ whereis startfluxbox
Установка сервера на Ubuntu:

$ apt-get install xfce4 xfce4-terminal $ add-apt-repository ppa:x2go/stable $ apt-get update $ apt-get install x2goserver x2goserver-xsession

$ vi .profile
Установка сервера на CentOS:

$ yum install epel-release $ yum install x2goserver x2goserver-xsession
Клиент для линукс ставится из вышеприведенных репозиториев следующей командой:

$ apt-get install x2goclient
Для Windows - скачиваем, ставим, запускаем. По той же ссылке, приведенной выше, есть клиент для OS X.

Запускаем клиент:

В настройках сессии указываем: в поле Host - IP вашего сервера, в поле Login - root, порт оставляем как есть, session type - тот GUI который ставили.

Как вы можете видеть, есть возможность аутентификации по ключу. В общем много всякого. Посмотрите сами. И звук можно через PulseAudio выводить.

После нажатия Ok вы увидите вот такие вот очаровательные штучки, на которые нужно нажать для получения запроса на ввод пароля и подключения к выбранной сессии:

Замечание: обратите внимание, что в списке нет Вашего любимого FluxBox’а поэтому путь к нему приходится прописывать руками.

Важной возможностью x2go является возможность запуска любого графического приложения вообще без установки DE. Для этого в настройках сессии нужно в секции session type нужно выбрать пункт single application и выбрать выполняемое приложение или ввести путь к программе которую следует запустить.

В этом случае установка ПО на сервер будет выглядеть следующим образом. В случае с Ubuntu:

$ add-apt-repository ppa:x2go/stable $ apt-get update $ apt-get install x2goserver x2goserver-xsession
А теперь важный момент, подключиться без этого фикса не получится! Нужно найти в файле.profile строку «mesg n || true» и заменить её на «tty -s && mesg n».

$ vi .profile $ apt-get install firefox xterm
И настроив сессию как показано ниже, можно будет запустить браузер на удаленном сервере, а на вашей машине откроется окно его отображающее:

Или так; тогда просто откроется окно терминала:

Ниже вы можете видеть скриншот окна статуса текущей сессии. Оранжевыми цифрами отмечены кнопки:

1. «Suspend session» - после нажатия на эту кнопку соединение будет разорвано, но сессия останется и будет ожидать повторного подключения. Все запущенные вами на сервере приложения продолжат свою работу;
2. «Terminate session» - после нажатия подключение к серверу будет разорвано, а запущенные вами на сервере приложения будут завершены.

TeamViewer

Последний способ удаленного доступа к рабочему столу.

Установка на Ubuntu:

$ apt-get update $ apt-get install lubuntu-desktop $ reboot $ dpkg --add-architecture i386 $ apt-get update $ wget http://download.teamviewer.com/download/teamviewer_i386.deb $ dpkg -i teamviewer_i386.deb $ apt-get -f install $ teamviewer --passwd
Установка на Debian:

$ apt-get update $ apt-get install lxde lightdm $ reboot $ dpkg --add-architecture i386 $ apt-get update $ wget http://download.teamviewer.com/download/teamviewer_i386.deb $ dpkg -i teamviewer_i386.deb $ apt-get -f install $ teamviewer --passwd
Установка на CentOS:

$ yum groupinstall "X Window system" $ yum install epel-release $ yum install fluxbox xterm lightdm $ systemctl set-default graphical.target $ reboot $ curl -o TeamViewer_Linux_PubKey.asc -Lk http://www.teamviewer.com/link/?url=354858 $ rpm --import TeamViewer_Linux_PubKey.asc $ curl -LOk http://download.teamviewer.com/download/teamviewer.i686.rpm $ yum install teamviewer.i686.rpm $ teamviewer --passwd
Также необходимо принять лицензионное соглашение TeamViewer’а, это можно сделать с помощью «Аварийного режима», либо добавить следующие строки в конец файла /opt/teamviewer/config/global.conf:

$ echo " EulaAccepted = 1" >> /opt/teamviewer/config/global.conf $ echo " EulaAcceptedRevision = 6" >> /opt/teamviewer/config/global.conf $ teamviewer --daemon restart
Следующая команда покажет состояние демона TeamViewer’а и необходимый для подключения девятизначный TeamViewer ID:

$ teamviewer --info

После запуска клиента скачанного тут, нужно ввести TeamViewer ID в поле Partner UD и нажать на кнопку «Connect to partner». Далее TeamViewer запросит пароль: .

Вместо заключения

Вот вроде бы и всё. Надеемся что эта статья поможет пользователям linux-серверов в настройке комфортного и удобного для них окружения.

Июль 28

В новых версиях Ubuntu уже есть встроенный VNC сервер . Мы будем использовать его стандартные средства. Пока разбирался в данном вопросе — пришлось почитать приличное количество форумов. Так вот, многие пользователи пишут, что в версии ubuntu 14.04 данный фокус не проходит из-за каких-то внутренних тонкостей устройства ядра. Я в данный вопрос глубоко не вдавался…в любом случае, если вдруг вы являетесь счастливым обладателем именно этой версии — можете воспользоваться альтернативным сервером x11vnc.

Ставится он довольно просто:

Sudo apt-get remove vino sudo apt-get install x11vnc

В этой же статье, будет рассмотрен стандартный VNC сервер уже включенный в ubuntu по умолчанию. Как все настроить?

Коннектимся к удаленному хосту.

Подключаемся через ssh к удаленному компьютеру, к которому хотим получить графический доступ. При этом мы должны знать его ip и логин с паролем пользователя — экран которого хотим видеть. По сути — нам подойдут данные любого пользователя с правами sudo, но тогда прийдется донастраивать некоторые моменты.

Итак, допустим в локальной сети мы имеем компьютер под ubuntu с ip адресом 10.20.0.30 и пользователем feanor184 . Коннектимся к нему из консоли с ключем -X (для запуска графических иксов):

Ssh -X [email protected]

вводим пароль и попадаем в консоль нашего удаленного компьютера.

Теперь, вводим в ней:

Sudo vino-preferences

и видим графическое окно

Тут ставим галочки:

allow other users to view your desktop — разрешаем смотреть рабочий стол.

allow other users to control your desktop — разрешаем управлять мышкой и клавиатурой удаленно.

require the user to enter this password — обязательно устанавливаем пароль на подключение. Мало ли кто лазиет в нашей сети

show notification area icon: always — всегда отображаем иконку vnc вверху экрана в трее.

Вы можете выставить так же свои настройки — здесь описаны мои настройки)

Сохраняем настройки и отсоединяемся от удаленного хоста.

Для подключения к настроенному компьютеру используем любой клиент с поддержкой vnc.

Например, Remmina — для Linux.

UltraVNC Viewer — для Windows.

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

Что имеем в итоге?

Мы получили возможность подключаться к удаленному компьютеру под ubuntu и выполнять на нем любые операции так, как если бы мы сами сидели за его монитором

Дата публикации: вторник, 19 января 2009г. 10:43:53
Перевод: Коваленко А.М.
Дата перевода: 4 августа 2009 г.

Вы используете как Windows, так и Linux? Можете ли вы удаленно управлять Windows из Linux (Ubuntu либо другого дистрибутива) или Linux из Windows? Несомненно, можете. Подобно тому, как используется Подключение к удаленному рабочему столу между платформами Microsoft (или удаленное управление между машинами с Linux), возможно и управление рабочим столом из разных платформ. Вы можете щелкать мышью на рабочем столе и запускать приложения, точно так же, как если бы вы сидели прямо перед компьютером.

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

Выбор протокола удаленного рабочего стола

Приложения удаленного рабочего стола обычно используют либо Протокол Удаленного рабочего стола (RDP), либо протокол Виртуальной Вычислительной Сети (VNC). Для установки удаленного подключения оба узла (сервер и клиент) должны поддерживать один и тот же протокол. Проблема заключается в том, что не все операционные системы (ОС) используют одинаковые протоколы по умолчанию. Вдобавок к этому, некоторые дистрибутивы Linux и некоторые редакции Windows не содержат в себе ни серверного, ни клиентского приложения удаленного рабочего стола, либо не содержат приложение удаленного рабочего стола вообще.

Вашей первой задачей должно стать определение протокола, который уже поддерживается на ваших компьютерах. Дополнительно к исследованию вашей ОС, поиску документации, ссылкам на шпаргалки, вы должны иметь возможность понимать, что есть что и где. Затем, уже в конце, вы должны выбрать протокол для использования на всех ваших компьютерах.

Обратите внимание:

• Удаленный рабочий стол VNC обычно медленнее, чем RDP соединения, тем не менее, VNC обычно легче реализовать на различных платформах.
• Для лучшей производительности и безопасности, вы можете использовать свободный сервер и клиентов NoMachine"s NX или сервер и клиентов FreeNX, но он более сложный в настройке, здесь требуется думать.
• Возможно также, обеспечить поддержку RDP соединений на машинах с Linux, например, используя xrdp сервер.

Открытие брандмауэра (межсетевого экрана)

Перед тем, как перейти к установке удаленных соединений или к их приему, вам необходимо настроить программное обеспечение вашего брандмауэра. На компьютерах, к которым вы хотите подключиться удаленно, необходимо разрешить трафик VNC или RDP через брандмауэр.

В Windows, при старте сервера, вы должны получить запрос на Блокирование или Разрешение доступа к сети приложению сервера удаленного рабочего стола. Если нажать кнопку "Разрешить", все должно заработать. Если вы не получили запрос, то можете зайти в свойства брандмауэра Windows и добавить разрешение для этого приложения вручную, используя номера портов, указанных ниже.

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

• RDP использует TCP порт 3389
• VNC использует порты, начиная с 5900 (каждое удаленное соединение к серверу использует разные порты; дисплей 1 использует порт 5901, дисплей 2 использует порт 5902, и т. д.). Лучшим методом, поэтому, будет определение области портов (таких как 5900 - 5905), когда вы создаете правило брандмауэра или исключения.

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

Использование VNC сервера и клиента в Ubuntu

Если вы используете Ububntu, то вы уже имеете установленные и готовые к использованию клиент и сервер VNC. (Эта статья базируется на дистрибутиве Ubuntu Desktop 8.10 Intrepid Ibex.) Для того, чтобы иметь возможность принимать удаленные соединения, просто выберете в меню Система > Свойства > Удаленный рабочий стол . В диалоговом окне настройте желаемые ресурсы общего пользования и параметры безопасности. Список команда/адрес представлен вам для указания других компьютеров в локальной сети с установленным Ubuntu или другим дистрибутивом Linux, с которых будет производиться подключение.

Для использования VNC вьюера (просмотрщика) на Ubuntu, выберите Приложения > Служебные > Терминал . Если вы подключаетесь к компьютеру, на котором установлен Ubuntu, наберите команду предлагаемую Ubuntu. Если производится подключение к компьютеру, на котором установлен другой дистрибутив Linux, применяется следующий формат команды:

$ vncviewer Имя_Компьютера_или _IP_адрес:#

так как показано на рисунке 1. Эта строка содержит команду, vncviewer , за которой следует имя или IP адрес компьютера (или Internet IP, если подключение производится через web), оканчиваясь двоеточием и ID (идентификатором) дисплея (туннеля). Если производится подключение к компьютеру, на котором установлен Windows, то двоеточие и номер дисплея не указываются, в этом случае формат команды следующий:

$ vncviewer ИмяКомпьютера_или_IP_адрес

рисунок 1

Установка VNC Клиента и Сервера на другие дистрибутивы Linux

Если вы используете дистрибутив Linux, отличный от Ubuntu, поищите в его хранилищах соответствующие пакеты для установки VNC сервера и клиента. Если таких пакетов нет, то вы можете скачать TightVNC напрямую с их веб-сайта и следовать инструкциям по сборке и установке.

Сервер TightVNC/RealVNC не имеет графического интерфейса, вы должны использовать командную строку, но не беспокойтесь - это легко. Просто откройте Терминал , наберите vncserver и нажмите Enter. При первом запуске вам будет предложено создать пароль для VNC соединений. После того, как вы установили пароль, будет автоматически настроен дисплей или туннель, как показано на рисунке 2.

рисунок 2

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

Ниже даны различные опции команды vncserver , которые полезно запомнить:

• Для получения помощи используйте опцию -help или введите команду man vncserver .
• Используя опцию -name desiredname вы можете назначить имя определенному туннелю или дисплею, которое отображается в строке заголовка VNC клиента, когда производится удаленное подключение к этому дисплею.
• Поправка:# позволяет вам вручную определить номер туннеля или дисплея.
• Используя опцию -geometry WxH вы можете установить ширину и высоту экрана для отображения удаленного рабочего стола.
• Добавив -depth # вы можете установить глубину цвета от 8 до 32 бит на пиксель.
• Для закрытия VNC туннеля используйте опцию -kill:# , заменив значок решетки желаемым идентификатором туннеля (дисплея).

В зависимости от определенного дистрибутива Linux и решения VNC, которое установлено, вы можете иметь или не иметь графический пользовательский интерфейс для клиента или приложения вьюера. Если имеется графический интерфейс, - не стесняйтесь использовать его, но, при желании, вы можете использовать и командную строку.

Для графического интерфейса вы можете, как правило, настроить опции из диалогового окна. Когда подключаетесь к машине с дистрибутивом Linux, наберите имя компьютера или IP адрес удаленной машины (или Internet IP когда подключаетесь через web), затем двоеточие, ID туннеля или дисплея и нажмите Enter. Например, ericlinuxbox:1 или 192.168.0.122:1 . Если подключаетесь к машине с Windows, двоеточие и номер дисплея не требуется. Для подключения из терминала, введите vncviewer и информацию об узле, таким же образом как показано на рисунке 1 ранее.

Установка VNC клиента/сервера в Windows

TightVNC также предлагает клиента и сервер в версии для Windows на его странице для скачивания . После установки TightVNC вы можете запустить сервер из меню Пуск (прим. переводчика: Пуск > Все Программы > TightVNC ), выбрав Запустить TightVNC сервер. При этом появится диалоговое окно свойств (см. рисунок 3), где вы должны назначить пароль для входящих сессий.

рисунок 3

После проверки всех установок нажмите ОК. Сервер будет запущен и готов к приему входящих соединений, одновременно в системном трее появится иконка сервера. Еще раз напомню, не используйте двоеточие и номер дисплея, когда подключаетесь к компьютеру с Windows из любой платформы.

Если вы подключаетесь к удаленному компьютеру из Windows, выберите ярлык TightVNC Вьюер из стартового меню. Подобным образом, для подключения из других платформ, введите имя или IP адрес удаленного компьютера (или Internet IP адрес, когда подключаетесь через web), и когда подключаетесь к компьютеру с Linux включите в команду двоеточие и номер дисплея.

Обратите особое внимание на следующую часть : в ней мы рассмотрим безопасность VNC соединений и все настройки, необходимые для удаленного подключения через Интернет.

Eric Geier , автор множества книг о компьютерах и сетях, включая книги "Домашняя Сеть. Все в одном. Настольное руководство для чайников" (Wiley 2008) и "100 вещей, которые вам необходимо знать о Microsoft Windows Vista" (Que 2007).

5. Переместите панель кнопок Button и панель адреса Location с помощью мыши.

6. Измените размеры панелей, используя специальные метки изменения размера на границах окон.

7. Запустите на выполнение в правой панели команду vi.

8. На левой панели просмотра откройте аплет, нажав клавиши .

9. На нижней панели воспользуйтесь компилятором и другими средствами командной строки.

10. Выберите опцию Setting Save View Profile для сохранения профиля.

11. Введите название профиля, а затем выберите опцию Save window size in profile. После этого нужно для сохранения установок щелкнуть на кнопке Save.

6. Контрольные вопросы

1. Какие программы называются файловыми менеджерами?

2. Какая информация отражается в области просмотра программы Konqueror?

3. Как создать новое окно с помощью программы Konqueror?

4. Перечислите задачи по управлению файловой системой, которые можно решать с помощью диспетчера файлов?

5. Перечислите стандартные функции KDE.

6. Что является компонентом рабочего стола KDE?

7. Назовите функции панели рабочего стола.

8. Как получить справку в диалоговом режиме?

9. Какие функции предоставляет центр управления KDE?

Литература 1,3,4

Лабораторная работа №9 Удаленный доступ в Linux

Цель работы: Ознакомиться на практике со средствами удаленного управления в операционной системе Linux. Приобрести опыт и навыки управления удаленным доступом

План проведения занятия

4. Используя теоретические сведения изучить назначение и правила работы с сервисом ssh.

5. Доустановить при необходимости требуемое программное обеспечение (ssh, sshd, putty).

6. Обеспечить доступ по протоколу ssh к своему компьютеру. Предоставить права и пароль для удаленного управления вашим компьютером соседнему - против часовой стрелки - компьютеру.

7. Установить удаленное подключение к удаленному (remote) компьютеру. В качестве Remote выступает соседний по часовой стрелке компьютер. То есть вы должны управлять удаленно правым компьютером, и обеспечить возможность удаленного управления вашим компьютером левому от вас компьютеру.

8. Составить отчет.

Краткие теоретические сведения

1. Протоколы удаленного доступа: telnet и ssh

Операционная система UNIX первоначально разрабатывалась как Интернетсервер. Средства для работы с Сетью встроены непосредственно в ядро этой операционной системы, а все необходимое программное обеспечение для организации сервера входит в состав дистрибутива. UNIX-система работает со всеми сетевыми протоколами (особенно с TCP/IP) лучше, чем любая другая операционная система для платформы Intel. Недаром говорят, что UNIX создан для сети, как птица для полета. Все перечисленные выше качества касаются также и ОС Linux. Существует множество направлений, где используются Linux-серверы: WWW-серверы, FTP-серверы, почтовики, шлюзы. Поэтому удаленное управление Linux-сервером имеет большое значение.

Для удаленного доступа к Linux используются два протокола telnet и SSH. Telnet - протокол линии передачи данных Интернет, который дает возможность

компьютеру функционировать как терминал, работающий под управлением удаленного компьютера. Протокол telnet был первоначально разработан для ARPAnet и является важной частью протокола передачи данных TCP/IP.

Имеются три главных проблемы связанные с использованием telnet, делая его плохим выбором для современных систем с точки зрения безопасности:

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

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

Отсутствие системы аутентификации в telnet не дает никакой гарантии, что связь, установленная между двумя удаленными хостами не будет прервана в середине.

Нежелательно использование протокола telnet в системах, для которых важна безопасность, таких как общественный Интернет. Сеансы telnet не поддерживают шифрование данных. Это означает это любой, кто имеет доступ к любому маршрутизатору, коммутатору или шлюзу в сети между двумя удаленными компьютерами, соединенными

сеансом связи по протоколу telnet, может перехватить проходящие пакеты и легко получить логин и пароль для доступа в систему (или завладеть любой другой информацией, которой обмениваются эти компьютеры) при помощи любой общедоступной утилиты подобно tcpdump и Ethereal.

SSH - (Secure Shell) - сетевой протокол, позволяющий производить удалённое управление компьютером и передачу файлов. Сходен по функциональности с протоколом telnet , однако использует алгоритмы шифрования передаваемой информации.

Недостатки telnet привели к очень быстрому отказу от использования этого протокола в пользу более безопасного и функционального протокола SSH. SSH предоставляет все те функциональные возможности, которые представлялись в telnet, с добавлением эффектного кодирования с целью предотвращения перехвата таких данных, как логины и пароли. Введенная в протоколе SSH система аутентификации с использованием публичного ключа гарантирует, что удаленный компьютер действительно является тем, за кого себя выдает.

Поскольку использование для удаленного управления протокола telnet неправильно с точки зрения безопасности, в лабораторной работе рассмотрим только удаленное управление по SSH.

На данный момент существует две версии протокола SSH: Описание технологии протокола SSH-1:

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

Аутентификация сервера происходит исходя из его возможности расшифровки сессионного ключа, который зашифрован публичным ключом сервера. Аутентификация клиента может происходить различными способами, в том числе DSA, RSA, OpenPGP или

по паролю. Сессия продолжается до тех пор, пока и клиент и сервер способны аутентифицировать друг друга. Установленное соединение по протоколу SSH-1 позволяет защитить передаваемые данные стойким алгоритмом шифрования, проверкой целостности данных и сжатием.

Описание технологии протокола SSH-2:

Оба протокола, по сути, выполняют одни и те же функции, но протокол SSH-2 делает это более элегантно, более безопасно и более гибко. Основное различие между протоколами заключается в том, что протокол SSH-2 разделяет все функции протокола SSH между тремя протоколами, в то время как протокол SSH-1 представляет собой один единый и неделимый протокол. Модуляцией функций протокола SSH в трех протоколах – протоколе транспортного уровня, протоколе аутентификации и протоколе соединения, делает протокол SSH-2 наиболее гибким и мощным механизмом создание безопасных туннелей. Ниже дано краткое описание и назначение каждого из трех протоколов, составляющих протокол SSH-2:

Протокол транспортного уровня – предоставляет возможность шифрования и сжатия передаваемых данных, а также реализует систему контроля целостностью данных.

Протокол соединения – позволяет клиентам устанавливать многопоточное соединение через оригинальный SSH туннель, таким образом, снижая нагрузку, которую создают клиентские процессы.

Протокол аутентификации – протокол аутентификации отделен от протокола транспортного уровня, т.к. не всегда бывает необходимым использование системы аутентификации. В случае если нужна аутентификация, процесс защищается оригинальным безопасным каналом, установленным через протокол транспортного уровня.

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

Сервером SSH служит демон sshd, который запускается на UNIX-машине.

В качестве SSH-клиента в настоящее время используют OpenSSH, PuTTY, SecureCRT, SFTPPlus, TeraTerm и др. В лабораторном практикуме будут использованы наиболее распространенные OpenSSH – для подключение Linux-клиента и PuTTY – для подключения Windows-клиента.

OpenSSH (Open Secure Shell - открытый безопасный shell) - набор программ,

предоставляющих шифрование сеансов связи по компьютерным сетям с использованием протокола SSH. Он был создан под руководством Тео де Раадта как открытая альтернатива коммерческого ПО от SSH Communications Security.

PuTTY (от TTY - телетайп, англ. putty - замазка) - свободно распространяемый клиент для протоколов SSH. Изначально разрабатывался для Windows, однако позднее портирован на Unix.

2. Настройка сервера ssh на сервере

Чтобы служба SSH на сервере начала работать, необходимо запустить на нем демон sshd. Желательно добавить команду запуска в сценарий загрузки системы. Демон sshd работает по 22 порту. Можно запускать его из-под супердемона xinetd/inetd, но обычно sshd запускается самостоятельно - в режиме standalone._

Конфигурационный файл сервера sshd называется /etc/ssh/sshd_config. Справку по его синтаксису можно получить по команде man 5 sshd_config. В пакете openssh-server находится конфигурационный файл с типовыми настройками.

Чтобы оградить ваш компьютер от нежелательных вторжений извне, рекомендуется вписать в конфигурационный файл директиву allowedadress и перечислить через пробел IP-адреса тех машин, с которых разрешен вход клиентов. Например, для рабочей станции ws2 в лаборатории можно разрешить удаленное подключение только с компьютера преподавателя и ближайшего компьютера слева:

allowedadress 192.168.1.100 192.168.1.101

Пример файла конфигурации /etc/ssh/sshd_config:

# Сначала пытаемся работать по протоколу SSH 2, а потом,

# если та сторона не поддерживает вторую версию, - по SSH 1 Protocol 2,1

# Ключ для протокола SSH версии 1 HostKey /etc/openssh/ssh_host_key

# Ключи для протокола SSH2 - RSA и DSA HostKey /etc/openssh/sshjiost_.rsajtey HostKey /etc/openssh/ssh_host_dsa_key

# Время жизни и размер ключа ssh версии 1 KeyRegenerationlnterval 3600

# По умолчанию используется размер 768 бит,установим 1024 ServerKeyBits 1024

# Время, через которое ключи сервера будут созданы заново.

# Периодическая смена ключей повышает безопасность системы.

KeyRegenerationlnterval lh

# Запрещаем регистрацию пользователя root по ssh.

# Это не исключает возможности удаленного

# администрирования: просто root придется зайти под

# обычным пользователем, а затем выполнить команду su.

# Зато злоумышленнику понадобится украсть

# не один, а два пароля: и root, и обычного пользователя.

PermitRootLogin no

# Протоколирование (раскомментируйте, если нужно

# вести журнал с помощью системы syslog) #SyslogFacility AUTH

# Аутентификация

# Включает парольную аутентификацию

# и запрещает пустые пароли

PasswordAuthentication yes PermitEmptyPasswords no

#StrictModes yes

# используем RSА-аутентификацию

RSAAuthentication yes PubkeyAuthentication yes

# Аутентификация rhosts - обычно не используется,

# поэтому запрещаем ее:

# пользовательские файлы -/.rhosts и -/.shosts не будут использоваться

RhostsAuthentication no IgnoreRhosts yes

# НЕ использовать РАМ аутентификацию

PAMAuthenticationViaKbdlnt no

# Дополнительное время клиенту на то, чтобы аутектифицироватьсебя.

# Если за это время клиент не смог ввести пароль,

# соединение будет прекращено

LoginGraceTime 2m

# Путь к баннеру

Banner /some/path

# Подсистема sftp-сервера

Subsystem sftp /usr/libexec/openssh/sftp-server

Ключи, с которыми можно запускать sshd, перечислены в таблице 9.1.

	Табл. 9.1. Ключи сервера sshd.
	Назначение
	Определяет число битов для ключа сервера (по умолчанию 768). Эту опцию
	можно использовать, только если вы используете протокол SSH версии 1
	Режим отладки (DEBUG). В этом режиме сервер не переходит в фоновый
	режим, обрабатывает только одно соединение и подробно протоколирует
	свои действия в системном журнале. Ключ отладки особенно полезен для
	изучения работы сервера.
	Так же, как и при использовании предыдущего ключа, сервер sshd не будет
	переходить в фоновый режим. Однако в отличие от -d ключ -D не переводит

	сервер в режим отладки
	Отравлять отладочные сообщения не в системный журнал, а на стандартный
	поток ошибок
	Задает альтернативный файл конфигурации вместо /etc/ssh/sshd_config
	Предоставляет клиенту, не прошедшему аутентификацию, дополнительное
	время на ввод пароля. Значение 0 интерпретируется как бесконечное
	ожидание
	Задает альтернативный файл открытого ключа (ключ узла). По умолчанию
файл_ключа	используется файл /etc/ssh/ssh_host_key. Этот ключ может понадобиться,
	чтобы запускать sshd от имени непривилегированного пользователя. Также
	ключ -h часто применяется при запуске sshd из сценариев, задающих
	различные настройки в зависимости от времени суток (в рабочее и
	нерабочее время}
	Используется, если нужно запускать sshd через суперсервер xinetd. Обычно
	демон sshd запускается отдельно при загрузке системы. Связано это с тем,
	что демону sshd требуется некоторое время для генерирования ключа
	сервера, прежде чей он сможет ответить на запросы клиентов. При запуске
	через суперсервер при каждом соединении суперсервер будет заново
	вызывать sshd, а тот - заново генерировать ключ. Однако на современных
	компьютерах задержка практически не заметна. Поэтому вполне можно
	запускать sshd и через суперсервер
	Задает время, спустя которое ключ сервера будет создан заново. По
	умолчанию время составляет 1 час. Эту опцию можно использовать только с
	протоколом SSH версии 1
	Указывает альтернативный порт, который демон sshd будет прослушивать
	вместо порта 22
	«Тихий режим»: не протоколировть сессию. Обычно протоколируется
	начало аутентификации, результат аутентификации и время окончания
	Тестовый режим. Применяется для проверки корректности файла
	конфигурации
	Разрешается использовать IP-адреса только в формате IPv4
	Разрешается использовать IP-адреса только в формате IPv6
		Удаленный доступ с Linux-клиента

Запустим сервер с CentOS Linux. Командой ps (process status) c ключами С (by command name) и l (long format) проверим, запущен ли демон sshd, а командой ifconfig

проверим адрес сервера (рис.7.1).

Рис. 9.1. Проверка загрузки службы sshd и IP-адреса сервера Видим, что процесс sshd запущен. Родительским для него является процесс

инициализации с идентификатором 1. IP-адрес сервера равен, как было задано при установке, 192.168.100.3.

Загружаем клиентскую машину с Alt Linux Lite. Запускаем на ней терминал и проверяем связь с сервером - набираем команду ping 192.168.100.3. Как видно из рис. 9.2 установить соединение с сервером сразу после загрузки не удается.

Рис. 9.2. Проверка связи с Linux-сервером

Требуется настройка IP-протокола. Выбираем (см. рис. 7.3) Настройка - Центр управления системы – Сеть, вводим IP-адрес 192.168.100.4 и нажимаем кнопку «Применить».

Рис. 9.3. Настройка IP-интерфейса на Linux-клиенте

Снова проверяем возможность установления связи с сервером. Как видно из рис. 9.4 теперь клиент «видит» сервер.

Рис. 9.4. После включения клиента в сеть 192.168.100 соединение установлено Поскольку настройка при загрузке с Live-CD не сохраняется, задавать IP-адрес

клиенту надо при каждой загрузке Alt Linux c Live-CD. Теперь пробуем подключиться удаленно к серверу.

Клиентская программа ssh может запускаться с многочисленными ключами, формат ее запуска в общем случае следующий:.

ssh [ключи] [ключи_с_аргументами] [логин_имя@]хост.домен [команда]

Мы будем использовать ключ l , с помощью которого можно указать, от имени какого пользователя будет осуществляться регистрации на удаленной машине, и ключ v , который включает отображение всей отладочной информации. Набираем команду ssh с адресом сервера и этими ключами. Как видно из этого рисунка, клиент и сервер обменялись информацией о том, какие версии протоколов они поддерживают (OpenSHH_4.7p1 на клиентской стороне и OpenSHH_4.3 на сервере), сервер прислал открытый RSA ключ и программа запрашивает от пользователя подтверждение на включение сервера в список известных хостов.

Рис. 9.5. Получение открытого ключа для шифрования данных от сервера.

Это важное свойство протокола SSH. Он разработан чтобы защитить пользователя против атак известных как спуфинг или «злоумышленник посередине». Одна из проблем, связанная со старыми протоколами типа Telnet, FTP, RSH и др. кроме того, что они передают всю информацию открытым текстом, состоит в том, что данные протоколы уязвимы к атаке подобного рода. Атакующий, имеющий доступ к промежуточной сети,

может перехватить ваши пакеты, сохранить их, а затем отослать непосредственному адресату. Еще хуже, он может перезаписать ваши пакеты, например, заменив ls -la mydir на rm -r mydir (удаление вместо просмотра) или отправить вам протрояненный файл вместо оригинала через ваш перехваченный FTP сеанс. Атакующий может, наконец, просто перенаправить ваше соединение к другому компьютеру, так что вы пошлете ваш пароль другой машине. Используя этот прием, атакующий сможет узнать пароль, который защищает вашу учетную запись, и сможет затем регистрироваться под вашим именем для своих целей.

SSH предоставляет возможность подтверждения подлинности хоста, с которым вы соединяетесь. Если вы правильно верифицировали хост, не существует способов чтения или манипуляции вашими пакетами промежуточным устройством. Успешная верификация хоста показывает, что соединение зашифровано от начала до конца - ваш SSH клиент установил безопасное соединение непосредственно с SSH сервером, и никакие промежуточные машины не имеют доступа к этому соединению.

Так как мы подключаемся к этой машине впервые, и SSH не работает по принципу третьего доверенного лица, такого как Certificate Authorities, вся работа, связанная с управлением ключами, лежит на вас. Ваш клиент показывает отпечаток открытого ключа (key fingerprint), простую для чтения строку чисел, которую вы можете использовать для проверки ключа вручную. Если вы отвечаете "Да, отпечаток правильный", ваш SSH клиент продолжит аутентификацию, дав вам возможность ввести ваш пароль и приступить к работе.

Как вы узнаете, что получили правильный ключ? Ведь если во время соединения с сервером атакующий перехватил ваше SSH соединение и пропустил через себя весь трафик, он может подсунуть вам свой ключ, вместо реального открытого ключа хоста. Существует несколько способов проверки подлинности ключа. Например, владелец системы может разместить отпечаток ключа на своей защищенной веб странице. Другой вариант - вы можете позвонить системному администратору хоста и проверить ключ по телефону (если исключена возможность перехвата злоумышленником телефонного разговора).

Подтверждаем продолжение соединения, набрав yes, и получаем от программы сообщение о том, что сервер включен в список известных хостов (рис. 9.6).

Рис. 9.6. Проверка RSA

Когда вы ответили "да", наш SSH клиент сохранил ключ сервера в файле known_hosts, который фактически является вашим личным Certificate Authority - списком ключей всех SSH серверов, с которыми вы работаете.

Теперь можно удаленно подключиться к серверу. Повторяем команду ssh 192.168.100.3 –l root –v

и получаем информацию об установлении соединения (рис. 9.7), где последней стадией аутентификации выступает ввод пароля пользователя root удаленного компьютера-сервера.

Рис. 9.7. Отладочная информация удаленного подключения Вводим пароль пользователя root сервера (рис. 9.8) и входим в сессию удаленного управления.

Рис. 9.8. Процедура удаленного подключения после ввода пароля Теперь можно удаленно управлять сервером. Можно, например, его удаленно перезагрузить, выполнив команду reboot, как показано на следующем рис.9.9.

На этом рисунке видно, что сразу после команды reboot установить заново удаленное подключение не удается – сервер еще не загрузился. После установления соединения команда ps показывает, что на сервере выполняются два пользовательских процесса – оболочка bash и собственно команда ps. Оба процесса запущены с удаленной консоли pts/0.

Завершаем удаленный сеанс командой logout.

Разработанная лабораторная установка позволяет в деталях изучать удаленное управление Linux-сервером. Настройка SSH на сервере может производиться с использованием конфигурационного файла sshd_config. Справку по его синтаксису пользователь может получить по команде man sshd_config. В пакете openssh-server находится конфигурационный файл с типовыми настройками.

4. Удаленный доступ с Windows-клиента

Встроенные клиенты SSH есть не у всех операционных систем, у UNIX - есть, у Windows - нет. Под Windows можно поставить SSH клиента - PuTTY, (официальный сервер http://www.chiark.greenend.org.uk/~sgtatham/putty/). Состав используемого дистрибутив а

PuTTY показан на рис. 9.10.

Рис.9.10. Состав дистрибутива PuTTY.

Putty это несколько отдельных программ, предназначенных для работы с unixсервером по протоколам SSH1, SSH2, Telnet, Rlogin, Raw. Программа работает на Windows для Intel x86 и Alpha, а также на UNIX. Показанный на рис. 9.11 полный комплект программ, под общим названием PuTTY, состоит из следующих утилит:

- putty.hlp – файл справки;

- putty.exe - клиент для соединения с сервером по протоколам telnet, ssh, raw, rlogin;

- puttygen.exe - генератор rsa/dsa ключей;

- pageant.exe - агент аутендификации, хранит ключи в памяти, при его использовании не нужно руками вводить ключевую парольную фразу;

- plink.exe - интерфейс командной строки для putty;

- pscp.exe - безопасное копирование файлов;

- psftp.exe - безопасный ftp клиент для копирования, просмотра, переименования файлов и т.д.

Устанавливать putty необязательно, можно просто скопировать файлы в нужную директорию.

Запускаем putty.exe и создаем профиль с настройками для нашего удалённого сервера. В PuTTY можно создавать профили для различных SSH серверов, так что Вам не придётся вбивать настройки для конкретного сервера, когда Вы захотите к нему очередной раз подсоединиться. Сейчас мы находимся в категории Sessions (см. дерево слева на рис. 9.11). Вводим адрес хоста 192.168.100.3 в строку Host Name (or IP adress) , оставляем предлагаемые по умолчанию номер порта (22) и Protocol (SSH). П од надписью Saved Sessions (сохранённые сессии) вводим имя профиля, например, Session with CentOS , которое поможет вспомнить, к какому серверу относится этот профиль.

Рис.9.11. Создание профиля с настройками в PuTTY

Затем идем в категорию Connection -> Data и указываем в Auto-login username (см. рис. 9.12) имя пользователя, под которым будем подключаться к SSH серверу – root.

Рис.9.12. Задаем имя пользователя удаленного хоста

Теперь возвращаемся в категорию Sessions, сохраняем профиль, нажав Save. В следующий раз, когда Вы запустите PuTTY, просто выберите подходящий профиль из

Saved Sessions, кликните Load и Open.

Теперь мы можем подсоединиться к нашему SSH серверу, просто кликнув Open . При первом соединении этого клиента, появляется (см. рис. 9.13) предупреждение об

угрозе безопасности, аналогичное сообщению, показанному на рис. 9.5. Это происходит потому, что PuTTY ещё не известен открытый ключ хоста сервера. PuTTY записывает ключ хоста для каждого сервера, к которому вы присоединяетесь, в регистр Windows. Каждый раз, когда вы присоединяетесь к серверу, она проверяет, что ключ хоста предоставленный сервером, есть тот же самый ключ, что был в последнем соединении. Если это не так, вы получите предупреждение и будете иметь возможность оборвать ваше соединение, прежде чем вы наберете какую-либо приватную информацию (такую как пароль). Поскольку мы подключаемся к серверу по протоколу SSH, то к этому соединению относится все сказанное в предыдущем выше относительно проверки открытого ключа сервера для подключения Linux-клиента.

В нашем случае сомнения в подлинности сервера отсутствуют - нажимаем кнопку

Рис. 9.13. Предупреждение PuTTY при первом подключении к удаленному хосту

Поскольку мы сохранили имя, под которым соединяемся, в настройках профиля, нам не нужно вбивать его снова, мы только укажем пароль пользователя (рис. 9.14).

Рис. 9.14. Сеанс удаленного управления сервером

Удаленное соединение установлено. На рис. 9.14 показано выполнение нескольких команд на удаленном Linux-сервере и затем – удаленная перезагрузка сервера. После перезагрузки сессия становится неактивной. Ее следует закрыть и снова подключиться к серверу, когда он загрузится.

Был рассмотрен наиболее распространенный способ соединения - с парольной идентификацией. Если кто-нибудь узнает имя и пароль, он тоже сможет соединиться. Поэтому если у Вас простой пароль и/или Вы стали жертвой атаки с прямым перебором, могут быть проблемы. В качестве альтернативы можно использовать способ Аутентификации самого пользователя с использованием шифрования с открытым ключом. Вы можете использовать PuTTYgen для изготовления пары закрытого и открытого ключей. Затем открытый ключ надо будет передать серверу, а закрытый ключ прикрепить к профилю PuTTY. Эти процедуры подробно описаны в руководстве putty.hlp.

Таким образом, разработанная лабораторная установка позволяет в деталях изучать удаленное управление Linux-сервером с Winows-клиента.

Порядок выполнения работы:

1) Проверить, запущен ли супер-сервер xinetd. Если не запущен – доустановить супер-

сервер из пакета xinetd-2.3.14-10.el5.i386.rpm. (/usr/sbin)

2) Проверить, используя команду find, наличие и месторасположение ssh-сервера shhd. Если sshd не установлен – доустановить из пакетов

openssh-4.3p2-16.el5.i386.rpm, openssh-askpass-4.3p2-16.el5.i386.rpm; openssh-server-4.3p2-16.el5.i386.rpm. (usr/sbin)

Может рассматриваться как акт агрессии, но иногда он просто необходим.

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

Опытные пользователи Unix-систем часто говорят о SSH и командной строке, как об инструментах получения доступа к графическому рабочему столу, но существуют отдельные приложения для данной цели.

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

Исследователи придерживались принципа справедливой оценки различных протоколов. Например, NoMachine NX поддерживает подключения VNC, но он проверялся в связке с собственным сервером NX, что вполне разумно.

Клиент TightVNC не тестировался, потому что он очень схож с реализацией TigerVNC. Оба продукта имеют одинаковую кодовую базу, но TigerVNC имеет несколько дополнительных функций.

Как проходило тестирование

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

При тестировании проверялась способность удаленно воспроизводить игру Armegatron. В этой нетребовательная игре на OpenGL на обновление экрана требуются доли секунд времени. Результаты могут быть несколько субъективны, но данный способ оказался очень действенным при демонстрации отзывчивости клиентов.

Клиенты были протестированы совместно с локальным компьютером с 4-х ядерным процессором и 16 гигабайтами памяти в гигабитной локальной сети под Ubuntu 14.04.3. В качестве серверов использовался сервер X11 VNC и официальный сервер NX для клиентов NX. Функциональность на базе протокола RDP поддерживается некоторыми продуктами, но на практике не была протестирована.

Сами клиенты работали на виртуальной машине с 2-х ядерным процессом Core i7, 4Гб ОЗУ и Fedora 23.