Кратко

  • Первый обмен ключами создаёт общий секрет K и хеш H. Именно первый H, вычисленный из реального согласования, становится идентификатором соединения.
  • Rekey может заменить алгоритмы, трафиковые ключи, векторы, контексты и даже ключ хоста. Исходный идентификатор сеанса при этом остаётся прежним.
  • При входе по открытому ключу подпись охватывает идентификатор, пользователя, сервис, метод, алгоритм и ключ. Это мешает перенести подпись в другое соединение, но не выдаёт разрешение на shell или проброс порта.

У разговора и его защиты был разный срок жизни

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

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

RFC 4251 разделил SSH 2 на транспорт, аутентификацию пользователя и протокол соединения. Транспорт проверяет сервер и защищает поток. Выше клиент доказывает пользователя. Затем соединение мультиплексирует логические каналы для shell, подсистем и перенаправлений. Rekey меняет защитный слой и не получает права молча перезапустить верхние.

Имя соединения получалось из событий

Клиент и сервер отправляют SSH_MSG_KEXINIT: случайную cookie и упорядоченные списки методов обмена, ключей хоста, шифров, целостности и сжатия. Выбор следует предпочтениям клиента и останавливается на первом варианте, который поддерживает сервер и допускают правила метода.

Согласованный обмен вычисляет общий секрет K и хеш H. В исходной схеме Diffie–Hellman для SSH 2 в H входят строки версий, обе необработанные полезные нагрузки KEXINIT, публичный ключ сервера, эфемерные значения сторон и общий секрет.

Другая версия, заявка алгоритмов, ключ хоста или временное значение дают другую стенограмму. Хеш не является номером, который сервер выдаёт из реестра, и не является меткой клиента. Оба участника оставляют материал в его вычислении.

Случайные cookie не позволяют одной стороне полностью предопределить ключи и идентификатор. Но сам идентификатор не секретен: знание значения не раскрывает K и не позволяет создать правильное шифрование или MAC.

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

Только первый H стал идентификатором сеанса

RFC 4253 использует K и H для вывода ключей и векторов. В первом обмене H получает дополнительную роль session_id. После этого значение не меняется до конца соединения.

Сам rekey может быть глубоким. Его начинает любая сторона. Алгоритмы и ключ хоста могут смениться. Все ключи и векторы вычисляются заново; контексты шифрования и сжатия сбрасываются после SSH_MSG_NEWKEYS. Новый обмен имеет собственные K и H, однако верхние уровни продолжают ссылаться на первый хеш.

Постоянство не делает изменения несущественными. Неожиданный ключ хоста требует решения о доверии, слабый метод может нарушать политику, ошибка завершит соединение. Инвариант утверждает меньше: успешное обновление транспорта само по себе не создаёт новую пользовательскую сессию.

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

Подпись пользователя включала и контекст, и запрос

RFC 4252 не ограничил подпись publickey именем пользователя. Подписываемые байты начинаются с идентификатора сеанса, затем содержат SSH_MSG_USERAUTH_REQUEST, пользователя, сервис, имя метода, логическое значение, алгоритм открытого ключа и сам ключ.

Записанная в соединении A подпись не проходит в B: первый хеш там иной. Незаметно заменить учётную запись, сервис, метод или алгоритм тоже нельзя. Доказательство имеет узкий смысл: владелец закрытого ключа подтвердил этот конкретный запрос в этом соединении.

У сервера остаются отдельные решения. Верна ли подпись? Разрешён ли ключ для заявленного пользователя? Нужен ли ещё один фактор? Математически правильная подпись не обязана заканчивать аутентификацию.

Метод hostbased связывает с сеансом также имя клиентского хоста и локального пользователя. Владение ключом машины не заменяет проверку её имени и права человека на вход.

Успешный вход не разрешал все будущие каналы

После SSH_MSG_USERAUTH_SUCCESS запускается запрошенный сервис. Однако shell, файловая подсистема, проброс порта, доступ к агенту и соединение с конкретной целью требуют последующих локальных решений.

Многие из них нельзя принять во время входа: клиент ещё не сообщил, какой канал откроет. Идентификатор даёт верхним слоям контекст, а не полномочия. Он сообщает, к какому защищённому разговору относится доказательство, но не одобряет каждое действие в нём.

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

Алгоритмы старели, а распределение полномочий сохранялось

Не все варианты 2006 года могли остаться пригодными. RFC 8332 добавил подписи RSA с SHA-256 и SHA-512 для сервера и клиента. Существующий RSA-ключ мог сохранить формат ssh-rsa, а новое имя выбирало более сильную процедуру подписи. Материал ключа, алгоритм и подписываемое утверждение оставались разными объектами.

RFC 9142 позднее изменил рекомендации KEX и отодвинул методы на SHA-1. Начальный обмен можно было модернизировать без переноса архитектурной границы: его первый хеш по-прежнему фиксировал контекст верхних доказательств.

Точное связывание не лечит плохое начало. Если клиент доверился неправильному ключу хоста или допустил слабый обмен, дальнейшие события будут надёжно привязаны к этой ошибке. Непрерывность и качество не совпадают.

Пять сущностей не образовывали одну «идентичность SSH»

Имя хоста выражает желаемое назначение. Ключ хоста — криптографический субъект, который надо связать с именем. Хеш описывает один обмен. Первый хеш задаёт контекст соединения. Ключ пользователя доказывает владение для запроса. Локальная политика разрешает действия.

RFC устанавливают эти значения и историю алгоритмов. Они не показывают, проверяет ли конкретный клиент ключ, когда сервер делает rekey, исчез ли SHA-1 и какая команда реально выполнилась.

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