SecureShell 2.0

• 1. Протоколы SSH и их функции.
• 2. Формат бинарных пакетов SSH.
• 3. Транспортный протокол SSH.
  • 3.1. Описание протокола.
  • 3.2. Методы.
• 4. Протокол аутентификации пользователя.
  • 4.1. Протокол.
  • 4.2 Методы аутентификации.
• 5. Протокол соединения.
  • 5.1. Каналы.
  • 5.2. Интерактивные сессии.
• Приложение 1. Типы данных, используемые в SSH протоколах.
• Приложение 2. Расширение протокола SSH.
• Приложение 3. Значения сообщений.
• Приложение 4. Список источников.

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

1. Протоколы SSH и их функции.

В состав SSH входят три протокола, расположенные друг над другом.

• 1. Транспортный протокол отвечает за аутентификацию сервера, конфиденциальность и целостность передаваемой информации, опционально предоставляется компрессия. Обычно транспортный уровень работает над TCP/IP, но может также использоваться как надстройка других потоков.
• 2. Протокол аутентификации пользователя аутентифицирует клиента для сервера, работает над транспортным протоколом.
• 3. Протокол соединения, предоставляющий работу с несколькими логическими каналами в шифрованном туннеле, работает над протоколом аутентификации пользователя.

Протокол соединения предоставляет каналы, которые могут быть использованы для широкого спектра целей. Стандартные методы предоставляются для установки интерактивных защищенных shell сессий и для форвардинга ("туннелинга") произвольных TCP/IP портов и X11 соединений.

Не трудно заметить, что решая проблемы защиты информации, авторы SSH фактически восстановили полную модель OSI (в которой за транспортым уровнем следует уровень сеанса, что в некотором смысле соответствует определению пользователя, а за ним уровень соединения). Однако вложенность пакетов протокола более высокого уровня в пакеты протокола нижележащего уровня, свойственная TCP/IP, в SSH отсутствует. В SSH используются бинарные пакеты единого формата для всех протоколов приложения. Хотя содержательная часть бинарного пакета сама по себе является пакетом соответствующего протокола приложения и соответственно может иметь разную структуру.

2. Формат бинарных пакетов SSH.

Каждый бинарный пакет имеет следующий формат. Над каждым полем пакета приведен тип данных, используемый в SSH, к которому оно относится (см. прил.1).

uint32	byte	byte[n1]	byte[n2]	byte[m]
packet_length	padding_length	payload	random padding	mac

Рис. 2.1 Формат бинарного пакета.

Отметим, что поле длины пакета также шифруется.

Минимальный размер пакета 16 (или размер блока шифра, что больше) байт (плюс МАС); реализациям СЛЕДУЕТ определять длину после получения первых 8 байтов (или размер блока шифра, что больше) пакета.

Все реализации ДОЛЖНЫ уметь обрабатывать пакеты, имеющие размер несжатой полезной нагрузки 32768 (215) байтов или меньше, и общим размером пакета 35000 байтов или меньше (включая длину, длину перегрузки, полезные расходы, перегрузку и МАС). Реализациям СЛЕДУЕТ поддерживать более длинные пакеты, чем им могут потребоваться. Однако реализациям СЛЕДУЕТ проверять, чтобы длина пакета была разумной для реализаций, избегающих отрицание-обслуживания и/или атак по переполнению буффера.

3. Транспортный протокол SSH.

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

На этом уровне протокола SSH аутентифицируется только хост сервера; аутентификация пользователя не поддерживается, она предусмотрена на более высоком уровне.

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

3.1. Описание протокола.

SSH работает над любым 8-битовым, бинарнопрозрачным транспортом. ЖЕЛАТЕЛЬНО, чтобы нижележащий транспорт обрабатывал ошибки, связанные с возникновением разрыва TCP-соединения, а следовательно позволял верхним уровням грамотно завершать работу.

При работе над TCP/IP сервер слушает порт 22. Этот номер порта официально выдан для протокола SSH и зарегистрирован в IANA.

Идентификация версий клиента и сервера

Соединение инициируется клиентом. Когда соединение установлено, обе стороны ДОЛЖНЫ послать идентификационное сообщение. До этого сообщения и включая его пакеты идут открытыми без использования бинарного формата, поскольку пока не известны версии, бинарный формат не определен.

Идентификационное сообщение содержит идентификационную строку, содержащую "SSH-protoversion-softwareversion comments" ("SSH-версия протокола-замечания по версии ПО").

Подстрока версии ДОЛЖНА содержать только печатные символы US-ASCII, не включая пробелов и знака минус (-). Она изначально задумывалась для фиксации расширений и отображения возможностей реализации. Подстрока замечаний содержит некоторую дополнительную информацию, которая может быть полезна для разрешения проблем.

