Network Working Group                                                                                           T. Ylonen
Request for Comments: 4251                              SSH Communications Security Corp
Category: Standards Track                                                                     C. Lonvick, Ed.
Cisco Systems, Inc. January 2006
Архитектура протокола SSH
The Secure Shell (SSH) Protocol Architecture
Статус документа
В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений.
Авторские права
Copyright (C) The Internet Society (2006).
Тезисы
Протокол SSH1 используется для организации безопасного входа в удаленную систему (login) и организации иных безопасных служб через сети, не обеспечивающие безопасности. В данном документе описана архитектура протокола SSH, а также нотация и терминология, используемые в документах, посвященных протоколу SSH. Описывается также алгоритм именования SSH, поддер­живающий локализованные расширения. Протокол SSH состоит из трех основных компонент. Протокол транспортного уровня (Transport Layer Protocol) обеспечивает аутентификацию серверов, конфиденциальность и целостность и высоким уровнем защи­щенности. Протокол аутентификации пользователей (User Authentication Protocol) используется на серверах для проверки полно­мочий клиентов. Протокол соединений (Connection Protocol) обеспечивает мультиплексирование шифрованного туннеля в несколько логических каналов. Детальные описания каждого из этих протоколов содержатся в отдельных документах.
Оглавление
1. Введение ................................................................................................................................................................................. .... ..................... 2
2. Разработчики ................................................................................................................................................................................................ 2...
3. Используемые в документе соглашения .................................................................................................................................................. 2....
4. Архитектура ........................................................................................................................................................................... ..... .... ................ 2
4.1. Ключи хостов ................................................................................................................................................................. ..................... 2
4.2. Возможности расширения ................................................................................................................................................... ...... .. ....... 3
4.3. Политика ........................................................................................................................................................................ ...................... 3
4.4. Параметры безопасности ................................................................................................................................................... ..... .. .......... 3
4.5. Локализация и поддержка различных наборов символов ....................................................................................................... ........4
5. Представление типов данных, используемых в протоколах SSH ........................................................................................................ .4...
6. Имена алгоритмов и методов .............................................................................................................................................................. ....... 5
7. Номера сообщений .......................................................................................................................................................................... ..... .... ..... 5
8. Согласование с IANA ....................................................................................................................................................... ..... ........................ 5
9. Вопросы безопасности .......................................................................................................................................................... .... .................... 6
9.1. Генерация псевдослучайных чисел .................................................................................................................................................. 6...
9.2. Фильтрация управляющих символов ........................................................................................................................................ ...... 6
9.3. Транспорт ..................................................................................................................................................................................... ........ 6
9.3.1. Конфиденциальность .................................................................................................................................................. .............. 6
9.3.2. Целостность данных ............................................................................................................................................................. ......7. .
9.3.3. Использование перехваченных данных (Replay) .............................................................................................................. .....8
9.3.4. Перехват с участием человека (Man-in-the-middle) .............................................................................................................. 8
9.3.5.  DoS-атаки ............................................................................................................................................................. .. ..................... 9
9.3.6. Скрытые каналы ............................................................................................................................................................... ........ 9
9.3.7. Сохранность тайн .......................................................................................................................................................... .... ......... 9
9.3.8. Упорядочивание методов обмена ключами .......................................................................................................................... 9...
9.3.9. Анализ трафика ................................................................................................................................................... ..... .... ................ 9
9.4. Протокол аутентификации ......................................................................................................................................................... .... ..... 9
9.4.1. Проблема небезопасного транспорта ................................................................................................................................... ....9...
9.4.2. Отладочные сообщения ......................................................................................................................................................... 10
9.4.3. Локальная политика безопасности ............................................................................................................................. .......... 10
9.4.4 Аутентификация с использованием открытых ключей .......................................................................................... ............ 10
9.4.5. Парольная аутентификация .................................................................................................................................. .... ............... 10
9.4.6. Аутентификация по хостам ........................................................................................................................................... ........ 10
9.5. Протокол соединений ................................................................................................................................................................. .....1. .0
9.5.1. Безопасность конечных точек ........................................................................................................................... ..................... 10
9.5.2. Перенаправление ................................................................................................................................................ ..................... 10
1Secure Shell
rfc.com.ru
rfc.com.ru
Перевод RFC 4251
9.5.3. Перенаправление трафика X11..................................................................................................................................................11
10. Литература...................................................................................................................................................................................................11
10.1. Нормативные документы.................................................................................................................................................................11
10.2.  Дополнительная литература.........................................................................................................................................................11
Адреса авторов.................................................................................................................................................................................................12
Торговые марки..............................................................................................................................................................................................12
1. Введение
Протокол SSH используется для организации безопасного входа в удаленную систему (login) и организации иных безопасных служб через сети, не обеспечивающие безопасности. Протокол включает три основных компоненты:
♦    Протокол транспортного уровня [SSH-TRANS] обеспечивает аутентификацию серверов, конфиденциальность и целостность. Этот протокол может также обеспечивать сжатие информации. Транспортный уровень работает в основном с использованием соединений TCP/IP, но может быть реализован и на базе иных потоков данных с гарантированной доставкой.
♦    Протокол аутентификации пользователей [SSH-USERAUTH] используется на серверах для проверки полномочий клиентов. Этот протокол работает на основе протокола транспортного уровня.
♦    Протокол соединений [SSH-CONNECT] обеспечивает мультиплексирование шифрованного туннеля в несколько логических каналов и работает поверх протокола аутентификации пользователей.
Клиент передает один запрос на обслуживание в процессе организации защищенного соединения на транспортном уровне. Дру­гой запрос на обслуживание передается после успешной проверки полномочий клиента. Такое решение обеспечивает возмож­ность создания новых протоколов и их совместного использования с перечисленными выше протоколами.
Протокол соединений обеспечивает каналы, которые могут использоваться для решения целого ряда задач. Обеспечиваются стан­дартные методы для организации защищенных shell-сессий и перенаправления (“туннелирования”) произвольных портов TCP/IP и соединений X11.
2. Разработчики
Основными разработчиками этого комплекта документов являются: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (все из SSH Communications Security Corp) и Markku-Juhani O. Saarinen (университет Jyvaskyla). Darren Moffat был редактором этого комплекта документов и внес важный вклад в работу.
За годы подготовки этого документа множество людей внесло свой вклад. В их число входят: Mats Andersson, Ben Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller, Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse и Tadayoshi Kohno. Указанные в списке люди могли не участвовать в написании данного документа, но они внесли свой вклад в его подготовку.
3. Используемые в документе соглашения
Во всех документах, связанных с протоколом SSH, следует использовать ключевые слова: необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) для описания уровня требования. Интерпрета-ция этих слов описана в [RFC2119].
Ключевые слова приватное использование (PRIVATE USE), иерархическое выделение (HIERARCHICAL ALLOCATION), выде­ление в соответствии с порядком запросов (FIRST COME FIRST SERVED), экспертное рассмотрение (EXPERT REVIEW), тре­буется спецификация (SPECIFICATION REQUIRED), одобрение IESG (IESG APPROVAL), согласование с IETF (IETF CONSENSUS), стандартизация (STANDARDS ACTION) в данном документе при их использовании в контексте распределения пространства имен интерпретируются в соответствии с [RFC2434].
В данном наборе документов определяются поля протокола и возможные значения этих полей. Поля будут определяться в опреде­лениях протокольных сообщений. Например, поле SSH_MSG_CHANNEL_DATA определяется следующим образом.
byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel (канал получателя)
string data (данные)
В данном документе поля протокола будут указываться в одинарных кавычках, а значения полей - в двойных. В приведенном выше примере поле 'data' может содержать значения "foo" и "bar".
4. Архитектура 4.1. Ключи хостов
Каждому серверному хосту следует иметь ключ (host key). Хосты могут иметь множество ключей, созданных с использованием различных алгоритмов. Возможно использование одного ключа множеством хостов. Если хост имеет ключи, он должен обеспечи­вать по крайней мере один ключ, который использует каждый из требуемых алгоритмов открытых ключей (DSS [FIPS-186-2]).
Ключ сервера используется в процессе обмена ключами для подтверждения того, что клиент реально связывается с нужным сер­вером. Для того, чтобы такая проверка стала возможной, клиент должен заранее знать открытый ключ сервера.
Могут использоваться две модели поддержки ключей:
♦    Клиент поддерживает локальную базу данных, в которой содержатся имена всех хостов (указанные пользователем) и соответ­ствующие открытые ключи. Этот метод не требует создания инфраструктуры централизованного управления или сторонней координации. Недостатком данного метода является трудоемкость поддержки ассоциаций между ключами и именами хостов.
♦    Ассоциации между ключами и хостами сертифицируются специальным агентством CA2. Клиент знает только ключ корневого
2certification authority – агентство по сертификации
rfc.com.ru                                                                                     2                                                            rfc.com.ru
Перевод RFC 4251
CA и может проверить все ключи хостов, сертифицированные приемлемыми агентствами CA.
Второй вариант упрощает задачу поддержки, поскольку клиенту нужно хранить единственный ключ CA. С другой стороны, в этом варианте требуется централизованная сертификация каждого хоста прежде, чем станет возможной процедура проверки пол­номочий. Кроме того требуется обеспечить высокий уровень для централизованной инфраструктуры сертификации.
Протокол позволяет отключить проверку ассоциации “сервер - ключ” при первом подключении к хосту. Это позволяет организо­вать соединение с хостом до получения от него ключа или сертификации хоста. При таком соединении обеспечивается защита от пассивного прослушивания, но существует уязвимость для активного перехвата с участием человека3. Реализациям в общем слу­чае не следует разрешать такие соединения по умолчанию, поскольку они могут снижать уровень безопасности. Однако по причи­не отсутствия в сети Internet широко доступной структуры обмена ключами на момент написания документа эта опция может ока­заться весьма полезной в переходный период, пока такая инфраструктура не будет создана, и обеспечит значительно более высо­кий уровень безопасности, нежели более старые решения (например, telnet [RFC0854] и rlogin [RFC1282]).
Реализациям протокола следует предпринимать разумные меры по проверке ключей хостов. Примером возможной стратегии мо­жет служить принятие ключа без проверки только при первом соединении с хостом, сохранение полученного ключа в локальной базе данных и его использование при каждом последующем подключении к данному хосту.
Реализации могут обеспечивать дополнительные возможности по проверке корректности ключей хостов (например, использова­ние шестнадцатеричных “отпечатков”, полученных хэша открытого ключа с помощью алгоритма SHA-1 [FIPS-180-2]). Такие “от­печатки” можно легко проверить по телефону или с использованием другого коммуникационного канала.
Всем реализациям следует обеспечивать опцию для запрета принятия непроверенных ключей хостов.
Члены рабочей группы полагают, что простота использования играет важную роль при выборе безопасных решений конечными пользователями и уровень безопасности не станет выше, если не будут применяться новые решения. Таким образом можно пред­полагать, что обеспечение опции, позволяющей отказаться от проверки ключа, будет повышать общий уровень безопасности в сети Internet, несмотря на локальное снижение уровня безопасности протокола в тех случаях, когда проверка отключена.
4.2. Возможности расширения
Мы полагаем, что протокол будет использоваться достаточно долго и некоторые организации захотят использовать свои методы шифрования, аутентификации и обмена ключами. Централизованная регистрация всех расширений весьма обременительна, осо­бенно для экспериментальных или засекреченных вариантов. С другой стороны, отсутствие централизованной регистрации будет приводить к конфликтам с идентификацией методов, осложняющим взаимодействие реализаций протокола.
Мы выбрали вариант идентификации алгоритмов, методов, форматов и расширений протокола с помощью текстовых имен, ис­пользующих определенный формат. Имена DNS используются для создания локальных пространств имен, где могут определяться экспериментальные или засекреченные расширения без возникновения конфликтов с другими реализациями.
Одной из задач является обеспечение максимальной простоты базового протокола и использование минимального числа алгорит­мов. Однако все реализации должны поддерживать минимальный набор алгоритмов для обеспечения интероперабельности (это не означает, что локальная политика на каждом хосте должна обеспечивать поддержку этих алгоритмов). Обязательные алгорит­мы указываются в соответствующих протокольных документах.
Дополнительные алгоритмы, методы, форматы и протоколы расширения могут определяться в отдельных документах. Дополни­тельная информация по этому вопросу содержится в разделе 6 (Алгоритм и метод именования).
4.3. Политика
Протокол допускает полное согласование алгоритмов и форматов шифрования, обеспечения целостности, обмена ключами, сжа­тия данных и открытых ключей. Алгоритмы шифрования, обеспечения целостности, сжатия и открытых ключей могут отличаться для каждого из направлений.
Приведенные ниже правила следует использовать в механизмах настройки конфигурационных параметров каждой реализации:
♦    Алгоритмы шифрования, обеспечения целостности и сжатия данных задаются раздельно для каждого направления. Политика должна задавать предпочтительный алгоритм (например, перевый алгоритм из списка для каждой категории).
♦    Алгоритм открытых ключей и метод обмена ключами, используемые для аутентификации хоста. Существование доверенных ключей хостов для различных алгоритмов открытых ключей также должно приниматься во внимание.
♦    Методы аутентификации, требуемые сервером от каждого пользователя. Политика сервера может требовать несколько мето­дов аутентификации для некоторых или всех пользователей. Набор обязательных алгоритмов может зависеть от местонахо­ждения пользователя, пытающегося получить доступ.
♦    Операции, которые пользователю дозволено выполнять с применением протокола соединений. Некоторые аспекты политики могут быть связаны с безопасностью - например, не следует позволять серверу инициировать сессии или выполнять команды на клиентской машине и недопустимо разрешать соединения с агентом аутентификации, если не запрошено перенаправление таких соединений. Иные аспекты (такие, как возможность и назначение перенаправления портов TCP/IP) определяются ло­кальной политикой. Многие из таких аспектов могут быть связаны с прохождением или обходом межсетевых экранов и в той или иной степени связаны с локальной политикой безопасности.
4.4. Параметры безопасности
Основной задачей протокола SSH является повышение уровня безопасности в Internet. Протокол пытается сделать это обеспече­нием максимальной простоты даже за счет некоторого снижения уровня безопасности.
♦    Все алгоритмы шифрования, обеспечения целостности и открытых ключей относятся к числу известных и проверенных.
♦    Все алгоритмы используются с криптографически обоснованным размером ключей, который позволяет надеяться на обеспече­ние защиты от самых мощных криптоаналитических атак в течение десятилетий.
3active man-in-the-middle attack
rfc.com.ru                                                                          3                                                                        rfc.com.ru
Перевод RFC 4251
♦ Все алгоритмы согласуются и в тех случаях, когда тот или иной алгоритм не поддерживается, обеспечивается простой переход к использованию другого алгоритма без изменения базового протокола.
Будут предприниматься специальные меры для того, чтобы упростить широкое и быстрое развертывание протокола. Частным слу­чаем таких мер является возможность работы протокола без проверки ключа хоста при первом подключении, однако такая мера не рекомендуется. Предполагается, что принимаемые меры помогут значительно расширить использование протокола в короткие сроки, пока не будет широко развернута инфраструктура обмена открытыми ключами в сети Internet.
4.5. Локализация и поддержка различных наборов символов
В большинстве случаев протоколы SSH не будут непосредственно передавать текст, отображаемый пользователю. Однако в неко­торых случаях такие данные могут передаваться. В тех случаях, когда это применимо, набор символов для данных должен указы­ваться явно. В большинстве случаев используется кодировка ISO-10646 UTF-8 [RFC3629]. В тех случаях, когда это применимо, обеспечивается также поле для тега языка [RFC3066].
Достаточно сложным является вопрос выбора набора символов для интерактивных сессий. Здесь нет очевидного решения, по­скольку разные приложения могут отображать данные в различных форматах. У клиентов также могут быть установлены разно­типные эмуляторы терминалов и используемый набор символов будет определяться этим эмулятором. В таких случаях нет воз­можности прямого задания набора символов или кодировки данных для терминальных сессий. Однако тип эмулятора терминала (например, "vt100") передается удаленному сайту и неявно задает набор символов и кодировку. Приложения обычно используют тип терминала для определения применяемого набора символов с помощью тех или иных дополнительных средств. Эмулятор тер­минала может также поддерживать выбор используемого по умолчанию набора символов. В любом случае выбор набора симво­лов для терминальной сессии рассматривается прежде всего как локальная задача клиента.
Внутренние имена, используемые для идентификации алгоритмов и протоколов, обычно не отображаются для пользователя и должны содержать символы набора US-ASCII.
Требования к именам пользователей для сервера и клиентов определяются возможностями сервера. Однако в некоторых случаях эти имена могут отображаться в журнальных файлах, отчетах и т. п. В именах должен использоваться набор символов ISO 10646 UTF-8, но в некоторых случаях может потребоваться иная кодировка. Сервер сам определяет способ отображения имен пользова­телей в поддерживаемые сервером имена. Рекомендуется использовать прямое сравнение битов.
В целях локализации для протокола предприняты попытки минимизации числа передаваемых текстовых сообщений. Сохранен­ные для протокола сообщения этого типа обычно связаны с ошибками, отладочной информацией и некоторыми задаваемыми из­вне данными. Для отображаемой информации следует обеспечить возможность выбора локализованных сообщений взамен сооб­щений, передаваемых протоколом с использованием цифровых кодов. Остальные сообщения следует сделать настраиваемыми.
5. Представление типов данных, используемых в протоколах SSH
byte
Байт представляет собой произвольное 8-битовое значение (октет). Данные фиксированного размера в некоторых случаях представляются как массивы байтов byte[n], где n показывает число байтов в массиве.
boolean
Логические значения сохраняются в одном бите. Значение 0 представляет логическое значение FALSE (ложь), а 1 - логическое значение TRUE (истина). Любые отличные от 0 значения должны интерпретироваться как TRUE, однако для приложений недопустимо использование для логических переменных каких-либо значений, кроме 0 и 1.
uint32
Представляет 32-битовое целое число без знака. Переменные этого типа сохраняются в четырех байтах с уменьшением значи­мости (сетевой порядок). Например, значение 699921578 (0x29b7f4aa) будет иметь байтовое представление 29 b7 f4 aa.
uint64
Представляет 64-битовое целое число без знака. Переменные этого типа сохраняются в восьми байтах с уменьшением значи­мости (сетевой порядок).
string
Двоичная строка произвольной длины. Строки могут содержать любые бинарные данные, включая 0-символ и 8-битовые сим­волы. Строки хранятся в виде переменной типа uint32, указывающей размер (число байтов) и последовательности (возможно нулевой длины) байтов, содержащих отдельные символы строки. Завершающих 0-символов для строк не используется.
Строки также служат для хранения текста. В этом случае для внутренних имен используется набор символов US-ASCII, а для текста, отображаемого пользователю, служит набор символов ISO-10646 UTF-8. Завершающий 0-символ в общем случае не следует включать в строку. Например, строка US-ASCII "testing" будет представлена, как 00 00 00 07 t e s t i n g. Отображение UTF-8 не изменяет представление символов набора US-ASCII.
mpint
Представляет целые числа в формате дополнения до 2, сохраняемые как строки байтов (старший байт сначала). Отрицатель­ные значения задаются 1 в старшем бите первого байта строки данных. Если старший бит имеет значение 0 (положительное число), все остальные биты также должны иметь значение 0 (собственно число начинается со второго байта). Недопустимо ис­пользование значений с незначимыми старшими байтами, установленным в 0 или 255. Нулевое значение должно сохраняться как строка нулевой длины.
По соглашению число, используемое в расчетах по модулю n (Z_n), следует представлять значением из диапазона 0 <= x < n.
Пример:
значение (hex) представление (hex)
0                                      00 00 00 00
9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7
rfc.com.ru
rfc.com.ru
4
80                                     00  00 00 02 00 80
-1234                              00  00 00 02 ed cc
-deadbeef                      00  00 00 05 ff 21 52 41 11 name-list
Строка, содержащая список разделенных запятыми имен. Такие списки представляются значением типа uint32, показывающим длину списка (число байтов), за которым следует список (возможно пустой) разделенных запятыми (,) имен. Имена в списке должны иметь отличную от 0 длину, недопустимо включать в имена символ запятой (","). Поскольку этот тип является списком имен, все элементы списка должны быть представлены набором символов US-ASCII. В зависимости от контекста к именам в списке могут предъявляться дополнительные требования. Например, имена в списке могут быть корректными иден­тификаторами алгоритмов (см. раздел 6) или тегами языков [RFC3066]. Порядок имен в списке может иметь значение, но это не обязательно и зависит от контекста использования списка. Недопустимо использование завершающих null-символов ни в отдельных именах, ни в списке в целом.
Пример:
значение                                         представление (hex)
(), пустой список имен 00 00 00 00
("zlib")                                          00 00 00 04 7а 6с 69 62
("zlib,none")                                00 00 00 09 7а 6с 69 62 2с бе 6f бе 65
6. Имена алгоритмов и методов
Протоколы SSH обозначают конкретные алгоритмы и методы хеширования, шифрования, обеспечения целостности, сжатия и об­мена ключами по именам. Существуют некоторые стандартные алгоритмы и методы, которые должны поддерживаться всеми реализациями. Существуют также алгоритмы и методы, которые включены в спецификацию протокола, но являются необязатель­ными. Кроме того следует ожидать, что некоторые организации пожелают использовать свои алгоритмы и методы.
В этом протоколе все идентификаторы алгоритмов и методов должны быть непустыми строками печатаемых символов из набора US-ASCII, не превышающими по размеру 64 символов. Регистр символов в именах должен приниматься во внимание.
Существует два формата представления имен алгоритмов и методов:
♦    Имена, не содержащие символа @, зарезервированы и выделяются по согласованию с IETF. Примерами таких имен могут служить "3des-cbc", "sha-1", "hmac-sha1", "zlib" (кавычки не являются частью имен). Имена в таком формате корректны только после их регистрации в IANA. Недопустимо включение в регистрируемые имена символов @, запятых (,), пробелов, управ­ляющих символов (коды ASCII до 32 включительно) и символов ASCII с кодом 127 (DEL). Регистр символов в именах прини­мается во внимание, недопустимы имена размером более 64 символов.
♦    Каждый может определять дополнительные имена алгоритмов и методов в формате name@domainname (например, "ourcipher-cbc@example.com". Формат левой части имени (до символа @) не задается спецификацией, однако эта часть должна быть строкой печатаемых символов US-ASCII и недопустимо включение в имена запятых (,), пробелов, символов управления (коды ASCII до 32 включительно) и символов с кодом ASCII 127 (DEL). Имя должно включать единственные символ @. Правая часть имени (после символа @) должна быть корректным полным доменным именем [RFC1034], контролируемым персоной или организацией, определяющей имя с этим доменом. Регистр символов в именах принимается во внимание, недопустимы имена размером более 64 символов. Каждый домен сам определяет способы управления своим пространством имен. Следует отметить, что эти имена похожи на определенные в STD 11 [RFC0822] адреса электронной почты. Однако это сходство являет­ся только внешним и имена никак не связаны с STD 11 [RFC0822].
7. Номера сообщений
Пакеты SSH используют номера сообщений от 1 до 255. Эти номера распределены между различными компонентами:
Протокол транспортного уровня:
1 - 19 - базовые сообщения транспортного уровня (например, disconnect, ignore, debug и т. п.)
20 - 29 - согласование алгоритма
30 - 49 - сообщения, связанные с обменом ключами (допускается совпадение номеров для разных методов аутентификации).
Протокол аутентификации пользователей:
50 - 59 - базовые сообщения протокола аутентификации
60 - 79 - сообщения, связанные с методом аутентификации (допускается совпадение номеров для различных методов).
Протокол соединений:
80 - 89 - базовые сообщения протокола 90 - 127 - сообщения, связанные с каналом.
Зарезервировано для клиентских протоколов:
128 - 191 - резерв
Локальные расширения:
192 - 255 - локальные расширения.
8. Согласование с IANA
Этот документ является частью набора документов, задающих спецификацию протокола. Инструкции по взаимодействию с IANA относительно протокола SSH, определенные в данном документе, [SSH-USERAUTH], [SSH-TRANS] и [SSH-CONNECT], детали­зированы в [SSH-NUMBERS]. Далее для удобства приведена краткая информация, но реальные инструкции по взаимодействию с IANA, содержащиеся в [SSH-NUMBERS], могут впоследствии изменить или отменить написанное здесь.
rfc.com.ru                                                                          5                                                                        rfc.com.ru
Перевод RFC 4251
Выделение перечисленных ниже типов имен для протокола SSH осуществляется по согласованию с IETF:
♦    Имена служб:
•     методы аутентификации;
•     имена каналов протокола соединений;
•     имена глобальных запросов протокола соединений;
•     имена запросов канала протокола соединений.
♦    Названия методов обмена ключами.
♦    Имена алгоритмов:
•     алгоритмы шифрования;
•     алгоритмы MAC;
•     алгоритмы открытых ключей;
•     алгоритмы сжатия данных.
Имена должны указываться с использованием набора символов US-ASCII, недопустимо включение в имена символов @, запя­тых, пробелов, символов управления (коды ASCII до 32 включительно), и символов ASCII с кодом 127 (DEL). Регистр символов в именах принимается во внимание; недопустимы имена размером более 64 символов.
Имена с символом @ являются локальными расширениями и не контролируются IANA.
Каждая из перечисленных выше категорий использует независимое пространство имен. Однако использования совпадающих имен в различных категориях следует избегать, чтобы не возникало путаницы.
Номера сообщений (см. раздел 7) в диапазоне от 0 до 191 выделяются по согласованию с IETF, как описано в [RFC2434]. Номера сообщений от 192 до 255 (локальные расширения) зарезервированы для приватного использования, как описано в [RFC2434].
9. Вопросы безопасности
В целях улучшения восприятия этот раздел содержит информацию по вопросам безопасности из документов, посвященных транс­порту, аутентификации и соединениям.
Транспортный протокол [SSH-TRANS] обеспечивает поддержку конфиденциальных каналов через сети, не обеспечивающие без­опасности. Этот протокол выполняет операции по аутентификации серверных хостов, обмену ключами, шифрованию и обеспече­нию целостности. Этот протокол также обеспечивает уникальный идентификатор сессии, который может использоваться протоко­лами вышележащих уровней.
Протокол аутентификации [SSH-USERAUTH] обеспечивает набор механизмов, который позволяет проверить полномочия пользо­вателя на сервере. Отдельные механизмы протокола аутентификации используют идентификатор сессии, предоставленный транс­портным протоколом и/или зависят от гарантий безопасности и целостности, предоставляемых транспортным протоколом.
Протокол соединений [SSH-CONNECT] задает механизм мультиплексирования множества потоков (каналов) данных через одно конфиденциальное доверенное транспортное соединение. Этот протокол также поддерживает каналы для доступа к интерактив­ным сеансам (shell), доставки данных различных внешних протоколов (включая любые протоколы TCP/IP) с использованием без­опасного транспорта и доступа к системе к системе обеспечения безопасности серверного хоста.
9.1. Генерация псевдослучайных чисел
Этот протокол связывает с каждым сеансом свой ключ (session key), используя случайные данные, связанные с сеансом в хэше, служащем для создания сеансовых ключей. Следует принимать специальные меры по обеспечению “высокого качества” случай­ных чисел. Если случайные данные (например, параметры Diffie-Hellman) являются псевдо-случайными, следует использовать криптографически защищенный генератор случайных чисел (т. е., следующий результат не должен быть предсказуемым на основе предыдущих результатов даже в тех случаях, когда известен их полный набор) с подходящим уровнем энтропии. [RFC4086] со­держит рекомендации по выбору источников случайных чисел и энтропии. Разработчикам следует принимать во внимание важ­ность энтропии и не забывать о сложностях реализации функций генерации псевдослучайных чисел.
Уровень энтропии, доступный для данного клиента или сервера, может в некоторых случаях оказаться недостаточным. В таких случаях следует воспользоваться генератором псевдослучайных, несмотря на недостаток энтропии, или отвергнуть использование протокола. Второй вариант является более предпочтительным.
9.2. Фильтрация управляющих символов
При выводе текста для пользователя (сообщения об ошибках или отладочная информация) клиентским программам следует заме­нять все управляющие символы (за исключением табулятора, перевода строки и возврата каретки) безопасными последовательно­стями для предотвращения атак, организуемых путем передачи управляющих символов.
9.3. Транспорт
9.3.1. Конфиденциальность
В число задач этого документа и группы Secure Shell WG не входит анализ или рекомендации по выбору шифров, отличающихся от тех, которые уже разработаны и приняты в отрасли. На момент создания документа к таким шифрам относятся методы 3DES, ARCFOUR, twofish, serpent и blowfish. Алгоритм AES был опубликован The US Federal Information Processing Standards как [FIPS-197] и принят в качестве одного из стандартных методов шифрования. Как всегда разработчикам и пользователям следует обра­титься к современной литературе для того, чтобы убедиться в отсутствии уязвимостей в алгоритме или его реализациях. Разработ­чикам следует также посмотреть какие алгоритмы считаются более сильными по сравнению с другими и рекомендовать пользова-
rfc.com.ru                                                                                     6                                                            rfc.com.ru
Перевод RFC 4251
телям применение более сильных алгоритмов. Хорошим тоном для разработчиков является вежливое и ненавязчивое уведомление пользователей о существовании более сильных алгоритмов шифрования при выборе пользователем более слабого алгоритма.
Режим шифрования "none" поддерживается для отладки, поэтому этим режимом не следует пользоваться для иных целей. Крипто­графические свойства этого режима достаточно подробно описаны в [RFC2410] т тз этого документа можно сделать вывод о не­применимости данного режима для протокола SSH.
Сравнение этих и других алгоритмов шифрования также можно найти в современной литературе. В качестве примеров таких пуб­ликаций укажем работы [SCHNEIER] и [KAUFMAN]. Оба эти документа описывают CBC-режим4 использования некоторых шиф­ров и недостатки этой схемы. Важно отметить, что этот режим теоретически уязвим для атак chosen cipher-text по причине доста­точно высокой предсказуемости стартовых последовательностей пакетов. Однако такие атаки достаточно сложны и не могут счи­таться применимыми на практике особенно в случаях использования блоков большого размера.
Атаки против режима CBC можно также предотвратить путем вставки пакетов, содержащих сообщение SSH_MSG_IGNORE. Без использования этого метода некоторые атаки могут приводить к успеху. Для того, чтобы данный тип атак (обычно их называют Rogaway-атаками [ROGAWAY], [DAI], [BELLARE]) работал, атакующему нужно знать вектор инициализации IV5 блока, который будет шифроваться следующим. В режиме CBC это результат шифрования предыдущего блока. Если атакующий не имеет воз­можности вовремя увидеть пакет (например, пакет находится в буфере модуля SSH или даже в ядре), атака не достигнет успеха. Если пакет будет передан в сеть, к которой атакующий имеет доступ, атака может оказаться успешной.
В оптимальном варианте от разработчика требуется добавление только одного пакета, если пакет уже передан в сеть и нет других пакетов, ожидающих передачи. Разработчики могут проверить наличие пакетов ожидающих передачи, однако получение такой информации от ядра или буферов может оказаться достаточно сложной задачей. Если ожидающие передачи пакеты отсутствуют, следует передавать пакет, содержащий SSH_MSG_IGNORE. Если новый пакет будет добавляться в поток всякий раз, атакующий, даже зная IV (который по его предположению будет использоваться для шифрования следующего пакета), не сможет корректно предсказать IV и атака, таким образом, не достигнет успеха.
Рассмотрим пример:
Клиент                                                                                                          Сервер
TCP(seq=x, len=500)                           ---->
содержит запись Record 1
[прошло 500 ms, пакета ACK нет]
TCP(seq=x, len=1000)                         ---->
содержит записи Records 1, 2
ACK
1.   Алгоритм Nagle в купе с алгоритмом повтора передачи TCP подразумевают возможность включения двух записей в один сегмент TCP.
2.   Запись Record 2 не находится в начале сегмента и никогда не будет там, поскольку она уже подтверждена с помощью ACK.
3.   Возможность атаки сохраняется, поскольку запись Record уже передана в сеть.
Этот пример показывает опасность опасность использования имеющихся в буфере TCP неотправленных данных в качестве признака необходимости передачи пустого пакета, поскольку в этом случае на момент повторного вызова write() в буфере содержится неподтвержденная запись Record 1.
Показанная ниже ситуация является совершенно безопасной:
Клиент                                                                                                          Сервер
TCP(seq=x, len=500)                           ---->
содержит SSH_MSG_IGNORE
TCP(seq=y, len=500)                           ---->
содержит данные (Data)
В предположении, что IV для второй записи SSH Record фиксировано после получения данных для пакета Data, нужно выполнить следующие операции:
чтение пользовательских данных;
шифрование пустого пакета;
шифрование пакета данных.
9.3.2. Целостность данных
Данный протокол позволяет отключить механизм проверки целостности данных (Data Integrity). Разработчикам следует с осторожностью относится к возможности использования этой функции для каких-либо целей за исключением отладки. Пользователей и администраторов следует явно предупреждать при выборе значения "none" для MAC.
Если не используется опция "none" для MAC, данный протокол обеспечивает целостность данных.
Поскольку MAC использует 32-битовый порядковый номер, возможна утечка информации после передачи 232 пакетов. Однако вы­полнение рекомендации по регенерации ключей должно предотвратить возможность таких атак. Спецификация транспортного протокола [SSH-TRANS] рекомендует менять ключ (rekeying) после передачи 1 Гигабайта данных, а минимальный размер пакета составляет 16 байтов. Следовательно, смена ключей при таких условиях должна произойти до того, как будет передано 228 пакетов.
4cipher-block chaining – сцепка шифрованных блоков. Прим. перев. 5Initialization Vector
rfc.com.ru                                                                          7                                                                        rfc.com.ru
                                                                                              Перевод RFC 4251
9.3.3. Использование перехваченных данных (Replay)
Использование для MAC опций, отличных от "none", обеспечивает целостность данных и аутентификацию. В дополнение к этому транспортный протокол обеспечивает уникальный идентификатор сессии (связанный с псевдослучайными данными, которые яв­ляются частью алгоритма и процесса обмена ключами), который может использоваться протоколами вышележащего уровня для привязки данных к текущей сессии и предотвращения случаев воспроизведения данных, перехваченных из других сессий. Напри­мер, протокол аутентификации [SSH-USERAUTH] использует идентификатор сессии для предотвращения повторного использова­ния сигнатур предыдущих сеансов. Поскольку обмен открытыми ключами криптографически связан с текущей сессией (т. е, на­чальным обменом ключами), перехваченные сигнатуры невозможно повторно использовать в других сессиях. Отметим, что иден­тификатор сессии можно делать открытым без снижения уровня безопасности протокола.
Если две сессии имеют одинаковые идентификаторы (хэш обмена ключами), пакеты из одной сессии могут использоваться в другой. Следует подчеркнуть, что вероятность такого совпадения при использовании современных методов криптографии является минимальной. Дополнительное снижение этой вероятности может обеспечиваться увеличением размерности результата хэш-функции и параметров DH.
Детектирование попыток использования перехваченных данных с использованием монотонного роста порядковых номеров на входе MAC (или HMAC в некоторых случаях_ рассматривается в документах [RFC2085], [RFC2246], [RFC2743], [RFC1964], [RFC2025], [RFC4120]. Основа этих методов описана в документе [RFC2104]. Существенно, что различие порядковых номеров в каждом пакете гарантирует, что по крайней мере один аргумент (input) MAC-функции будет уникальным и обеспечит неповто­ряющийся результат MAC, который не может быть предсказан атакующим. Если сессия длится достаточно долго, порядковые номера могут начать повторяться. Такой повтор может дать атакующему возможность повторного использования ранее за­писанных пакетов с идентичными порядковыми номерами, но такая ситуация возможна только в тех случаях, когда партнеры не используют повторной генерации ключей до того, как начнется повтор порядковых номеров. Если партнеры выполнили регенера­цию ключей, повторное использование пакетов будет обнаружено, поскольку проверка MAC даст отрицательный результат. По этой причине необходимо сделать упор на то, что партнеры должны выполнить регенерацию ключей до того, как начнется повтор порядковых номеров. Естественно, если атакующий будет пытаться повторно использовать собранные пакеты до того, как парт­неры проведут регенерацию ключей, получатель дубликата не получит корректное значение MAC и пакет будет отброшен. При­чина некорректности результата MAC в таких случаях обусловлена тем, что получатель будет создавать MAC на основе принято­го пакета, разделяемого ключа (shared secret) и ожидаемого порядкового номера. Поскольку используемый повторно пакет не имеет ожидаемого порядкового номера (пакет с таким номером уже был принят получателем), рассчитанное значение MAC не бу­дет соответствовать значению из принятого пакета.
9.3.4. Перехват с участием человека (Man-in-the-middle)
Протокол не включает предположений о распространении открытых ключей хостов, требований к инфраструктуре обмена ключами или методам их распространения. Предполагается, что протокол в некоторых случаях будет использоваться без предварительной проверки достоверности связи между ключом и именем хоста. Такое использование уязвимо для атак с участием человек (man-in-the-middle attack). В этом параграфе рассматривается данная проблема и даются рекомендации для администраторов и пользователей по вопросам важности проверки связи между ключом и именем хоста до начала первого сеанса.
Существует три варианта атак на протокол с использованием перехвата с участием человека. В первом случае атакующий разме­щает устройство перехвата на пути между клиентом и сервером до начала сеанса. В этом случае устройство пытается прикинуться легитимным сервером и будет предлагать клиенту свой ключ в начале сеанса. Если устройство станет предлагать реальный ключ сервера, оно не сможет расшифровать или подписать данные, передаваемые между клиентом и легитимным сервером, пока не по­лучит доступа к закрытому ключу (private key) хоста. Используемое для атаки устройство одновременно будет инициировать сес­сию с легитимным сервером, маскируя себя под клиента. Если открытый ключ сервера был до начала сессии получен клиентом с помощью безопасного канала, предложенный используемым для атаки устройством ключ не будет соответствовать ключу серве­ра, хранящемуся у клиента. В таким случае пользователю следует выдавать предупреждение о несоответствии ключей. Как указа­но в параграфе 4.1, пользователь волен принять предложенный ключ и продолжить сессию. Рекомендуется включать в предупре­ждение о несоответствии ключей информацию, которая позволит пользователю клиентского хоста принять обдуманное решение. Если пользователь выберет продолжение сессии с хранящимся у него открытым ключом сервера (вместо ключа, предложенного в начале сеанса), связанные с этим сеансом данные, передаваемые между атакующим и сервером будут отличаться от данных, пере­даваемых между атакующим и клиентом в силу описанного выше использования случайных чисел. В результате атакующий не сможет добиться своей цели, поскольку он не сможет корректно подписывать пакеты, содержащие связанные с сессией данные от сервера, поскольку ему неизвестен закрытый ключ сервера.
Второй вариант похож на первый и также основан на перехвате на этапе организации соединения, но этот случай подчеркивает важность безопасного распространения открытых ключей. Если для открытого ключа сервера не обеспечивается безопасное рас­пространение, клиент не может удостовериться в том, что он соединился с нужным сервером. Атакующий может воспользоваться мошенническими методами (social engineering) для передачи ключей ничего не подозревающим пользователям и после этого по­местить устройство перехвата на пути между клиентом и легитимным сервером. В этом случае клиент просто соединится с устройством атакующего, а атакующий организует соединение с легитимным сервером и сможет организовать мониторинг дан­ных от клиента и сервера, а также манипулировать этими данными. Администраторам серверов рекомендуется делать “отпечатки” ключей доступными для проверки с помощью тех или иных средств, безопасность которых не влияет на целостность реальных ключей. Возможные механизмы обсуждались в параграфе 4.1 и могут также включать защищенные Web-страницы, передачу на бумажных носителях и т. п. Разработчикам следует обеспечивать рекомендации по эффективному использованию та­ких мер с их реализациями. Поскольку протокол является расширяемым, в будущих версиях могут обеспечиваться более эффек­тивные методы распространения ключей серверов до организации первого соединения. Например, могут создаваться отпечатки ключей доступные через безопасные серверы DNS или использоваться Kerberos ([RFC4120]) через GSS-API ([RFC1964]) в процес­се обмена ключами для аутентификации сервера.
В третьем варианте атакующий может попытаться манипулировать пакетами в процессе их передачи между партнерами после ор­ганизации сеанса. Как описано в параграфе 9.3.3, вероятность успеха при таких атаках весьма мала. Как и для описанного в пара­графе 9.3.3 случая причина низкой вероятности успеха при такой атаке обусловлена тем, алгоритм MAC является достаточно без­опасным и нереально подобрать входные данные для алгоритма MAC, чтобы получить на выходе желаемый результат. Более де­тальное обсуждение этого вопроса приводится в разделе 6 [RFC2104]. Если алгоритм MAC имеет уязвимости или достаточно слаб, атакующий может оказаться способен задать те или иные данные на входе для получения известного значения MAC. Используя это, он сможет изменить передаваемые через сеть пакеты. Кроме того, атакующий может воспользоваться уязвимостью алгоритма или его слабостью для определения разделяемого ключа (shared secret) путем просмотра MAC в захваченных пакетах. В любом из этих случаев атакующий сможет создавать пакеты и помещать их в поток SSH. Для предотвращения этого разработчикам следует
rfc.com.ru
8
rfc.com.ru
Перевод RFC 4251
использовать общепринятые проверенные алгоритмы MAC, а администраторам следует читать современную литературу и дискуссии для того, чтобы вовремя узнавать о найденных в используемых алгоритмах MAC уязвимостях или недостатках.
В заключение отметим, что использование этого протокола без надлежащей проверки связи между хостами и их ключами, не обеспечивает должного уровня безопасности и не рекомендуется. Однако такое использование может оказаться необходимым для сред, где безопасность не играет критически важной роли и обеспечивается защита от пассивных атак. Разработчикам протоколов и использующих их приложений следует принимать этот факт во внимание.
9.3.5.  DoS-атаки
Этот протокол предназначен для работы на основе надежного транспорта. При возникновении ошибок передачи или манипуляции сообщениями соединение закрывается. В таких случаях следует предпринять попытку восстановитть соединение. Атак этого типа (“обрыв провода”) почти невозможно избежать.
В дополнение к сказанному данный протокол уязвим для атак на службы (denial of service attack), при которых атакующий может вывести сервер из строя за счет потребления ресурсов процессора и памяти путем организации множества соединений и обмена ключами без аутентификации. Разработчикам следует принимать меры по осложнению таких атак (например, разрешая соединения лишь для ограниченного числа известных клиентов.
9.3.6. Скрытые каналы
Протокол не включает мер предотвращения скрытых каналов. Например, поля заполнения (padding), сообщения SSH_MSG_IGNORE и некоторые другие места могут использоваться для передачи скрытой информации, для которой не существует надежного способа обнаружения на принимающей стороне.
9.3.7. Сохранность тайн
Следует отметить, что алгоритм обмена ключами Diffie-Hellman (DH) может обеспечивать PFS6. PFS определяется как криптогра­фическое свойство протокола организации ключей, при котором компрометация сеансового ключа или долгосрочного закрытого ключа после завершения сессии не ведет к компрометации более ранних сессий [ANSI-T1.523-2001]. Сессии SSH, основанные на обмене ключами с использованием методов DH, описанные в разделе “Обмен ключами по методу Diffie-Hellman” документа [SSH-TRANS] (включая "diffie-hellman-group1-sha1" и "diffie-hellman-group14-sha1") обеспечивают безопасность даже при после­дующем раскрытии ключей или данных аутентификации. Следовательно, протокол SSH обеспечивает PFS. Однако это свойство не передается каким-либо приложениям или протоколам, использующим SSH как транспорт. Транспортный уровень SSH обеспе­чивает конфиденциальность аутентификации и других методов, основанных на секретных данных.
Естественно при раскрытии параметров DH для клиента или сервера раскрываются сеансовые ключи, но они не представляют ценности после завершения обмена ключами. Это лишний раз подчеркивает, что такие элементы не должны сбрасываться в область подкачки и их следует удалять из памяти после завершения обмена ключами.
9.3.8. Упорядочивание методов обмена ключами
Как сказано в разделе “Согласование алгоритма” документа [SSH-TRANS], каждое устройство будет передавать список предпочтительных методов обмена ключами. Наиболее предпочтительный метод указывается в списке первым. Рекомендуется сортировать алгоритмы по силе криптографических методов, размещая первым наиболее сильный. Некоторые рекомендации по этому вопросу содержатся в документе [RFC3766].
9.3.9. Анализ трафика
Пассивный мониторинг любого протокола может дать атакующему некоторую информацию о сессии, пользователе, протоколе, которую не удалось бы получить иным путем. Например, показано, что анализ трафика SSH-сессии позволяет получить информа­цию о размере пароля – [Openwall] и [USENIX].Разработчикам следует использовать пакеты SSH_MSG_IGNORE вкупе с заполне­нием случайной длины для осложнения попыток анализа трафика. Для этих же целей могут использоваться и другие методы.
9.4. Протокол аутентификации
Задачей этого протокола является аутентификация пользователей. Предполагается, что этот протокол работает на основе безопас­ного протокола транспортного уровня, который уже обеспечил аутентификацию сервера, организовал шифрованный коммуника­ционный канал и создал уникальный идентификатор для данной сессии.
Допускается использование нескольких методов аутентификации с различными параметрами безопасности. Выбор методов аутентификации (или их комбинации), дозволенных каждому пользователю определяется локальной политикой сервера. Уровень аутентификации не превышает уровень наиболее слабой из допустимых комбинаций методов.
Сервер может “засыпать” после нескольких неудачных попыток аутентификации для того, чтобы осложнить атакующему поиск ключа. Следует принимать меры, чтобы в таких не возникала возможность организации DoS-атак.
9.4.1. Проблема небезопасного транспорта
Если транспортный уровень не обеспечивает конфиденциальности, методы аутентификации, основанные на секретных данных, следует отключить. Если не обеспечивается достаточной защиты целостности, следует отключить запросы на изменение параметров аутентификации (например, смена паролей) для предотвращения возможности незаметной подмены атакующим шифрованного текста или блокирования им возможности использования новых параметров аутентификации (DoS-атака).
Приведенное выше допущение о том, что протокол аутентификации использует только защищенный транспорт, имеет очень важ­ное значение. При развертывании систем SSH не следует забывать о пагубных последствиях MITM-атак в тех случаях, когда у клиента нет способа достаточно надежно проверить связь ключа с сервером до начала сессии. В частности, применительно к про­токолу аутентификации, клиент может организовать соединение с устройством перехвата, используемым атакующим, и выдать последнему используемые для аутентификации сведения (в частности, имя пользователя и пароль). Даже в тех случаях, когда ис­пользуемые для аутентификации данные не будут раскрыты, атакующий может получить информацию, перехватывая данные о нажатии клавиш, подобно тому, как это делается в приманках (honeypot).
6perfect forward secrec
rfc.com.ru
9
rfc.com.ru
Перевод RFC 4251
9.4.2. Отладочные сообщения
Следует с осторожностью подходить к созданию отладочных сообщений. Эти сообщения могут раскрывать информацию о хосте, если к их содержанию не отнестись должным образом. Отладочные сообщения могут быть отключены (на этапе аутентификации пользователя), если требуется обеспечить высокий уровень безопасности. Администраторам хостов следует принять все возмож­ные меры по изоляции всех уведомлений о событиях и их защите от просмотра нежелательными лицами. Разработчикам следует внимательно отнестись к возможности раскрытия информации через некоторые вполне обыденные события или отладочные сооб­щения. Неплохо также подготовить рекомендации для администраторов по методам предотвращения доступа к такой информации нежелательным лицам. Разработчикам следует предусмотреть возможность минимизировать с помощью локальной политики объем критичной к раскрытию информации, передаваемой пользователю на этапе аутентификации. Для решения этой задачи ре­комендуется по умолчанию отключать выдачу отладочных сообщений и разрешать их включение только в результате целе­направленных действий администратора. Рекомендуется также обеспечивать выдачу администратору соответствующего преду­преждения в тех случаях, когда он разрешает выдачу отладочных сообщений.
9.4.3. Локальная политика безопасности
Разработчики должны обеспечить проверку пользователя на основании представленных им данных, а также возможность при­менения локальной политики сервера для этого пользователя. По причине гибкости протокола SSH может отсутствовать возмож­ность определения локальной политики безопасности, которую следует применять во время аутентификации, поскольку в этот момент невозможно установить тип запрашиваемого пользователем сервиса. Например, локальная политика может разрешать пользователю доступ к файлам на сервере, но не разрешать доступ к командному процессору (interactive shell). Однако при работе протокола аутентификации неизвестно, что собирается делать пользователь – работать с файлами, использовать командный про­цессор или выполнять оба типа операций. В любом случае при существовании на сервере локальной политики она должна приме­няться корректно.
Разработчикам рекомендуется обеспечивать принятую по умолчанию локальную политику и делать ее параметры известными администраторам и пользователям. По усмотрению разработчиков эта локальная политика может разрешать пользователям вы­полнение любых операций или вносить ограничения в действия пользователей – администраторы могут изменить установленную по умолчанию политику в соответствии с реальными задачами. Возможен также вариант, когда принятая по умолчанию политика основана на практическом опыте и может помочь администраторам, не имеющим достаточного опыта работы с SSH. В любом случае политика должна применяться и реализаваться в соответствии с описанными выше требованиями.
9.4.4 Аутентификация с использованием открытых ключей
Использование для аутентификации открытых ключей предполагает, что клиентский хост не компрометирован. Предполагается также отсутствие компрометации для закрытого ключа сервера.
В целях ослабления риска можно можно использовать для закрытых ключей дополнительные пароли (passphrase), однако это не реализуется на основе политики. Предлагается использовать смарт-карты или иные технологии для согласования парольных фраз с политикой.
Сервер может требовать одновременно пароль и открытый ключ, однако это требование ведет к тому, что пользовательский па­роль становится известным серверу (см. следующий параграф).
9.4.5. Парольная аутентификация
Парольный механизм, как задано протоколом аутентификации, предполагает, что сервер не компрометирован. При компромета­ции сервера использование парольной аутентификации будет раскрывать атакующему комбинации имен пользователей и паролей, что может вести к дальнейшему возрастанию риска.
Эту уязвимость можно преодолеть за счет использования другой формы аутентификации. Например, аутентификация на основе открытых ключей не делает допущений об уровне безопасности сервера.
9.4.6. Аутентификация по хостам
Аутентификация по хостам предполагает, что клиентские хосты не компрометированы. Для этого варианта не существует страте­гий снижения риска кроме использования аутентификации по хостам в комбинации с другими методами аутентификации.
9.5. Протокол соединений
9.5.1. Безопасность конечных точек
Безопасность конечных точек предполагается для протокола соединений. При компрометации сервера все терминальные сессии, перенаправление портов или доступ в систему также подвергаются компрометации. Способов предотвращения этого риска нет.
При компрометации клиента, если серверу не удается остановить атаку на уровне протокола аутентификации, все показанные службы (подсистемы и перенаправление) становятся уязвимыми для атаки. Разработчикам следует обеспечивать для администраторов механизмы управления доступными службами для снижения уровня уязвимости. Такие механизмы могут включать выбор хостов и портов, которые могут использоваться в качестве цели перенаправления, хостов, к которым пользователи получают shell-лоступ или на которых разрешается показанные подсистемы.
9.5.2. Перенаправление
Протокол SSH поддерживает перенаправление (proxy forwarding) для других протоколов типа SMTP, POP3 и HTTP. Это может представлять интерес для сетевых администраторов, которые заинтересованы в контроле доступа удаленных пользователей к некоторым приложениям. Важно отметить, что перенаправление протоколов может приводить к нарушению политики безопасности для сайта, поскольку позволяет организовать незаметные туннели через межсетевые экраны. Разработчикам следует обеспечивать для администраторов механизмы контроля перенаправдения, позволяющие обеспечить выполнение политики безопасности для сайтов.
Кроме того, возможно обратное перенаправление, которое также позволяет обходить контроль в межсетевых экранах.
Как было сказано выше перенаправление предполагает безопасность конечных точек. Компрометация конечной точки будет приводить к компрометации всех данных, передаваемых с использованием перенаправления.
rfc.com.ru
10
rfc.com.ru
Перевод RFC 4251
  
9.5.3. Перенаправление трафика X11
Другой формой перенаправдения, обеспечиваемого протоколом соединений SSH, является перенаправление для протокола X11. При нарушении системы безопасности конечной точки перенаправление X11 может открыть возможность для атаки на сервер X11. Пользователям и администраторам следует применять соответствующие механизмы обеспечения безопасности X11 для предотвращения несанкционированного доступа к серверам X11. Разработчикам, администраторам и пользователям, желающим повысить уровень безопасности X11 рекомендуется прочесть документ [SCHEIFLER] и проанализировать известные проблемы для случаев использования SSH пересылки с X11 в бюллетенях CERT VU#363181 и VU#118892 [CERT].
X11-дисплей, использующий пересылку SSH сам по себе не может решить проблем, связанных с безопасностью X11 [VENEMA]. Однако пересылка X11 с использованием SSH (или иного безопасного протокола) в комбинации с псевдодисплеями, принимающими соединения только через локальные механизмы IPC, использующими авторизацию или списки контроля доступа (ACL), могут решить большинство проблем с безопасностью X11, если для MAC не используется режим "none". Разработчикам дисплеев X11 рекомендуется по умолчанию разрешать отображение только через локальные IPC. Разработчикам серверов SSH, поддерживающих перенаправление X11 рекомендуется по умолчанию разрешать соединения только через локальные IPC. На однопользовательских системах может оказаться разумным открывать по умолчанию также соединения через TCP/IP.
Разработчикам протоколов перенаправления X11 следует реализовать для контроля доступа механизм magic cookie, описанный в [SSH-CONNECT], в качестве дополнительного средства предотвращения несанкционированного использования прокси-сервера.
10. Литература
10.1. Нормативные документы
[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
[SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 42507, January 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 21197, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
10.2. Дополнительная литература
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with Replay Prevention", RFC 2085, February 1997.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[FIPS-180-2] US National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standards Publication 180-2, August 2002.
[FIPS-186-2] US National Institute of Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication 186-2, January 2000.
[FIPS-197] US National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", Federal Information Processing Standards Publication 197, November 2001.
[ANSI-T1.523-2001] American National Standards Institute, Inc., "Telecom Glossary 2000", ANSI T1.523-2001, February 2001.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols algorithms and source in code in C", John Wiley and Sons, New York, NY, 1996.
[SCHEIFLER] Scheifler, R., "X Window System : The Complete Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital Press, ISBN 1555580882, February 1992.
7Перевод этого документа на русский язык имеется на сайте http://rfc.com.ru. Прим. перев.
rfc.com.ru                                                                         11                                                                       rfc.com.ru
Перевод RFC 4251
[KAUFMAN] Kaufman, C., Perlman, R., and M. Speciner, "Network Security: PRIVATE Communication in a PUBLIC World", Prentice Hall Publisher, 1995.
[CERT] CERT Coordination Center, The., "http://www.cert.org/nav/index_red.html".
[VENEMA] Venema, W., "Murphy's Law and Computer Security", Proceedings of 6th USENIX Security Symposium, San Jose CA http://www.usenix.org/publications/library/proceedings/sec96/venema.html, July 1996.
[ROGAWAY] Rogaway, P., "Problems with Proposed IP Cryptography", Unpublished paper http://www.cs.ucdavis.edu/~rogaway/ papers/draft-rogaway-ipsec-comments-00.txt, 1996.
[DAI] Dai, W., "An attack against SSH2 protocol", Email to the SECSH Working Group ietf-ssh@netbsd.org ftp://ftp.ietf.org/ietf-mail-archive/secsh/2002-02.mail, Feb 2002.
[BELLARE] Bellaire, M., Kohno, T., and C. Namprempre, "Authenticated Encryption in SSH: Fixing the SSH Binary Packet Protocol", Proceedings of the 9th ACM Conference on Computer and Communications Security, Sept 2002.
[Openwall] Solar Designer and D. Song, "SSH Traffic Analysis Attacks", Presentation given at HAL2001 and NordU2002 Conferences, Sept 2001.
[USENIX] Song, X.D., Wagner, D., and X. Tian, "Timing Analysis of Keystrokes and SSH Timing Attacks", Paper given at 10th USENIX Security Symposium, 2001.
Адреса авторов
Tatu Ylonen
SSH Communications Security Corp
Valimotie 17
00380 Helsinki
Finland
EMail: ylo@ssh.com
Chris Lonvick (редактор) Cisco Systems, Inc. 12515 Research Blvd. Austin 78759 USA EMail: clonvick@cisco.com
Перевод на русский язык Николай Малых
nmalykh@bilim.com
Торговые марки
ssh – торговый знак, зарегистрированный в США и/или других странах.
Полное заявление авторских прав
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Интеллектуальная собственность
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Подтверждение
Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).
rfc.com.ru
12
rfc.com.ru
Подробно что такое криптокошелек и как его выбрать