Secure Shell (SSH) – это протокол, обеспечивающий безопасную работу различных сетевых сервисов (таких как login) на незащищенной сети. Он состоит из трех подпротоколов.
Протокол транспортного уровня (SSH-TRANS) обеспечивает аутентификацию сервера, конфиденциальность и целостность данных. Опционально может производить компрессию данных. Обычно работает поверх TCP/IP, но может быть использован и с любым надежным потоком данных (8-битовый двоичный транспорт с коррекцией ошибок).
Протокол соединения (SSH-CONN)совмещает (мультиплексирует) различные логические каналы в единый шифрованный канал. Функционирует поверх протокола аутентификации пользователя.
Рассмотрим общую архитектуру протокола и коснемся трех его составляющих. Одним из наиболее важных элементов схемы является требование аутентификации, которая производится на основе алгоритмов шифрования с открытым ключом. Это означает, что каждый участник взаимодействия (хост) должен иметь соответствующий ключ. Модель протокола допускает как вариант, когда один хост имеет множество ключей, так и вариант, когда множество хостов пользуются одним ключом. Для каждого из используемых алгоритмов хост должен иметь отдельный ключ (в качестве стандартного указан алгоритм DSS – Digital Signature Standard).
Ключ сервера используется для обеспечения уверенности клиента, что он работает с соответствующим сервером. Для этого клиент должен иметь некоторые предварительные знания о ключе сервера. Протокол допускает существование двух различных моделей обеспечения клиента такой информацией.
– Децентрализованная. Клиент имеет базу данных открытых ключей. Преимущество модели в том, что она не требует инфраструктуры централизованного администрирования, недостаток – в том, что поддержание локальной базы данных требует дополнительных затрат.
– Централизованная. Присутствует доверенная сторона СА (certification authority), которая производит подтверждение ассоциации хост/открытый ключ для каждого ключа, полученного клиентом. Таким образом, клиенту достаточно хранить только ключ самого СА. С другой стороны, до начала взаимодействия, каждый сервер должен быть сертифицирован СА. Теоретически допускается в качестве опции протокола возможность использования первой сессии с хостом без подтвержденной ассоциации хост/ключ, однако указывается, что такая возможность уязвима с точки зрения безопасности для атаки класса злоумышленник-посередине (англ. man-in-the-middle).
Допускаются альтернативные методы подтверждения корректности соответствия ключа хосту, например, вычисление 16-ричного значения хэш-функции открытого ключа (указан алгоритм SHA-1 Secure Hash Algorithm) и далее передача его для верификации внешними каналами связи (например, по телефону).
Для конкретной реализации протокола необходимо учитывать ряд требований.
–Алгоритмы шифрования, контроля целостности и сжатия должны быть отдельными для каждого из направлений, при этом должен быть определен предпочтительный алгоритм (первый из указанного в списке для каждой категории).
–Для аутентификации хоста должны использоваться алгоритмы с открытым ключом и методы защищенного обмена ключами.
–Сервер должен требовать аутентификации для каждого пользователя. Для некоторых или всех пользователей сервер может требовать множественную аутентификацию. При этом требуемые сервером алгоритмы аутентификации могут зависеть от месторасположения, откуда пользователь пытается получить доступ.
–Операции, которые разрешены пользователю к выполнению, определяются протоколом соединения. Должны быть ясно определены допущения в работе, например, такие как запрет серверу инициировать сессии или исполнять команды на клиентской машине, а также установка соединения до его запроса клиентом. Кроме того, необходимо определить, кто и какие TCP-порты может запрашивать для соединения. Также необходимо учитывать, что соединение может проходить через межсетевой экран и пересекаться с его собственной политикой.
–Алгоритмы шифрования, поддержания целостности и открытых ключей должны быть известны и проверены, длины ключей обеспечивать устойчивость к криптоанализу. Алгоритмы должны согласовываться, так чтобы в случае взлома одного можно было перейти на другой без модификации основного протокола.
Сетевые адреса отображаются в виде строк, DNS-имена не используются, так как протокол DNS не обеспечивает необходимой безопасности, если в адресе встречается двоеточие (:), он интерпретируется, как IPv6.
Для использования в протоколе обозначений различных алгоритмов шифрования, хэширования, сжатия и пр., применяются идентификаторы алгоритмов в виде строк размером до 64 знаков с учетом регистров. Эти идентификаторы или имена могут быть в двух форматах.
Имена, не содержащие символы @ и запятую, – это зарезервированные обозначения института IANA (Internet Assigned Numbers Authority) , такие как (без учета кавычек): "3des-cbc", "sha-1", "hmac-shal". Сюда входят наименования для алгоритмов шифрования, алгоритмов контроля целостности (message authentication control – MAC), алгоритмов с открытым ключом, методов обмена ключами и имен сервисов/протоколов.
Возможно определение дополнительных алгоритмов, используя имена для них в формате name@domain,где domain – это полностью обозначенное доменное имя (Full Qualified Domain Name – FQDN).
SSH использует нумерацию сообщений от 1 до 255, распределенные следующим образом.
1–19 Характеристики протокола транспортного уровня (disconnect, ignore, debug и т. п.).
20–29 Согласование алгоритмов.
30–49 Специфики способов обмена ключами.
50–59 Характеристики протокола аутентификации пользователя.
60–79 Специфики методов аутентификации пользователя.
80–89 Характеристики протокола соединения.
90–127 Сообщения, связанные с работой канала.
128–191 Зарезервированные для клиентских протоколов.
192–255 Локальные расширения (для особенностей реализации). Рассмотрим некоторые особенности подпротоколов.
Подпротокол транспортного уровня
Протокол обеспечивает аутентификацию только сервера, но не клиента, использует зарегистрированный TCP порт 22. Протокол применяет следующие методы (табл. 22.3).
Подпротокол аутентификации
Цель протокола – произвести аутентификацию клиента. Предполагается, что он будет работать поверх протокола транспортного уровня, который уже произвел аутентификацию сервера, установил шифрованное соединение и определил идентификатор сессии.
Для усложнения возможных атак перебора ключей аутентификации, сервер может временно блокировать свою работу после нескольких неудачных попыток аутентификации. Если при работе транспортного уровня была выбрана нерекомендованная опция работы без шифрования, тогда аутентификационные методы, основанные на передаче секретных данных, должны быть блокированы. Кроме того, если отсутствует контроль целостности, необходимо отключить возможность изменения аутентификационных данных, таких как пароль, так как это может привести к отказу в работе сервиса (атака класса deny-of-service), если атакующий изменит шифрованный поток данных.
Сервер управляет аутентификацией, указывая клиенту, какие виды аутентификации необходимы в какой период времени. Клиенту предоставляется возможность выбора из списка методов аутентификации сервера. Таким образом, с одной стороны, сервер контролирует аутентификационные методы, с другой – дает клиенту возможность выбрать поддерживаемый им метод.
Метод попе (без аутентификации) зарезервирован, но не должен предлагаться сервером в качестве допустимых методов аутентификации. Клиент может предложить этот метод серверу, но сервер должен отказать в нем, если только он не предоставляет возможности работы без аутентификации. В основном цель такого запроса клиента – это получение списка методов аутентификации от сервера. Если после отправления списка методов сервером клиент не отвечает, сервер должен иметь возможность разрыва соединения по таймауту (рекомендуемый период – 10 минут).
Подпротокол соединения
Предполагается, что протокол функционирует поверх транспорта, обеспечивающего безопасность путем шифрования, контроля целостности и аутентификации. Протокол используется для выполнения команд на удаленной машине, а также может быть использован сервером для запуска команд на исполнение на клиентской станции (это может быть запрещено в отдельных реализациях для снижения уровня риска атаки). Протокол подробно описывает форматы различных сообщений о выполнении команд, таких как открытие и закрытие канала, передача данных, продвижение (forwarding) и т. п.