Часть идентификационной строки без символов возврата каретки и новой строки используется в обмене ключами.

До посылки идентификационного сообщения сервер МОЖЕТ посылать другие строки данных. Рекомендуется, чтобы эти строки были в кодировке ISO-10646 UTF-8 [RFC-2044], и они НЕ ДОЛЖНЫ начинаться с "SSH-". Клиенты ДОЛЖНЫ уметь обрабатывать эти строки. Первоначально эта возможность была задумана, чтобы позволить TCP-wrappers отображать сообщение об ошибке до рассоединения.

После посылки идентификационных сообщений клиент и сервер могут, не ожидая ответа, начинать процедуру согласования алгоритмов. Всем пакетам, следующим за идентификационной строкой, СЛЕДУЕТ пользоваться бинарными пакетами протокола той версии, которая была заявлена.

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

• Если клиент старой версии инициировал работу с новым сервером, не поддерживающим совместимость, то клиент сам должен обрабатывать ситуацию (завершить соединение), не дожидаясь действий со стороны сервера, в свою очередь на новом сервере соединение со старым клиентом должно грамотно обрабатываться (завершение соединения). Поддерживает или нет сервер совместимость, определяется по номеру версии, который он устанавливает в идентификационной строке: если "1.99", то совместимость поддерживается (при этом новый клиент должен понимать, что номер версии сервера "2.0"), если "2.0", то нет.
• Новый клиент - старый сервер. Поскольку новый клиент МОЖЕТ сразу послать дополнительные данные после его идентификационной строки (до получения идентификации сервера), старый протокол может уже грохнуться к моменту, когда клиент узнает, что сервер старый. Когда это случиться, клиенту СЛЕДУЕТ закрыть соединение с сервером и начать соединение заново в режиме старого протокола.

Согласование алгоритмов

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

Согласовываемые методы:
1) алгоритм обмена ключами,
2) алгоритм создания публичного ключа хоста сервера,
3) алгоритмы шифрования для сервера и клиента,
4) МАС алгоритмы сервера и клиента,
5) алгоритмы сжатия для сервера и клиента,
6) национальный язык, используемый сервером и клиентом в сообщениях, предназначающихся для вывода на терминал или записи в log-файлы.

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

Далее, не дожидаясь получения пакета согласования противоположной стороны, каждая сторона, надеясь на правильность своих предположений и предпочтений, МОЖЕТ инициировать начало процедуры обмена ключами. Если предположения относительно всех алгоритмов оказались правильными, первый пакет обмена ключами, который был оптимистично послан, обработавыется. Однако, если предположение оказалось неправильным, то пакеты согласования исправляются, учитывая пожелания противоположной стороны, высказанные в первом пакете согласования, и послаются "исправленные" пакеты. В этой ситуации первый пакет обмена ключами игнорируется (даже если ошибка не затрагивала содержимого этих первых пакета(ов)).

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

Обмен ключами

Обмен ключами проходит по алгоритму, утвержденному в процессе согласования. На данный момент список возможных алгоритмов обмена ограничивается одним методом, Диффе-Хелмана (Diffie-Hellman).

В процессе обмена ключами посылается публичный ключ сервера, сформированный по согласованному алгоритму публичного ключа.

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

Возможно использование двух надежных моделей.

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

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

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

Все-таки реализациям СЛЕДУЕТ прилагать усилия для проверки ключей хостов. Например, не проверять ключ хоста только при первом соединении, сохранять его в локальной базе данных и сравнивать во всех последующих соединениях с этим хостом.

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

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

После обмена ключами с неявной (скрытой, подразумеваемой, но не выраженной) аутентификацией сервера, клиент ДОЛЖЕН ждать ответа на запрос службы прежде, чем посылать остальные данные. Под службой понимается название одного из вышестоящих протоколов (либо протокола аутентификации пользователя, либо протокол соединения). Из всех служебных данных, генерировавшихся в транспортном протоколе, вышестоящие протоколы имеют доступ только к идентификатору сессии, сгенерированному во время обмена ключами.

3.2. Методы.

Используемые на транспортном уровне SSH методы описаны ниже. Они все подчиняются одинаковым политическим требованиям:

• используется тот алгоритм и ключ, который был утвержден в процессе согласования;
• алгоритмы в каждом направлении ДОЛЖНЫ работать независимо, и реализации ДОЛЖНЫ позволять выбирать алгоритмы независимо для обоих направлений,
• новые алгоритмы могут быть заданы в соответствии с стандартами образования новых имен (прил.2).

