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

УДАЛЁННЫЙ ДОСТУП В LINUX

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

В соответствии с рабочей программой по дисциплине «Операционные системы» в результате

 

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

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

Средства для работы с Сетью встроены непосредственно в ядро этой операционной системы, а все необходимое программное обеспечение для организации сервера входит в состав дистрибутива. 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.

Настройка сервера 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:

Port 22

# Сначала пытаемся работать по протоколу 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

#LogLevel INFO

 

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

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

# и запрещает пустые пароли 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.

 

Табл. 1. Ключи сервера sshd

 

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

 

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

 

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

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

Рис. 1. Проверка загрузки службы sshd и IP-адреса сервера

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

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

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

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

«Применить».

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

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

теперь клиент «видит» сервер.

 

Рис. 4. После включения клиента в сеть 192.168.100 соединение установлено

 

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

клиенту надо при каждой загрузке Alt Linux c Live-CD.

Теперь пробуем подключиться удаленно к серверу.

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

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

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

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

 

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

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

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

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

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

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

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

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

Теперь можно удаленно подключиться к серверу. Повторяем команду

ssh 192.168.100.3 –l root –v

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

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

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

Рис. 9. Удаленная перезагрузка сервера

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

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

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

Удалённый доступ к серверу по протоколу SSH (посредством openssh).

SSH (англ. Secure Shell — «безопасная оболочка») — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов).