Network Working Group T. Ylonen
Request for Comments: 4253 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
The Secure Shell (SSH) Transport Layer Protocol
Abstract
Secure Shell (SSH) это протокол для безопасного удалённого входа и
других безопасных сетевых сервисов поверх небезопасной сети.
Этот документ описывает протокол транспортного уровня SSH, который
обычно работает поверх TCP/IP. Протокол может быть использован как основание
для ряда безопасных сетевых сервисов. Он предоставляет сильное
шифрование, аутентификацию сервера и защиту целостности. Он может
также предоставлять сжатие.
Метод передачи ключа, алгоритм открытого ключа, симметричный алгоритм
шифрования, алгоритм аутентификации сообщения и алгоритм хеширования здесь
все описаны.
Этот документ также описывает метод передачи ключа Diffie-Hellman
и минимальный набор алгоритмов, которые нужны для работы
протокола транспортного уровня SSH.
Содержание
1. Введение
2. Contributors
3. Соглашения используемые в этом документе
4. Настройка подключения
4.1. Использование через TCP/IP
4.2. Передача версии протокола
5. Совместимость со старыми версиями SSH
5.1. Старый клиент, новый сервер
5.2. Новый клиент, старый сервер
5.3. Размер пакета и Overhead
6. Двоичный протокол пакетов
6.1. Максимальная длина пакета
6.2. Сжатие
6.3. Шифрование
6.4. Целостность данных
6.5. Методы обмена ключами
6.6. Алгоритмы открытого ключа
7. Обмен ключами
7.1. Согласование алгоритма
7.2. Получаемые значения
7.3. Использование ключей
8. Обмен ключами по алгоритму Diffie-Hellman
8.1. diffie-hellman-group1-sha1
8.2. diffie-hellman-group14-sha1
9. Повторный обмен ключами
10. Запрос сервиса
11. Дополнительные сообщения
11.1. Disconnection Message
11.2. Ignored Data Message
11.3. Debug Message
11.4. Reserved Messages
12. Summary of Message Numbers
13. IANA Considerations
14. Security Considerations
15. References
15.1. Normative References
15.2. Informative References
Authors' Addresses
1. Introduction
The SSH transport layer is a secure, low level transport protocol.
It provides strong encryption, cryptographic host authentication, and
integrity protection.
Аутентификация на этом уровне протокола ориентирована на хосты; этот протокол
не выполняет аутентификацию пользователя. A higher level protocol for
user authentication can be designed on top of this protocol.
Протокол был разработан быть простым and flexible to allow
parameter negotiation, and to minimize the number of round-trips.
Описан метод обмена ключа, алгоритм открытого ключа, алгоритм симметричного
шифрования, алгоритм аутентификации сообщений и алгоритм хеширования.
It is expected that in most environments, only 2
round-trips will be needed for full key exchange, server
authentication, service request, and acceptance notification of
service request. The worst case is 3 round-trips.
2. Contributors
см оригинал
3. Соглашения используемые в этом документе
All documents related to the SSH protocols shall use the keywords
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe
requirements. These keywords are to be interpreted as described in
[RFC2119].
The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
this document when used to describe namespace allocation are to be
interpreted as described in [RFC2434].
Protocol fields and possible values to fill them are defined in this
set of documents. Protocol fields will be defined in the message
definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as
follows.
byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data
Throughout these documents, when the fields are referenced, they will
appear within single quotes. When values to fill those fields are
referenced, they will appear within double quotes. Using the above
example, possible values for 'data' are "foo" and "bar".
4. Настройка подключения
SSH works over any 8-bit clean, binary-transparent transport.
Нижележащий транспортный протокол должен защищать от ошибок передачи, т.к.
такие ошибки приводят к разрыву соединения SSH.
Клиент инициирует соединение.
4.1. Использование через TCP/IP
Когда используется через TCP/IP, сервер обычно ждёт соединения на порту 22.
Этот номер порта зарегистрирован в IANA, и официально назначен для SSH.
4.2. Передача версии протокола
Когда соединение установлено, обе стороны ОБЯЗАНЫ послать строку идентификации
Строка ДОЛЖНА иметь вид:
SSH-protoversion-softwareversion[<SP>comments]<CR><LF>
С того момента как протокол описываемый в этом наборе документов имеет версию
2.0, 'protoversion' ДОЛЖНА быть "2.0".
Строка 'comments' является НЕОБЯЗАТЕЛЬНОЙ.
Если строка 'comments' присутствует, то символ '<SP>'
(Spase, ASCII 32) ДОЛЖЕН разделять строки 'softwareversion' и 'comments'.
Идентификация ОБЯЗАНА заканчиваться символами <CR> (Carriage Return, ASCII 13) и <LF>
(Line Feed, ASCII 10). Разработчики которые хотят поддерживать
совместимость со старыми, недокументированными версиями этого протокола могут
захотеть обрабатывать идентификационную строку не ожидая
наличия символа <CR> по причинам описываемым в
разделе 5 данного документа. Символ null НЕ ДОЛЖЕН быть отправлен.
Максимальная длина строки 255 символов, включая <CR> и <LF>.
Часть идентификационной строки до символов <CR> и <LF> используется
в обмене ключом Диффи-Хеллмана(раздел 8).
Сервер МОЖЕТ послать другие строки данных до отправки строки о версии.
Каждая линия (строка) ДОЛЖНА оканчиваться <CR> и <LF>.
Такие строки НЕ ДОЛЖНЫ начинаться с "SSH-", и ДОЛЖНЫ иметь кодировку
ISO-10646 UTF-8 [RFC3629] (язык не определён). Клиенты
ДОЛЖНЫ уметь обрабатывать такие стороки. Такие строки МОГУТ быть молча
проигнорированы или МОГУТ быть показаны пользователю клиента. Если они
показаны, то фильтрация управляющих символов, как изложено в [SSH-ARCH],
ДОЛЖНО быть использовано. Основное назначение этой возможности разрешить TCP-
wrappers отображать сообщение об ошибке до отключения.
Обе строки 'protoversion' и 'softwareversion' ДОЛЖНЫ состоять из
печатных символов US-ASCII, за исключением пробельных символов и знака (-).
Строка 'softwareversion' в первую очередь используется to trigger compatibility extensions
и указания возможностей данной реализации.
Строка 'comments' ДОЛЖНА содержать дополнительную информацию которая может
быть полезной в решении проблем пользователя.
As such, пример правильной идентификационной строки:
SSH-2.0-billsSSH_3.6.3q3
Данная идентификационная строка не содержит необязательной строки
'comments' и поэтому завершена символами <CR&rt; и <LF&rt; сразу
после строки 'softwareversion'.
Обмен ключа начинается немедленно после отправки этого идентификатора.
Все пакеты следующие после идентификационной строки БУДУТ использовать
бинарный протокол пакетов, который описан в разделе 6.
5. Совместимость со старыми версиями SSH
Как отмечалось ранее, 'protoversion' определённый для этого протокола это "2.0".
Ранние версии этого протокола не были официально
задокументированы, но общеизвестно что они использовали 'protoversion'
"1.x" (например, "1.5" или "1.3"). Во время написания этого документа
многие реализации SSH использовали версию протокола 2.0, но
известно всё ещё имеются устройства использующие предыдущие версии.
В течение переходного периода, важно быть готовым работать
в направлении совместимости с установленными клиента SSH и серверами
которое используют старую версию протокола. Информация в этом
разделе относится только к соответствующим реализациям поддерживающим
совместимость с SSH версиями 1.x. Для интересующихся, единственная известная
документация протокола 1.x содержится в файлах README которые
поставляются вместе с исходным кодом [ssh-1.2.30].
5.1. Старый клиент, новый сервер
Серверная реализация МОЖЕТ поддерживать конфигурируемый флаг совместимости
который включает совместимость со старыми версиями. Когда флаг выставлен,
сервер ДОЛЖЕН идентифицировать свою 'protoversion' как "1.99". Клиенты
использующие протокол 2.0 ОБЯЗАНЫ воспринимать это как "2.0".
В этом режиме, сервер НЕ ДОЛЖЕН посылать символ <CR> (ASCII 13)
после идентификационной строки.
В режиме совместимости, сервер НЕ ДОЛЖЕН посылать любые следующие
данные после отправки своей идентификационной строки пока он не примет
идентификационную строку от клиента. Сервер сможет определить
использует ли клиент старый протокол и сможет вернуться к
старому протоколу если потребуется. В режиме совместимости, сервер НЕ ДОЛЖЕН
посылать дополнительные данные до строки идентификации.
Когда совместимость со старыми клиентами не нужна, сервер МОЖЕТ
посылать начальные данные для обмена ключа сразу после передачи
идентификационной строки (в следующем пакете).
5.2. Новый клиент, старый сервер
С тех пор как клиент МОЖЕТ немедленно посылать дополнительные данные после
идентификационной строки (до получения идентификационной строки сервера),
старый протокол может уже быть нарушен прежде чем клиент увидит
что сервер использует старую версию. Когда это происходит, клиент ДОЛЖЕН
закрыть соединение с сервером и переподключиться используя старый протокол.
5.3. Packet Size and Overhead
Некоторые читатели будут беспокоиться об увеличении размера пакета в связи
с новыми заголовками, padding и Message Authentication Code (MAC).
Минимальный размер пакета составляет порядка 28 байт (в зависимости
от согласованных алгоритмов). Увеличение незначительно для больших
пакетов, но очень значительно для однобайтовых пакетов (telnet-type
сессии). Однако, есть ряд факторов которые позволяют не рассматривать это
как проблему почти во всех случаях:
o Минимальный размер заголовка TCP/IP 32 байта. Из этого,
увеличение на самом деле с 33 до 51 байт (приблизительно).
o Минимальный размер поля данных в пакете Ethernet 46 байт [RFC0894].
Из этого, увеличение не больше чем на 5 байт.
When Ethernet headers are considered, увеличение менее чем на 10
процентов.
o The total fraction of telnet-type data in the Internet is
negligible, even with increased packet sizes.
The only environment where the packet size increase is likely to have
a significant effect is PPP [RFC1661] over slow modem lines (PPP
compresses the TCP/IP headers, emphasizing the increase in packet
size). However, with modern modems, the time needed to transfer is
in the order of 2 milliseconds, which is a lot faster than people can
type.
There are also issues related to the maximum packet size. To
minimize delays in screen updates, one does not want excessively
large packets for interactive sessions. The maximum packet size is
negotiated separately for each channel.
6. Двоичный протокол пакетов
Каждый пакет имеет следующий формат:
uint32 packet_length
byte padding_length
byte[n1] payload; n1 = packet_length - padding_length - 1
byte[n2] random padding; n2 = padding_length
byte[m] mac (Message Authentication Code - MAC); m = mac_length
packet_length
Длина пакета в байтах, не включая 'mac' или само поле 'packet_length'.
padding_length
Длина вставки 'random padding' (в байтах).
payload
Полезное содержимое пакета. Если сжатие было согласовано,
то это поле сжато. Изначально, сжатие ДОЛЖНО быть "none" (без сжатия).
random padding
Вставка переменной длины (дополняет пакет до нужной длины и защищает
от анализа трафика), такой чтобы общая длина
(packet_length || padding_length || payload || random padding)
являлась кратным размеру блока шифра или 8, в зависимости от того что
больше. Вставка ДОЛЖНа быть как минимум 4 байта. Вставка должна
состоять из случайных байтов. Максимальный размер вставки 255 байт.
mac
Message Authentication Code. Если аутентификация сообщений была
согласована, то это поле содержит байты MAC. Первоначально,
алгоритм MAC ДОЛЖЕН быть "none".
Учтите что длина сцеплённых полей 'packet_length', 'padding_length',
'payload'и 'random padding' ДОЛЖНА быть кратной размеру блока шифра
или 8, в зависимости от того что больше. Это ограничение ДОЛЖНО быть
применено, даже когда используются поточные шифры.
Учтите что поле 'packet_length' также шифруется и его обработка
требует особого внимания при отправке или приёме пакетов. Также учтите что
вставка переменного размера 'random padding' может помочь усложнить
анализ трафика.
Минимальный размер пакета 16 (или размер блока шифра, в зависимости
что больше) байт (плюс 'mac'). Реализации ДОЛЖНЫ
расшифровывать длину после приёма первых 8 (или размера блока шифра,
в зависимости что больше) байтов пакета.
6.1. Максимальная длина пакета
Все реализации ДОЛЖНЫ уметь обрабатывать пакеты с несжатой
полезной нагрузкой длиной 32768 байта или меньше и общим размером пакета
35000 байтов или меньше (включая 'packet_length',
'padding_length', 'payload', 'random padding', and 'mac'). The
maximum of 35000 bytes is an arbitrarily chosen value that is larger
than the uncompressed length noted above. Implementations SHOULD
support longer packets, where they might be needed. For example, if
an implementation wants to send a very large number of certificates,
the larger packets MAY be sent if the identification string indicates
that the other party is able to process them. However,
implementations SHOULD check that the packet length is reasonable in
order for the implementation to avoid denial of service and/or buffer
overflow attacks.
6.2. Сжатие
Если согласовано сжатие, поле 'payload' (и только оно)
будет сжато с использованием согласованного алгоритма. Поле
'packet_length' и поле 'mac' будут расчитаны из сжатой полезной нагрузки
Шифрование бедут выполнено после сжатия.
Compression MAY be stateful, depending on the method. Сжатие
ДОЛЖНО быть независимым для каждого направления и реализации ДОЛЖНЫ
позволять независимо выбирать алгоритм для каждого направления. На
практике однако, РЕКОМЕНДУЕТСЯ выбирать единый метод сжатия для обоих
направлений..
В данный момент определены следующие методы сжатия:
none REQUIRED без сжатия
zlib OPTIONAL сжатие ZLIB (LZ77)
Сжатие "zlib" описано в [RFC1950] и в [RFC1951].
The compression context is initialized после каждого обмена ключами, and
is passed from one packet to the next, with only a partial flush
being performed at the end of each packet. A partial flush means
that the current compressed block is ended and all data will be
output. If the current block is not a stored block, one or more
empty blocks are added after the current block to ensure that there
are at least 8 bits, counting from the start of the end-of-block code
of the current block to the end of the packet payload.
Дополнительные методы могут быть определены как указано в [SSH-ARCH] и
[SSH-NUMBERS].
6.3. Шифрование
Алгоритм шифрования и ключ будут согласованы во время обмена ключами
Когда шифрование задействовано, поля "packet length", "padding length",
"payload" и "padding" каждого пакеты ДОЛЖНЫ быть зашифрованы
данным алгоритмом.
Зашифрованные данные во всех пакетах отправляемых в одно направлении ДОЛЖНЫ быть
рассмотрены как единый поток данных. Например, векторы инициализации
ДОЛЖНЫ быть переданы с конца одного пакета на начало следующего пакета.
Все шифры ДОЛЖНЫ использовать ключи с длиной ключа 128 битов или более.
Шифры в каждом направлении ДОЛЖНЫ быть независимы друг от друга.
Реализации ОБЯЗАНЫ позволять алгоритмам в каждом направлении быть выбранными
независимо, если несколько алгоритмов разрешены локальной политикой.
Однако на практике, РЕКОМЕНДУЕТСЯ использовать один алгоритм в обоих направлениях.
В данный момент определены следующие шифры:
3des-cbc REQUIRED three-key 3DES in CBC mode
blowfish-cbc OPTIONAL Blowfish in CBC mode
twofish256-cbc OPTIONAL Twofish in CBC mode, with a 256-bit key
twofish-cbc OPTIONAL alias for "twofish256-cbc" (this is being retained for historical reasons)
twofish192-cbc OPTIONAL Twofish with a 192-bit key
twofish128-cbc OPTIONAL Twofish with a 128-bit key
aes256-cbc OPTIONAL AES in CBC mode, with a 256-bit key
aes192-cbc OPTIONAL AES with a 192-bit key
aes128-cbc RECOMMENDED AES with a 128-bit key
serpent256-cbc OPTIONAL Serpent in CBC mode, with a 256-bit key
serpent192-cbc OPTIONAL Serpent with a 192-bit key
serpent128-cbc OPTIONAL Serpent with a 128-bit key
arcfour OPTIONAL the ARCFOUR stream cipher with a 128-bit key
idea-cbc OPTIONAL IDEA in CBC mode
cast128-cbc OPTIONAL CAST-128 in CBC mode
none OPTIONAL no encryption; NOT RECOMMENDED
The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-
encrypt), where the first 8 bytes of the key are used for the first
encryption, the next 8 bytes for the decryption, and the following 8
bytes for the final encryption. This requires 24 bytes of key data
(of which 168 bits are actually used). To implement CBC mode, outer
chaining MUST be used (i.e., there is only one initialization
vector). This is a block cipher with 8-byte blocks. This algorithm
is defined in [FIPS-46-3]. Note that since this algorithm only has
an effective key length of 112 bits ([SCHNEIER]), it does not meet
the specifications that SSH encryption algorithms should use keys of
128 bits or more. However, this algorithm is still REQUIRED for
historical reasons; essentially, all known implementations at the
time of this writing support this algorithm, and it is commonly used
because it is the fundamental interoperable algorithm. At some
future time, it is expected that another algorithm, one with better
strength, will become so prevalent and ubiquitous that the use of
"3des-cbc" will be deprecated by another STANDARDS ACTION.
The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128-bit keys
[SCHNEIER]. This is a block cipher with 8-byte blocks.
The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode,
with 256-bit keys as described [TWOFISH]. This is a block cipher
with 16-byte blocks.
The "twofish192-cbc" cipher is the same as above, but with a 192-bit key.
The "twofish128-cbc" cipher is the same as above, but with a 128-bit key.
The "aes256-cbc" cipher is AES (Advanced Encryption Standard)
[FIPS-197], in CBC mode. This version uses a 256-bit key.
The "aes192-cbc" cipher is the same as above, but with a 192-bit key.
The "aes128-cbc" cipher is the same as above, but with a 128-bit key.
The "serpent256-cbc" cipher in CBC mode, with a 256-bit key as
described in the Serpent AES submission.
The "serpent192-cbc" cipher is the same as above, but with a 192-bit key.
The "serpent128-cbc" cipher is the same as above, but with a 128-bit key.
The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys.
The Arcfour cipher is believed to be compatible with the RC4 cipher
[SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and
should be used with caution.
The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER].
The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode with a
128-bit key [RFC2144].
Алгоритм "none" указывает что шифрование проводиться не должно.
Учтите, что этот метод не предоставляет защиту конфиденциальности и он
НЕ РЕКОМЕНДУЕТСЯ. Некоторые функции (например, парольная
аутентификация) может быть отключены из соображений безопасности если выбран
этот "шифр".
Дополнительные методы могут быть определены как указано в [SSH-ARCH]
и в [SSH-NUMBERS].
6.4. Целостность данных
Целостность данных защищается путём включения в каждый пакет MAC который
вычисляется из общего секретного ключа, порядкового номера пакета, и
содержимого пакета.
Алгоритм аутентификации сообщения и ключ согласовываются во время обмена
ключами. Первоначально, MAC не передаётся, и его длина ДОЛЖНА
быть нулевой. После обмена ключами, 'mac' для выбранного алгоритма MAC
будет вычисляться до шифрования путём состыковки данных пакета:
mac = MAC(key, sequence_number || unencrypted_packet)
где
unencrypted_packet - это весь пакет без поля 'mac' (the
length fields, 'payload' и 'random padding')
sequence_number - это изменяемый порядковый номер пакета представленный как uint32.
sequence_number изначально равен нулю для первого пакета и он
инкрементно увеличивается после каждого пакета (regardless of whether encryption or
MAC is in use). Он никогда не обнуляется, даже если ключи/алгоритмы позже
заново согласовываются. Он заново обнуляется после каждого 2^32 пакета.
sequence_number пакета не включается в сам пакет отсылаемый через кабель.
Алгоритм MAC для каждого направления ДОЛЖЕН быть независимым и
реализации ДОЛЖНЫ позволять выбрать алгоритм независимо для обоих
направлений. Однако на практике, РЕКОМЕНДУЕТСЯ использовать один и тот же
алгоритм для обоих направлений.
Значение 'mac' полученное из алгоритма MAC ДОЛЖНО быть
передано без шифрования как последняя часть пакета. Количество байтов
в 'mac' зависит от выбранного алгоритма.
В данный момент определены следующие алгоритмы MAC:
hmac-sha1 REQUIRED HMAC-SHA1 (длина дайджеста = длина ключа = 20)
hmac-sha1-96 RECOMMENDED первые 96 битов HMAC-SHA1 (длина дайджеста = 12, длина ключа = 20)
hmac-md5 OPTIONAL HMAC-MD5 (длина дайджеста = длина ключа = 16)
hmac-md5-96 OPTIONAL первые 96 битов HMAC-MD5 (длина дайджеста = 12, длина ключа = 16)
none OPTIONAL без MAC; NOT RECOMMENDED
Алгоритмы "hmac-*" описаны в [RFC2104].
MAC "*-n" используют только первые n битов из конечного значения.
SHA-1 описан в [FIPS-180-2] и MD5 описан в [RFC1321].
Дополнительные методы могут быть определены как указано в [SSH-ARCH] и в
[SSH-NUMBERS].
6.5. Методы обмена ключами
Метод обмена ключами определяет как генерируются одноразовые сессионные
ключи для шифрования и для аутентификации и как производится аутентификация
сервера.
Определены два НЕОБХОДИМЫХ метода обмена ключами:
diffie-hellman-group1-sha1 НЕОБХОДИМ
diffie-hellman-group14-sha1 НЕОБХОДИМ
Эти методы описаны в разделе 8.
Дополнительные методы могут быть определены как указано в [SSH-NUMBERS].
Имя "diffie-hellman-group1-sha1" используется для метода обмена ключами
использующего группы Oakley, как определено в [RFC2409]. SSH maintains its
own group identifier space that is logically distinct from Oakley
[RFC2412] and IKE; however, for one additional group, the Working
Group adopted the number assigned by [RFC3526], using diffie-
hellman-group14-sha1 for the name of the second defined group.
Implementations should treat these names as opaque identifiers and
should not assume any relationship between the groups used by SSH and
the groups defined for IKE.
6.6. Алгоритмы с открытым ключом
Этот протокол был разработан для работы с почти всеми форматами открытого
ключа, шифрования, и алгоритмами (подпись и/или шифрование).
Есть несколько аспектов которые определяют тип открытого ключа:
- Формат ключа: как закодирован ключ и как представлены сертификаты.
Двоичные данные ключа в данном протоколе МОГУТ содержать
сертификаты в дополнение к ключам.
- Подпись и/или алгоритмы шифрования. Некоторые типы ключей могут не
поддерживать подписывание и шифрование вместе. Использование ключа также может быть
ограничено политикой (например, в сертификатах). В этом
случае, различные типы ключей ДОЛЖНЫ быть определены для альтарнатив
разным политикам.
- Кодирование подписей и/или зашифрованных данных. This includes but
is not limited to padding, byte order, and data formats.
В данное время определены следующие форматы открытых ключей и/или сертификатов:
ssh-dss REQUIRED sign Raw DSS Key
ssh-rsa RECOMMENDED sign Raw RSA Key
pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key)
pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key)
Дополнительные типы ключей могут быть определены как указано в [SSH-ARCH]
и в [SSH-NUMBERS].
Тип ключа ДОЛЖЕН всегда быть явно обозначен (из согласования
алгоритма или какого-либо другого источника). It is not normally included в
двоичные данные ключа.
Сертификаты и открытые ключи кодируются следующим образом:
string идентификатор формата сертификата или открытого ключа
byte[n] данные ключа/сертификата
Часть относящаяся к сертификату может быть строкой нулевой длины, но открытый ключ
обязателен. Это открытый ключ который будет использоваться для
аутентификации. Последовательность сертификата содержащаяся в двоичных данных
сертификата может быть использована для проведения авторизации.
Форматы открытого ключа/сертификата that do not explicitly specify a
signature format identifier MUST use the public key/certificate
format identifier as the signature identifier.
Подписи кодируются следующим образом:
string идентификатор формата подписи (как определено форматом
открытого ключа/сертификата)
byte[n] двоичные данные подписи в определённом формате кодирования.
Формат ключа "ssh-dss" имеет следующее специфическое кодирование:
string "ssh-dss"
mpint p
mpint q
mpint g
mpint y
Здесь, параметры 'p', 'q', 'g' и 'y' формируют двоичные данные подписи.
Подписывание и проверка при использовании этого формата ключа делается согласно
Digital Signature Standard [FIPS-186-2] при использовании хеша SHA-1
[FIPS-180-2].
Результирующая подпись кодируется следующим образом:
string "ssh-dss"
string dss_signature_blob
Значение для 'dss_signature_blob' кодируется как строка содержащая r,
следующая s (которые являются 160-битными целыми, не включая длины
padding, unsigned, и в сетевом порядке байтов).
Формат ключа "ssh-rsa" имеет следующую специфическую кодировку:
string "ssh-rsa"
mpint e
mpint n
Здесь 'e' и 'n' параметры формирующие двоичные данные ключевой подписи.
Подписание и проверка используя этот формат ключа осуществляется в соответствии
со схемой RSASSA-PKCS1-v1_5 в [RFC3447] при использовании
хеша SHA-1.
The resulting signature is encoded as follows:
string "ssh-rsa"
string rsa_signature_blob
Значение для 'rsa_signature_blob' кодируется как строка содержащая
s (which is an integer, without lengths or padding, unsigned, and in
network byte order).
The "pgp-sign-rsa" method indicates the certificates, the public key,
and the signature are in OpenPGP compatible binary format
([RFC2440]). This method indicates that the key is an RSA-key.
The "pgp-sign-dss" is as above, but indicates that the key is a
DSS-key.
7. Обмен ключами
Обмен ключами (kex) начинается с отправки каждой стороной именованных списков
поддерживаемых алгоритмов. Каждая сторона имеет предпочтительный алгоритм в каждой
категории, и предполагается, что большинство реализаций, в любой момент
времени, будут использовать тот же предпочтительный алгоритм.
Каждая сторона МОЖЕТ предположить какой алгоритм использует другая сторона
и МОЖЕТ послать первый пакет передачи ключа согласно алгоритму, если
соответствует для предпочтительного метода.
Предположение считается неверным если:
- алгоритм обмена ключами (kex) и/или алгоритм ключа хоста не угадан
(сервер и клиент имеют разные предпочитаемые алгоритмы), или
- если любой из других алгоритмов не могут быть согласованы
(процедура описана в разделе 7.1).
Иначе, предположение считается верным и оптимистично отправленный
пакет ДОЛЖЕН быть обработан как первый пакет передачи ключа.
Однако, если предположение было неверным и пакет был оптимистично послан
одной или обеими сторонами, такой пакет ДОЛЖЕН быть проигнорирован (даже если
ошибка в предположении не затронула содержимое начального
пакета(ов)) и соответствующая сторона ДОЛЖНА послать корректный начальный
пакет.
Метод обмена ключами использует явную аутентификацию сервера, если сообщение
передачи ключа включает подпись или другое доказательство подлинности
сервера.
Метод обмена ключами использует неявную аутентификацию
сервера если для того чтобы доказать свою подлинность, сервер
также должен доказать что он знает общий секрет, K, путём отправки
сообщения и соответствующего MAC который клиент пожет проверить.
Метод обмена ключами, описанный в этом документе использует явную аутентификацию
сервера. Однако, методы передачи ключа с неявной аутентификацией
сервера МОГУТ быть использованы с данным протоколом. После передачи ключа
с неявной аутентификацией сервера, слиент ОБЯЗАН ждать
ответа на его сообщение запроса сервиса message прежде чем посылать любые
последующие данные.
7.1. Согласование алгоритма
Обмен ключами начинается каждой стороной с отправки следующего пакета:
byte SSH_MSG_KEXINIT (id 20)
byte[16] cookie (random bytes)
name-list kex_algorithms
name-list server_host_key_algorithms
name-list encryption_algorithms_client_to_server
name-list encryption_algorithms_server_to_client
name-list mac_algorithms_client_to_server
name-list mac_algorithms_server_to_client
name-list compression_algorithms_client_to_server
name-list compression_algorithms_server_to_client
name-list languages_client_to_server
name-list languages_server_to_client
boolean first_kex_packet_follows
uint32 0 (reserved for future extension)
Имена алгоритмов в каждом списке должны разделяться запятой
(смотри имена алгоритмов в [SSH-ARCH] и дополнительную
информацию в [SSH-NUMBERS]). Каждый поддерживаемый (разрешённый) алгоритм
ДОЛЖЕН быть перечислен в порядке предпочтения, от наиболее предпочитаемого
к менее предпочитаемому.
Первый алгоритм в каждом именованном списке ДОЛЖЕН быть предпочитаемым (предполагаемым)
алгоритмом. Каждый именованный список ДОЛЖЕН содержать как минимум одно имя алгоритма.
cookie
ДОЛЖЕН быть случайным значением генерируемым отправителем.
Его назначение сделать невозможным любой стороной полностью
определять ключи и идентификатор сессии.
kex_algorithms
Алгоритмы обмена ключами были определены выше. Первый алгоритм
ДОЛЖЕН быть предпочтительным (и предполагаемым) алгоритмом. Если
обе стороны сделают одинаковые предположения, то алгоритм ДОЛЖЕН быть использован.
Иначе, для выбора метода обмена ключами ДОЛЖЕН быть использован
следующий алгоритм:
Перебрать все клиентсткие алгоритмы обмена ключей по одному за раз.
Выбрать первый алгоритм который удовлетворяет следующим условиям:
+ сервер также поддерживает алгоритм,
+ if the algorithm requires an encryption-capable host key,
there is an encryption-capable algorithm on the server's
server_host_key_algorithms который также поддерживается клиентом,
+ if the algorithm requires a signature-capable host key,
there is a signature-capable algorithm on the server's
server_host_key_algorithms который также поддерживается клиентом.
Если алгоритм удовлятворяющий эти требования не найден, то
соединение терпит неудачу, и обе стороны ДОЛЖНЫ разъединиться.
server_host_key_algorithms
Список алгоритмов поддерживаемых ключом хоста сервера.
Сервер перечисляет алгоритмы для которых он имеет ключ хоста;
клиент перечисляет алгоритм которые он хочет использовать.
Для хоста МОЖНО использовать несколько ключей хоста, возможно
с различными алгоритмами.
Некоторые ключи хоста могут не поддерживать одновременно подпись
и шифрование (это можно определить по алгоритму), и поэтому не все
ключи хоста годятся для всех методов обмена ключа.
Выбор алгоритма зависит от того требуется ли выбранному алгоритму
обмена ключами подпись или пригодный для шифрования ключ хоста.
ДОЛЖНО быть возможный вяснить это из имени алгоритма открытого ключа.
Первый алгоритм из списка клиента который соответствует требованиям
а также поддерживается сервером ДОЛЖЕН быть выбран. Если такого
алгоритма нет, то обе стороны должны разъединиться.
encryption_algorithms
Именованный список приемлимых симметричных алгоритмов шифрования (также
известных как ciphers) в порядке предпочтения. Выбранный
алгоритм шифрования для каждого направления ДОЛЖЕН быть первым
алгоритмом в именованном списке клиента, который также находится в
именованном списке сервера. Если такого алгоритма не найдено, обе стороны
ОБЯЗАНЫ разъединиться.
Помните, что "none" должно быть явно указано в списке если оно должно быть
приемлимо. Определённые имена алгоритмов перечислены в списке раздела 6.3.
mac_algorithms
Именованный список приемлимых алгоритмов MAC в порядке предпочтения.
Избранный алгоритм MAC ДОЛЖЕН быть первым
алгоритмом в клиентском списке который также присутствует в списке
сервера (Приоритет отдаётся списку клиента). Если такого алгоритма нет,
то обе стороны ОБЯЗАНЫ разъединиться.
Помните что алгоритм "none" должен быть явно обозначен в списке если он
должен приниматься. Имена алгоритмов MAC перечислены в разделе 6.4.
compression_algorithms
Список приемлимых алгоритмов сжатия в порядке предпочтения.
Избранный алгоритм сжатия ДОЛЖЕН быть первым
алгоритмом в списке клиента который также находится в списке сервера.
Если такого алгоритма нет, то обе стороны ОБЯЗАНЫ разъединиться.
Помните что алгоритм "none" должен быть явно обозначен в списке если он
должен приниматься. Имена алгоритмов сжатия перечислены в разделе 6.2.
languages
Это список языковых меток в порядке предпочтения [RFC3066].
Обе стороны МОГУТ игнорировать этот список. Если
предпочитаемых языков нет, этот список ДОЛЖЕН быть пуст как
определено в разделе 5 [SSH-ARCH]. Метки языков НЕ ДОЛЖНЫ
присутствовать до тех пор пока не будет изветно что они нужны
отправляющей стороне.
first_kex_packet_follows
Indicates whether a guessed key exchange packet follows. If a
guessed packet will be sent, this MUST be TRUE. If no guessed
packet will be sent, this MUST be FALSE.
После получения пакета SSH_MSG_KEXINIT от другой стороны,
каждая сторона будет знать было ли их предположение правильным. Если
предположение другой стороны было неправильным и это поле было равно TRUE,
следующий пакет ДОЛЖЕН быть молча проигнорирован и обе стороны ДОЛЖНЫ тогда
действовать как определено согласованным методом обмена ключа. Если
предположение было правильным, обмен ключом ДОЛЖЕН продолжиться используя
угаданный пакет. (?!?)
После обмена сообщением SSH_MSG_KEXINIT, выполняется
алгоритм обмена ключом. Он может включать несколько обменов пакетами, как
определено методом обмена ключа.
Как только сторона отослала сообщение SSH_MSG_KEXINIT для обмена ключа или
повторного обмена ключа, до тех пор пока она не пошлёт сообщение SSH_MSG_NEWKEYS
(раздел 7.3)она НЕ ДОЛЖНЫ посылать сообщения отличные от:
o Общие сообщения транспортного уровня (1 to 19) (но
SSH_MSG_SERVICE_REQUEST и SSH_MSG_SERVICE_ACCEPT НЕ ДОЛЖНЫ быть отправлены);
o Algorithm negotiation messages (20 to 29) (but further
SSH_MSG_KEXINIT messages MUST NOT be sent);
o Specific key exchange method messages (30 to 49).
Положения раздела 11 применяются к нераспознанным сообщениям.
Однако учтите, что во время повторного обмена ключами после отправки
сообщения SSH_MSG_KEXINIT, каждая сторона ДОЛЖНА быть готова обработать
произвольное количество сообщений которые могут находиться в пути до получения
сообщения SSH_MSG_KEXINIT от другой стороны.
7.2. Получаемые значения
Обмен ключами создаёт два значения:
общий секретный ключ K и хеш передачи H.
Ключи шифрования и аутентификации получаются из них.
Хеш передачи H из первой передачи ключа
дополнительно используется как идентификатор сессии, который является уникальным
идентификатором для этого подключения. Он используется методами аутентификации
как часть данных которая подписывается в целях доказательства владения
секретным ключом. Единожды вычисленный, идентификатор сессии не изменяется,
даже если ключи позже снова пройдут процедуру передачи ключа.
Каждый метод обмена ключами определяет функцию хеширования которая используется в
передаче ключа. Тот же алгоритм хеширования ДОЛЖЕН быть использован в key
derivation. Здесь мы назовём это HASH.
Ключи шифрования ДОЛЖНЫ быть вычислены как HASH, из известного значения и K,
следующим образом:
o Initial IV client to server: HASH(K || H || "A" || session_id)
(здесь K кодируется как mpint и "A" как byte и session_id как raw
data. Под "A" подразумевается символ A, ASCII 65).
o Initial IV server to client: HASH(K || H || "B" || session_id)
o Encryption key client to server: HASH(K || H || "C" || session_id)
o Encryption key server to client: HASH(K || H || "D" || session_id)
o Integrity key client to server: HASH(K || H || "E" || session_id)
o Integrity key server to client: HASH(K || H || "F" || session_id)
Данные ключа ДОЛЖНЫ быть взяты из начала полученного значения хеша.
Из начала значения хеша берётся столько байт сколько нужно.
Если необходимая длина ключа больше чем результат HASH, то
ключ увеличивается путём вычисления HASH of the concatenation of K and H and
the entire key so far, and appending the resulting bytes (as many as
HASH generates) to the key. This process is repeated until enough
key material is available; the key is taken from the beginning of
this value.
Другими словами:
K1 = HASH(K || H || X || session_id) (X это например, "A")
K2 = HASH(K || H || K1)
K3 = HASH(K || H || K1 || K2)
...
key = K1 || K2 || K3 || ...
This process will lose entropy if the amount of entropy in K is
larger than the internal state size of HASH.
7.3. Использование ключей
Обмен ключами заканчивается когда каждой стороной посылается сообщение SSH_MSG_NEWKEYS.
Это сообщение посылается используя старые ключами и алгоритмы. Все сообщения
посылаемые после этого сообщения ОБЯЗАНЫ использовать новые ключи и алгоритмы.
Когда это сообщение получено, новые ключи и алгоритмы ДОЛЖНЫ быть
использованы для приёма.
Назначение данного сообщения удостовериться в том что другая сторона может
ответить сообщением SSH_MSG_DISCONNECT по которому другая сторона может
понять если что-то пойдёт не так с обменом ключами.
byte SSH_MSG_NEWKEYS (id 21)
8. Обмен ключами по алгоритму Diffie-Hellman
Передача ключа Diffie-Hellman (DH) provides a shared secret that
cannot be determined by either party alone. The key exchange is
combined with a signature with the host key для выполнения аутентификации
хоста. Этот метод передачи ключа предоставляет явную аутентификацию
сервера как описано в разделе 7.
Следующие шаги используются для передачи ключа.
Здесь,
C - клиент;
S - сервер;
p - большое безопасное (сделать ссылку на определение) простое число;
g - генератор for a subgroup of GF(p);
q - the order of the subgroup;
V_S - идентификационная строка сервера;
V_C - идентификационная строка клиента;
K_S - открытый ключ хоста сервера;
I_C is C's SSH_MSG_KEXINIT message
I_S is S's SSH_MSG_KEXINIT message that have been exchanged before this part begins.
1. C генерирует случайное число x (1 < x < q) и вычисляет
e = g^x mod p.
C посылает e на S.
2. S генерирует случайное число y (0 < y < q) и вычисляет f = g^y mod p.
S receives e. Он вычисляет K = e^y mod p,
H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K)
(эти элементы закодированы согласно их типам; смотри ниже),
и ставит подпись s на H своим секретным ключом хоста.
S посылает (K_S || f || s) на C.
The signing operation may involve a second hashing operation.
3. C проверяет является ли K_S ключом хоста для S (e.g., using
certificates or a local database). C также позволено принимать
ключ без проверки; however, doing so will render the
protocol insecure against active attacks (but may be desirable for
practical reasons in the short term in many environments).
C вычисляет K = f^x mod p,
вычисляет H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K)
и проверяет подпись s на H сверяя с тем что прислал сервер.
Значения 'e' или 'f' которые не находятся в диапазоне [1, p-1] НЕ ДОЛЖНЫ быть
посланы или приняты любой стороной. Если это условие нарушено, то
передача ключа терпит неудачу.
This is implemented with the following messages. Алгоритм хеширования
для вычисления хеша передачи определяется именем метода и он
называется HASH. Алгоритм открытого ключа для подписывания согласовывается в
сообщении SSH_MSG_KEXINIT.
Сначала клиент послылает:
byte SSH_MSG_KEXDH_INIT (id 32)
mpint e
Сервер отвечает:
byte SSH_MSG_KEXDH_REPLY (id 33)
string открытый ключ и сертификаты сервера (K_S)
mpint f
string подпись значения H
Хеш вычисляется как the HASH hash of the concatenation of the following:
string V_C, идентификационная строка клиента (без CR и LF)
string V_S, идентификационная строка сервера (без CR и LF)
string I_C, полезная нагрузка "payload" клиентского SSH_MSG_KEXINIT
string I_S, полезная нагрузка "payload" серверного SSH_MSG_KEXINIT
string K_S, ключ хоста
mpint e, значение обмена посылаемое клиентом
mpint f, значение обмена посылаемое сервером
mpint K, общий секрет
Это значение называется хешем передачи и оно используется для
аутентификации обмена ключами. Хеш передачи ДОЛЖЕН храниться в секрете.
The signature algorithm MUST be applied over H, not the original
data. Most signature algorithms include hashing and additional
padding (e.g., "ssh-dss" specifies SHA-1 hashing). In that case, the
data is first hashed with HASH to compute H, and H is then hashed
with SHA-1 as part of the signing operation.
8.1. diffie-hellman-group1-sha1
The "diffie-hellman-group1-sha1" method specifies the Diffie-Hellman
key exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024-
bit MODP Group). This method MUST be supported for interoperability
as all of the known implementations currently support it. Note that
this method is named using the phrase "group1", even though it
specifies the use of Oakley Group 2.
8.2. diffie-hellman-group14-sha1
The "diffie-hellman-group14-sha1" method specifies a Diffie-Hellman
key exchange with SHA-1 as HASH and Oakley Group 14 [RFC3526] (2048-
bit MODP Group), and it MUST also be supported.
9. Повторный обмен ключами
Повторный обмен ключами начинается отправкой пакета SSH_MSG_KEXINIT when
not already doing a key exchange (раздел 7.1). Когда
это сообщение получено, участник ДОЛЖЕН ответить своим собственным
сообщением SSH_MSG_KEXINIT, за исключением когда полученный SSH_MSG_KEXINIT
сам является ответом. Любая сторона МОЖЕТ инициировать повторный обмен, но
роли НЕ ДОЛЖНЫ быть изменены (i.e., the server remains the server, and
the client remains the client).
Повторый обмен ключами выполняется using whatever encryption was in effect
when the exchange was started. Методы шифрования, сжатия и MAC
не меняются пока новый SSH_MSG_NEWKEYS будет отправлен после
обмена ключами (как в первоначальном обмене ключами). Повторный обмен
выполняется идентично начальному обмену ключами, за исключением
идентификатора сессии, который должен остаться неизменённым. It is permissible to
change some or all of the algorithms during the re-exchange. Host
keys can also change. Все ключи и векторы инициализации
расчитываются повторно после обмена. Compression and encryption contexts
are reset.
РЕКОМЕНДУЕТСЯ чтобы ключи были изменены после каждого гигабайта
переданных данных или после каждого часа времени подключения, в зависимости
что наступит быстрее. However, since the re-exchange is a public key
operation, it requires a fair amount of processing power and should
not be performed too often.
More application data may be sent after the SSH_MSG_NEWKEYS packet
has been sent; key exchange does not affect the protocols that lie
above the SSH transport layer.
10. Запрос сервиса
После обмена ключами клиент запрашивает сервис. Сервис
идентифицируется по имени. Форматы имён и процедур для определения
новых имён описаны в [SSH-ARCH] and [SSH-NUMBERS].
В данный момент зарезервированы следующие имена:
ssh-userauth
ssh-connection
Similar local naming policy is applied to the service names, as is
applied to the algorithm names. A local service should use the
PRIVATE USE syntax of "servicename@domain".
byte SSH_MSG_SERVICE_REQUEST (id 5)
string service name
Если сервер отклоняет запрос сервиса, то он ДОЛЖЕН послать
соответствующее сообщение SSH_MSG_DISCONNECT и ДОЛЖЕН отключиться.
Когда сервис запускается, он может получать доступ к идентификатору сессии
сгенерированному во время обмена ключами.
Если сервер поддерживает сервис (и разрешает клиенту использовать
его), он ДОЛЖЕН ответить следующим образом:
byte SSH_MSG_SERVICE_ACCEPT (id 6)
string service name
Message numbers used by services should be in the area reserved for
them (see [SSH-ARCH] and [SSH-NUMBERS]). The transport level will
continue to process its own messages.
Note that after a key exchange with implicit server authentication,
the client MUST wait for a response to its service request message
before sending any further data.
11. Additional Messages
Either party may send any of the following messages at any time.
11.1. Disconnection Message
byte SSH_MSG_DISCONNECT (id 1)
uint32 код причины
string описание причины в кодировке ISO-10646 UTF-8 [RFC3629]
string language tag [RFC3066]
Это сообщение означает немедленный разрыв соединения. Все
реализации ОБЯЗАНЫ уметь обрабатывать это сообщение; они ДОЛЖНЫ быть
в состоянии отправить это сообщение.
Отправитель НЕ ДОЛЖЕН отправлять или принимать любые данные после этого сообщения и
получатель НЕ ДОЛЖЕН принимать любые данные после получения этого сообщения.
The Disconnection Message 'description' string gives a more specific
explanation in a human-readable form. The Disconnection Message
'reason code' gives the reason in a more machine-readable format
(suitable for localization), and can have the values as displayed in
the table below. Note that the decimal representation is displayed
in this table for readability, but the values are actually uint32
values.
Symbolic name reason code
------------- -----------
SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1
SSH_DISCONNECT_PROTOCOL_ERROR 2
SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3
SSH_DISCONNECT_RESERVED 4
SSH_DISCONNECT_MAC_ERROR 5
SSH_DISCONNECT_COMPRESSION_ERROR 6
SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7
SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8
SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9
SSH_DISCONNECT_CONNECTION_LOST 10
SSH_DISCONNECT_BY_APPLICATION 11
SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12
SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13
SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14
SSH_DISCONNECT_ILLEGAL_USER_NAME 15
If the 'description' string is displayed, the control character
filtering discussed in [SSH-ARCH] should be used to avoid attacks by
sending terminal control characters.
Requests for assignments of new Disconnection Message 'reason code'
values (and associated 'description' text) in the range of 0x00000010
to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as
described in [RFC2434]. The Disconnection Message 'reason code'
values in the range of 0xFE000000 through 0xFFFFFFFF are reserved for
PRIVATE USE. As noted, the actual instructions to the IANA are in
[SSH-NUMBERS].
11.2. Ignored Data Message
byte SSH_MSG_IGNORE (id 2)
string data
Все реализации ДОЛЖНЫ понимать (и игнорировать) это сообщение в любое
время (после получения идентификационной строки). Реализациям нет
необходимости отправлять их. Это сообщение может быть использовано как
дополнительная мера защиты против продвинутых способов анализа трафика.
11.3. Debug Message
byte SSH_MSG_DEBUG (id 4)
boolean always_display
string сообщение в кодировке ISO-10646 UTF-8 [RFC3629]
string метка языка [RFC3066]
Все реализации ДОЛЖНЫ понимать это сообщение, но им
разрешено игнорировать их. Это сообщение используется для передачи информации
которая может помочь отладке. Если 'always_display' равно TRUE, сообщение
СЛЕДУТ отобразить. В обратном случае, его НЕ СЛЕДУЕТ отображать пока
отладочная информация не будет явно запрошена пользователем.
Поле 'message' не требует наличия новой строки. Но однако,
разрешено состоять из нескольких строк разделённых парами <CR><LF> (Carriage
Return - Line Feed).
Если строка 'message' отображена, то должна использоваться фильтрация
управляющих символов как обсуждалось в [SSH-ARCH] для избегания атак путём
отправки управляющих символов терминала.
11.4. Зарезервированные сообщения
Реализация ДОЛЖНА отвечать на все нераспознанные сообщения сообщением
SSH_MSG_UNIMPLEMENTED в порядке, в котором сообщения были получены.
В противном случае, такие сообщения ДОЛЖНЫ быть проигнорированы. Следующие
версии протокола могут определить другое предназначение для этого типа
сообщений.
byte SSH_MSG_UNIMPLEMENTED
uint32 порядковый номер пакета отклонённого сообщения
12. Summary of Message Numbers
The following is a summary of messages and their associated message
number.
SSH_MSG_DISCONNECT 1
SSH_MSG_IGNORE 2
SSH_MSG_UNIMPLEMENTED 3
SSH_MSG_DEBUG 4
SSH_MSG_SERVICE_REQUEST 5
SSH_MSG_SERVICE_ACCEPT 6
SSH_MSG_KEXINIT 20
SSH_MSG_NEWKEYS 21
Note that numbers 30-49 are used for kex packets. Different kex
methods may reuse message numbers in this range.
13. IANA Considerations
Этот документ является частью набора. The IANA considerations для протокола
SSH определенные в [SSH-ARCH], [SSH-USERAUTH], [SSH-CONNECT] и в этом
документе, детально изложены в [SSH-NUMBERS].
14. Security Considerations
Этот протокол создаёт безопасный зашифрованный канал через небезопасную
сеть. Он выполняет аутентификацию хоста сервера, обмен ключами,
шифрование и защиту целостности. Он также производит уникальный
ID сессии который может быть использован вышележащими протоколами.
Все аспекты безопасности для этого протокола представлены в [SSH-ARCH].
15. Ссылки
15.1. Normative References
[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Protocol Architecture", RFC 4251, 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 4250, January
2006.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
1321, April 1992.
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC
2144, May 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R.
Thayer, "OpenPGP Message Format", RFC 2440, November
1998.
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential
(MODP) Diffie-Hellman groups for Internet Key Exchange
(IKE)", RFC 3526, May 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[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.
[FIPS-46-3] US National Institute of Standards and Technology,
"Data Encryption Standard (DES)", Federal Information
Processing Standards Publication 46-3, October 1999.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols algorithms and source in code in C", John
Wiley and Sons, New York, NY, 1996.
[TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A
128-Bit Block Cipher, 1st Edition", March 1999.
15.2. Informative References
[RFC0894] Hornig, C., "Standard for the transmission of IP
datagrams over Ethernet networks", STD 41, RFC 894,
April 1984.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.
[ssh-1.2.30] Ylonen, T., "ssh-1.2.30/RFC", File within compressed
tarball ftp://ftp.funet.fi/pub/unix/security/
login/ssh/ssh-1.2.30.tar.gz, November 1995.
Поддержите проект, если он помог вам
Проект продвигается за счёт личных средств и времени авторского коллектива. Если вы нашли здесь то, что искали, то вы можете выразить свою благодарность финансово. Даже небольшой платёж помогает авторам в их труде, сохраняя их вовлечённость и высокую мотивацию чтобы строить открытый мир равных возможностей для всех неравнодушных людей вокруг.