Сжатие

Если согласовано сжатие, сжимается поле полезной нагрузки (и только оно). Поле длины и МАС вычисляется, исходя из размера сжатой полезной нагрузки.

Сжатие может не быть состоятельным (в зависимости от метода).

Сейчас определены следующие методы сжатия:

none	REQUIRED	no compression
zlib	OPTIONAL	GNU ZLIB (LZ77) compression

Метод сжатия "zlib" описан в [RFC-1950] и в [RFC-1951].

Шифрование

Когда шифрование действует, поля длины пакета, длины перегрузки, полезная нагрузка и перегрузки каждого пакета ДОЛЖНЫ быть зашифрованным заданным алгоритмом.

Всем шифрам СЛЕДУЕТ использовать ключи с эффективной длиной от 128 бит и более.

Определены следующие шифры:

3des-cbc	REQUIRED	three-key 3DES in CBC mode
blowfish-cbc	RECOMMENDED	Blowfish in CBC mode
twofish-cbc	RECOMMENDED	Twofish in CBC mode
arcfour	OPTIONAL	the ARCFOUR stream cipher
idea-cbc	OPTIONAL	IDEA in CBC mode
cast128-cbc	OPTIONAL	CAST-128 in CBC mode
none	OPTIONAL	no encryption; NOT RECOMMENDED

При отсутствии шифрования ("none") отсутствует конфиденциальная защита, что не рекомендуется. Если выбрана мода "none", некоторые незащищенные функции протоколов высокого уровня могут быть не доступны.

Целостность данных

Целостность данных обеспечивается включением в каждый пакет кода аутентификации сообщения (МАС), который вычисляется из закрытого ключа, порядкового номера пакета, и содержимого пакета. При инициализации МАС "none", и его длина ДОЛЖНА быть нуль. После обмена ключами выбранный МАС вычисляется из конкатенации до шифрования данных пакета.

мас = МАС(ключ, порядковый номер||нешифрованный пакет)

где нешифрованный пакет - входной пакет без МАС (поля длины, полезные нагрузки или перегрузки), и порядковый номер - подразумеваемый порядковый номер пакета, принадлежит типу uint32.

Порядковый номер инициализирован 0 для первого пакета, и увеличивается после каждого пакета (независимо, используется ли шифрование или МАС). Порядковый номер никогда не переустанавливается, даже если ключи/алгоритмы пересогласуются заново позже. Он возвращается к 0 после 232 пакетов. Порядковый номер пакета сам по себе не включаются в отсылаемый после расширения пакет.

МАС байты, полученные из МАС алгоритма, ДОЛЖНЫ передаваться без шифрования в завершающей части пакета. Количество МАС байтов зависит от выбранного алгоритма.

Следующие МАС алгоритмы определены:

hmac-sha1	REQUIRED	HMAC-SHA1 (length = 20)
hmac-sha-96	RECOMMENDED	first 96 bits of HMAC-SHA1 (length = 12)
hmac-md5	OPTIONAL	HMAC-MD5 (length = 16)
hmac-md5-96	OPTIONAL	first 96 bits of HMAC-MD5 (length = 12)
none	OPTIONAL	no MAC; NOT RECOMMENDED

Алгоритмы "hmac-*" описаны в [RFC-2104]. В МАС алгоритмах "*-n" используется только n первых бит от результирующего значения. Хэш алгоритмы описаны в [Schneier]. Отсутствие МАС метода ("none") НЕ РЕКОМЕНДУЕТСЯ. Активные атаки могут модифицировать передаваемые данные при отсутствии МАС.

Методы обмена ключами

Метод обмена ключами определяет, как генерируются ключи одноразовой сессии для шифрования и аутентификации, и как происходит аутентификация сервера.

Только один метод обмена ключами определен как ТРЕБУЕМЫЙ:

diffie-hellman-group1-sha1

REQUIRED

Алгоритмы публичных ключей

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

Несколько аспектов, которые определяют тип публичных ключей:

• Формат ключа: в какой кодировке ключ и как представлены сертификаты подлинности.
• Алгоритмы подписи и/или шифрования. Некоторые типы ключей могут не поддерживать ни подписывания, ни шифрования.

Следующий публичный ключ и/или сертификационные форматы определены на данный момент:

ssh-dss	REQUIRED	sign	Simple DSS
x509v3	RECOMMENDED	sign	X.509 certificates
spki	OPTIONAL	sign	SPKI certificates
pgp	OPTIONAL	sign	OpenPGP certificates

Тип ключа ДОЛЖЕН быть четко известен всегда (начиная с алгоритма согласования и некоторых других исходных текстов).

