Rekey SSH меняет транспортные ключи, сохраняя контекст соединения
Фотография конкретного исполнения не приложена.
Длительный административный сеанс может кратко остановить полезную передачу во время key re-exchange. Это не обязательно повторный login или разрыв приложения. Для анализа нужно различать обслуживание transport keys и жизненный цикл пользовательской session.
RFC 4253 предусматривает повторный key exchange. Session identifier, полученный при первом обмене, при этом не меняется. Ротация transport keys сама по себе не выполняет заново все методы user authentication и не выдаёт пользователю новые прикладные права.
Поведение буферов и задержек зависит от реализации и нагрузки. Наличие rekey не доказывает применение нового host key из файлов после обслуживания сервера. Также периодическая смена transport keys не заменяет правила срока доступа учётной записи.
В приёмке сопоставляют события rekey с непрерывностью channels и результатом длительной операции. Отдельно проверяют политику завершения пользовательского доступа. Отчёт должен назвать, что именно обновилось. Один успешный rekey не подтверждает повторную аутентификацию пользователя или переход соединения на новый набор административных разрешений.
Основание — Numbered SSH RFCs with historical base mechanics and scoped later extensions; not complete current cryptographic allowlist, разделы RFC4253 7.2 Session identifier;9 Key Re-Exchange. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — указанные номерные RFC SSH. Базовые документы 2006 года используются для семантики протокола, а не как полный актуальный список разрешённых алгоритмов. Реальные версии клиента/сервера, ключи и политика доступа не проверялись; команды, подключения и forwarding не выполнялись.
Запросы отправляются на наш e-mail из вашей почтовой программы.
