jsonscraper

GitHub включает постквантовый SSH-обмен ключами — пока не в США

С 14 октября GitHub принимает новые RSA-ключи от 3072 бит и начинает включать ML-KEM для SSH. Разбираем, что администраторам стоит проверить сегодня.

Редакционная политика Сообщить об ошибке

Сегодня, 14 октября 2026 года, GitHub начала применять два изменения для SSH: новые загружаемые RSA-ключи должны иметь длину не менее 3072 бит, а для части подключений включается постквантовый алгоритм обмена ключами mlkem768x25519-sha256. Изменения относятся к SSH-соединениям; пользователям Git по HTTPS менять настройки из-за этого объявления не требуется.

Article: GitHub включает постквантовый SSH-обмен ключами — пока не в США
Summary: 14 октября GitHub ввела минимум 3072 бит для новых RSA SSH-ключей и начала включать постквантовый алгоритм обмена ключами ML-KEM на github.com и части GitHub Enterprise Cloud. Для пользователей в США это включение пока исключено.
Image role: cover — the central idea
Section: 
Visual subject: SSH key exchange visualization with quantum-resistant lattice cryptography represented by geometric ML-KEM key packets moving
© jsonscraper · AI-generated illustration

В объявлении GitHub от 22 сентября указано, что алгоритм становится доступен на github.com и GitHub Enterprise Cloud с Data Residency, за исключением региона США. Это начало поддержки со стороны платформы: фактическое использование нового алгоритма зависит также от SSH-клиента и его настроек.

Что именно меняется

Для новых RSA SSH-ключей, загружаемых после 14 октября, установлен минимум 3072 бита. Уже существующие RSA-ключи менять только из-за длины не требуется: GitHub рекомендует использовать с ними подписи RSA-SHA-2 — rsa-sha2-256 или rsa-sha2-512. В документации компания также рекомендует Ed25519 для новых ключей, когда этот тип подходит рабочей среде.

Второе изменение касается согласования ключа сессии. mlkem768x25519-sha256 сочетает ML-KEM — постквантовый алгоритм инкапсуляции ключей — с X25519. По плану GitHub, совместимые клиенты, настроенные предпочитать этот алгоритм, смогут выбирать его автоматически. Старые клиенты должны переходить к поддерживаемому алгоритму совместимости.

Что проверить в команде

  1. Определить способ подключения. Проверьте адреса Git remote: записи, начинающиеся с https://, не затрагиваются SSH-изменениями. Для SSH проверьте используемые клиенты, библиотеки и интеграции.
  2. Проверить RSA-подписи. Убедитесь, что клиент и используемая библиотека поддерживают RSA-SHA-2. GitHub указывает минимальные версии популярных реализаций, включая OpenSSH 7.2p1, Go SSH 0.16.0 и libssh2 1.11.0.
  3. Проверить новые ключи. Если политика организации требует RSA, новый ключ должен быть не короче 3072 бит. Для уже загруженного RSA-ключа важнее поддержка алгоритма подписи, а не генерация замены только ради этого изменения.
  4. Проверить клиентскую поддержку ML-KEM. Обновление платформы само по себе не гарантирует, что конкретный клиент выберет новый обмен ключами. Сначала проверьте его документацию и поведение в тестовом подключении; для старых клиентов планируйте обновление по принятому в организации графику.

Есть и отдельный этап, который начнётся позднее: GitHub назначила пробные отключения устаревшей подписи RSA с SHA-1 и механизма diffie-hellman-group-exchange-sha256 на 4 ноября и 9 декабря 2026 года, а окончательное удаление запланировала на 13 января 2027 года. Поэтому сегодняшнее требование к длине новых RSA-ключей и будущий отказ от старых алгоритмов следует учитывать как разные задачи миграции.

Для команд практический приоритет на сегодня — инвентаризация SSH-клиентов и проверка RSA-SHA-2, затем отдельное тестирование поддержки ML-KEM. Пользователям в США доступность нового алгоритма пока не заявлена; требование к размеру новых RSA-ключей при этом уже действует для загрузок после 14 октября.

Персоны

Для этой статьи персоны пока не указаны.

Читайте дальшеСингапур и Google DeepMind разработали ИИ для поиска мошеннических переписок на телефоне
Читать следующую статью

Превратите прочитанное в рабочую интеграцию

Изучайте API социальных данных jsonscraper, тестируйте запросы и создавайте новые процессы.

Смотреть API