4. Протокол аутентификации пользователя.

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

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

Если транспортный уровень не обеспечивает шифрования, то особо уязвимые аутентификационные методы ЖЕЛАТЕЛЬНО отключить. А если он не обеспечил и МАС, то необходимо отключить и запросы по обмену аутентификационными данными (например, обмен паролями), чтобы предотвратить необнаруживаемые в этом случае атаки, модифицирующие шифрованный текст.

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

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

4.1. Протокол.

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

Клиент посылает запросы с аутентификацией по конкретному методу.

Аутентификационные методы определяются по названию (имени). Отсутствие аутентификации обозначается "none". Обычно работа без аутентификации пользователя запрещена. Однако, клиент отправляет пакет, где в качестве метода аутентификации установлен "none", только для получения списка, методов поддерживаемых сервером. Клиент использует методы из списка сервера в любом порядке. После успешной аутентификации по некоторому методу, сервер высылает сообщение, содержащее список оставшихся необходимых методов. Сервер может более жестко контролировать процесс аутентификации, предлагая методы по одному.

Некоторые сервера имеют время задержки аутентификации и рассоединяются, если аутентификация не была произведена в этот период времени. РЕКОМЕНДОВАННОЕ время задержки 10 минут. Кроме того, сервер может ограничивать число неудачных аутентификационных запросов, которые могут быть выполнены в одной сессии (РЕКОМЕНДОВАННОЕ ограничение 20 попыток). Если порог достигнут, серверу рассоединиться.

После удачного завершения всего процесса аутентификации пользователя начинается процесс установки канала уровня протокола соединения.

4.2. Методы аутентификации.

Метод публичного ключа пользователя: publickey

Единственный обязательный для всех реализаций серверов аутентификационный метод - метод публичного ключа. Все реализации ДОЛЖНЫ поддерживать этот метод; однако, не всем пользователям необходимо иметь публичные ключи, и в ближайшее время большинство местных стратегий вероятно не станут требовать публичного ключа аутентификации для каждого пользователя.

Во время аутентификации по методу публичного ключа согласовывается алгоритм создания публичного ключа, в последствии высылается сам публичный ключ и подпись, сгенерированная при помощи секретного ключа пользователя. Сервер проверяет, что ключ является действующим аутентификатором пользователя, и а также истинность подписи. Если и то, и другое подтверждается, аутентификационный запрос принимается; иначе он ДОЛЖЕН быть отвергнут.

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

Метод пароля: password

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

Аутентификация, основанная на хосте: hostbased

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

5. Протокол соединения.

SSH протокол соединения обеспечивает интерактивные сессии, удаленное выполнение команд, форвардирг TCP/IP соединений и Х11 соединений. Все эти каналы мультиплицируются в один зашифрованный туннель. Протокол соединения был сконструирован так, чтобы работать над транспортным протоколом и протоколом аутентификации пользователя SSH.

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

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

5.1. Каналы.

Каналами в протоколе SSH называются терминальные сессии, форвардируемые соединения и т.п. Любая сторона может открыть канал. Несколько каналов мультиплицируются в одном соединении.

На каждом конце канал идентифицируется своим номером. Запрос на открытие канала содержат номер канала отправителя. Любые другие сообщения, связанные с каналом, содержат номер канала получателя.

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

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

Типы каналов:
1) интерактивная сессия,
2) форвардинг TCP/IP соединения,
3) X11 форвардинг,
4) форвардинг аутентификационного агента.

Открытие и закрытие канала

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

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

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

Передача данных

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

Данные передаются в пакетах как строки.

Максимальное разрешенное для передачи количество данных - это текущий размер буфера противоположной стороны. С каждой порцией посланных данных размер буфера уменьшается. Обе стороны МОГУТ игнорировать все лишние данные, посланные, когда разрешенный буфер уже исчерпан.

5.2. Интерактивные сессии.

Сессия - удаленное выполнение программы. Программой может быть shell, приложение, системная команда или некоторые встроенные подсистемы. Несколько сессий не могут быть активны одновременно.

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

К сообщениям, специфичным для интерактивных сессий относятся:

• 1) запрос псевдо-терминала, в котором задаются тип терминала, служебные символы, размер окна вывода (данное из разряда информационных, нежели обязательных к исполнению),
• 2) сообщение об изменение окна отображения (информационное сообщение),
• 3) сообщение о контроле потока данных, т.е. о разрешении/запрещении контролировать (т.е. приостанавливать) поток данных на стороне клиента,
• 4) сообщение об установке переменных окружения, необходимых запускаемым впоследствии утилитам shell/command, обычно набор данных, для которых возможна установка, регламентируется;
• 5) запуск shell, команды, подсистемы;
• 6) сообщение статуса завершения работы запрошенного сервиса;
• 7) запрос X11 форвардинга.

Приложение 1. Типы данных, используемые в SSH протоколах.

byte	Байт - произвольное 8-битовое значение (октет) [RFC1700]. Данные фиксированной длины иногда представляются как последовательность байт и обозначаются byte[n], где n количество байт в массиве.
boolean	Булевское значение хранится как единичный байт. Значение 0 - ложь, 1 - истина. Все ненулевые значения ДОЛЖНЫ интерпретироваться как истина; однако, приложения НЕ ДОЛЖНЫ хранить значения, отличные от 0 или 1.
uint32	32-битовое беззнаковое целое хранится как 4 байта, чтобы уменьшения значения (сетевой порядок байт). Например, значение 699921578 (0x29b7f4aa)хранится как 29 b7 f4 aa.
string	Строка произвольной длины, может содержать произвольные бинарные данные, включающие 0-ые символы и 8-битовые символы. Строки хранятся в виде: uint32, содержащий их длину (количество байт, которые следуют), и далее следует 0 (=пустая строка) или более байтов, которые являются значением строки. Завершающего нулевого символа нет. Строки также используются для хранения текста. В этом случае, US-ASCII используется для внутренних имен, и ISO-10646 UTF-8 для текста, которые может отображаться для пользователя. В норме завершающий нулевой символ ЖЕЛАТЕЛЬНО не хранить в строке. Строка US-ASCII "testing" представляется 00 00 00 07 t e s t i n g. UTF8 не изменяет символы в кодировке US-ASCII.
mpint	Это целые в двойном дополнительном формате, хранимые как строка, 8 бит в байте, MSB первый. Отрицательные числа имеют 1 в знаковом бите в первом байте данных. Положительное число ДОЛЖНО предшествоваться нулевым байтом (знаковый бит - 0). Ненужные ведущий нуль или 255 байтов НЕ ДОЛЖНЫ включаться. Нулевое значение ДОЛЖНО хранится как строка с нулевыми байтами данных.

Приложение 2. Расширение протокола SSH.

Авторы надеются, что протокол будет развиваться, и некоторые организации захотят использовать собственное шифрование, аутентификацию и/или методы обмена ключами. Центральная регистрация всех нововведений обременительна, особенно для экспериментальных версий. С другой стороны, отсутствие центральной регистрации приведет к конфликтам в методах идентификации.

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

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

SSH протоколы ссылаются на алгоритмы частичного хэширования, шифрования, целостности, сжатия и обмена ключами или протоколы по именам. Реализации ДОЛЖНЫ поддерживать несколько стандартных алгоритмов, некоторые из определенных в спецификации протокола алгоритмов ОПЦИОНАЛЬНЫ. Некоторые организации возможно захотят ввести собственные алгоритмы.

В этом протоколе, все идентификаторы алгоритмов ДОЛЖНЫ быть US-ASCII строками не длиннее, чем 64 символа. В именах ДОЛЖНЫ различаться заглавные и прописные буквы.

Существует 2 формата имен алгоритмов:

• Для IANA (Internet Assigned Numbers Authority) зарезервированы имена, не содержащие знак at (@). Например, уже включены имена '3des-cbc', 'sha-1', 'hmac-sha1', и 'zlib' (кавычки не являются частью имени). Можно добавить имена в этом формате, зарегистрировав их в IANA. Имена в этом формате НЕ ДОЛЖНЫ использоваться без регистрации в IANA. Зарегистрированные имена НЕ ДОЛЖНЫ содержать знака at (@) или запятой (,).
• Дополнительные названия задаются в формате name@domainname, т.е. "ourcipher-cbc@ssh.fi". Формат части, предшествующей знаку at не специфицируется; он ДОЛЖЕН быть в кодировке US-ASCII, исключая знаки at и запятую. Часть за знаком at ДОЛЖНА быть действительным полным зарегистрированным доменным именем в internet [RFC-1034], контролируемым персоной или организацией, определившей это имя.

Приложение 3. Значения сообщений.

SSH пакеты имеют значения сообщений в диапазоне 1-255.

Транспортный протокол:

Протокол аутентификации пользователя:

Зарезервировано для протоколов клиента: 128-191

Локальные расширения: 192-255

Приложение 4. Список источников.

сайт http://www.ssh.fi

1. draft-ietf-secsh-architecture-03.txt
2. draft-ietf-secsh-transport-05.txt
3. draft-ietf-secsh-user-05.txt
4. draft-ietf-secsh-connect-05.txt

  [Начало]