Хабр, привет! Хекслет в эфире. 

Мы в десятый раз перепроверяем свои RSA-ключи, чего и всем желаем: 22 сентября 2026 года GitHub объявил, что ужесточает правила для подключений по SSH. Мы расспросили об этом Дмитрия Зайцева — он девопс, CTO в компании Flocktory, организатор и спикер Devops Days.

Скоро GitHub отключит часть старых алгоритмов и изменит требования для новых RSA-ключей. Изменения касаются только SSH и не затронут репозитории, которые открываются по HTTPS. 

Что и когда изменится, как подготовиться и что проверить — всё расскажем и покажем. 

Что и зачем изменяется

Изменений четыре.

1. Размер RSA-ключа — от 3072 бит.
   RSA-ключи, добавленные в аккаунт после 14 октября 2026 года, должны быть не короче 3072 бит — и для входа, и для подписи коммитов. Это требование действует только для новых ключей. Ранее добавленные можно оставить..

2. GitHub перестанет принимать подпись RSA-ключом с хешем SHA-1 (ssh-rsa).
   RSA-ключи можно использовать с подписью SHA-2 (rsa-sha2-256 и rsa-sha2-512), поэтому перевыпускать ключи не нужно. Нужен клиент, поддерживающий подпись SHA-2.

3. Отключается обмен ключами diffie-hellman-group-exchange-sha256.
   Обмен ключами (key exchange) — этап подключения, на котором клиент и сервер договариваются о ключе сеанса. GitHub перестанет поддерживать этот способ: он медленный и малоиспользуемый.

4. Добавляется постквантовый (post-quantum) обмен ключами mlkem768x25519-sha256. Это новый способ договариваться о ключе сеанса, устойчивый к взлому на квантовых компьютерах. С 14 октября GitHub будет поддерживать его на github.com. Настраивать ничего не нужно: клиент, который знает этот способ, выберет его сам, а старый продолжит работать с прежним алгоритмом.

Отдельно про Ed25519: именно этот алгоритм цифровой подписи GitHub советует для новых ключей. Алгоритм ECDSA тоже подходит. GitHub обещает, что ключи Ed25519 и ECDSA продолжат работать.

Календарь

Нововведения будут применены в несколько этапов. Перед тем, как окончательно ввести изменения, GitHub проведёт «учения»: на ограниченное время GitHub перестанет принимать подпись ssh-rsa на SHA-1 и обмен ключами diffie-hellman-group-exchange-sha256, и всё, что на них держится, упадёт.

В GitHub Enterprise Server изменения придут с версией 3.25, а mlkem768x25519-sha256 — с версией 3.24.

Крайний срок — январь, но проверять лучше до 4 ноября: в этот день первый раз реально сломается то, что не готово.

Что делать

Три шага, которые помогут сохранить доступ к репозиториям: 

• проверить ключи,

• при необходимости выпустить Ed25519,

• убедиться, что соединение работает. 

Первый и третий этапы нужны даже тем, у кого всё на Ed25519: никогда не вредно лишний раз проверить.

Шаг 1: проверить ключи

Список файлов в папке с ключами: ls ~/.ssh

Публичные ключи лежат в файлах с расширением .pub: id_rsa.pub, id_ed25519.pub и так далее. Тип и размер ключа показывает ssh-keygen:

ssh-keygen -l -f ~/.ssh/id_rsa.pub
ssh-keygen -l -f ~/.ssh/id_ed25519.pub

Ответ выглядит так:

2048 SHA256:Xk3p9…  you@example.com (RSA)
256  SHA256:q8Zt4…  you@example.com (ED25519)

Первое число — размер в битах, посередине стоит отпечаток (fingerprint) ключа, в скобках — тип. 

В примере два ключа. Первый — RSA на 2048 бит. Это меньше 3072, поэтому после 14 октября добавить в аккаунт новый ключ такого размера не получится. Второй — Ed25519 на 256 бит. Размер здесь с RSA не сравнивают: у Ed25519 биты считаются иначе, а по стойкости такой ключ сопоставим с RSA на 3072 бита. Он подходит.

В PowerShell путь к ключу выглядит так: $env:USERPROFILE\.ssh\id_rsa.pub.

При входе на GitHub SSH-клиент пробует свои ключи по очереди. Чтобы посмотреть, какие именно ключи применяет клиент, выполните команду:

ssh -vT git@github.com 2>&1 | grep "Offering public key"

В PowerShell вместо grep работает Select-String. 

В ответе будет строка вроде 

debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:q8Zt4…

Что настроить на GitHub

Клик по аватару пользователя → Settings → SSH and GPG keys (вот прямая ссылка). Под названием каждого ключа показан отпечаток, его надо сверить с выводом ssh-keygen. Рядом отмечено, когда ключ использовали в последний раз, так что «заброшенные» ключи заметны сразу.

Что делать:

• если у вас Ed25519 или ECDSA — всё ок, ничего менять не нужно.

• если у вас RSA от 3072 бит: работает, если ваш клиент умеет подписывать запросы SHA-2 (проверим на шаге 3).

• если у вас RSA короче 3072 бит: судя по анонсу, добавленный ключ продолжит работать. Но добавить новый ключ такого размера после 14 октября не получится. Проще сразу заменить его на Ed25519.

Шаг 2: если надо — выпустить ключ Ed25519

Команда одна для всех систем:

ssh-keygen -t ed25519 -C "you@example.com"

Она спросит имя файла и парольную фразу (passphrase). Если в ~/.ssh уже лежит id_ed25519, стоит задать другое имя, например id_ed25519_github, иначе придётся перезаписывать старый ключ. Фраза шифрует файл приватного ключа. Без шифрования доступ к репозиториям получит любой, у кого окажется файл с приватным ключом — например, при потере ноутбука.

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

Linux и Git Bash:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

macOS:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Windows (PowerShell от имени администратора):

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

Windows — добавление ключа (обычное окно PowerShell, без прав администратора):

ssh-add $env:USERPROFILE\.ssh\id_ed25519

Публичный ключ (файл с .pub) нужно скопировать в буфер обмена, чтобы вставить его в форму на GitHub. Копирование можно выполнить через терминал:

Linux (X11, нужен пакет xclip): 

xclip -selection clipboard < ~/.ssh/id_ed25519.pub

Linux с Wayland (нужен пакет wl-clipboard): 

wl-copy < ~/.ssh/id_ed25519.pub

macOS: 

pbcopy < ~/.ssh/id_ed25519.pub

Windows: 

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | Set-Clipboard

И теперь добавляем ключ на GitHub: на странице с ключами жмите New SSH key и заполняйте форму: 

• Title (название по имени машины, например work-laptop-2026), 

• Key type (Authentication Key)

• Key, куда вставляется скопированная строка, начинающаяся с ssh-ed25519. 

Остаётся нажать Add SSH key. При этом GitHub может попросить пароль от аккаунта.

Если коммиты подписываются SSH-ключом (в настройках git указано gpg.format ssh), тот же публичный ключ нужно добавить второй раз с типом Signing Key. Порог в 3072 бита действует и для ключей подписи, но Ed25519 он не касается. Путь к ключу в git обновляется так:

git config --global user.signingkey ~/.ssh/id_ed25519.pub

Старый ключ пока остаётся в аккаунте, удалять его стоит после шага 3.

Шаг 3: проверить соединение и алгоритмы

Базовая проверка:

ssh -T git@github.com

Главное в ответе — приветствие с именем аккаунта: 

Hi BestUserEver! You've successfully authenticated, but GitHub does not provide shell access. 

Проверяем версию SSH-клиента

Версия OpenSSH должна быть 7.2p1 или новее, иначе клиент подпишет запрос RSA-ключом с хешем SHA-1, и GitHub не примет такую подпись.

ssh -V

Ответ может быть примерно таким:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024

В примере OpenSSH 9.6p1 (новее 7.2p1), значит, с версией всё в порядке.

Проверяем алгоритм обмена ключами

ssh -vT git@github.com 2>&1 | grep "kex: algorithm"

Ответ может выглядеть так:

debug1: kex: algorithm: curve25519-sha256

Если в ответе указан алгоритм curve25519-sha256, обмен ключами будет работать нормально. Некоторые свежие клиенты после 14 октября могут перейти на mlkem768x25519-sha256. 

Тревожный ответ — diffie-hellman-group-exchange-sha256.

Если в ответе diffie-hellman-group-exchange-sha256 — первым делом стоит обновить OpenSSH (или другой клиент): новая версия сама выберет актуальный алгоритм обмена. Если обновить клиент не получается — можно исключить алгоритм из списка в ~/.ssh/config:

Host github.com
  KexAlgorithms -diffie-hellman-group-exchange-sha256

После этого снова выполните команду с grep "kex: algorithm" и убедитесь, что в ответе больше нет diffie-hellman-group-exchange-sha256.

Генеральная репетиция отключения

В В OpenSSH версий 9 и позже:

ssh -o PubkeyAcceptedKeyTypes=-ssh-rsa -o KexAlgorithms=-diffie-hellman-group-exchange-sha256 -T git@github.com

В OpenSSH 8.5 и в более ранних опция PubkeyAcceptedKeyTypes называется PubkeyAcceptedAlgorithms.

Эта команда запрещает клиенту устаревшие алгоритмы (подпись ssh-rsa на SHA-1 и обмен ключами diffie-hellman-group-exchange-sha256). Если ключи и настройки соответствуют новым требованиям GitHub, ответ будет такой же, как при базовой проверке:

Hi BestUserEver! You've successfully authenticated, but GitHub does not provide shell access.

Если вы получили приветствие, значит, на этой машине и с этим ключом вход будет работать и 4 ноября, и после 13 января. Другие компьютеры, CI-серверы и библиотеки нужно проверить отдельно.

Если что-то настроено не так — будет отказ:

git@github.com: Permission denied (publickey).

Если и обычная проверка, и репетиция отключения успешно прошли с новым ключом Ed25519, старый RSA-ключ можно удалить из аккаунта (если он не нужен другим машинам) на странице управления ключами.

Если всё пошло не так

Ошибка Permission denied (publickey) означает, что GitHub не получил подходящего ключа. Команда ssh-add -l показывает ключи в агенте: пустой список значит, что ключ не добавлен — и нужно вернуться к шагу 2. Если в ~/.ssh есть несколько ключей, поможет явный выбор в ~/.ssh/config:

Host github.com
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

Со старыми клиентами и библиотеками всё упирается в версию. Минимальные версии с поддержкой RSA и SHA-2 по данным GitHub:

Если обновить программу не получается — можно создать для неё отдельный ключ Ed25519 или ECDSA и добавить его в аккаунт на GitHub. Это сработает, только если программа умеет работать с такими ключами.

На GitHub Enterprise Server сроки зависят от администратора: основные изменения придут в версии 3.25, постквантовый обмен — в 3.24. 

Ключи в CI и Deploy keys для репозитория

Отдельная история — CI. Ключи в секретах CI-системы и Deploy keys (Settings → Deploy keys) нужно обновлять отдельно от личных, и про них легко забыть. 

Порядок такой: 

• добавить новый ключ, 

• прогнать сборку, 

• удалить старый ключ.

Заключение

Что стоит сделать до 4 ноября:

1. Проверить тип и размер каждого ключа (ssh-keygen -l).

2. Проверить версии OpenSSH на рабочих машинах и версии клиентов и библиотек в CI.

3. Использовать для новых ключей алгоритм цифровой подписи Ed25519.

4. Убедиться, что ssh -T git@github.com и репетиция отключения проходят без ошибок.

5. После проверки новых ключей удалить старые — из аккаунта и из Deploy keys.

Если все пункты выполнены — вы даже не заметите изменений, которые будут 14 октября и 4 ноября 2026 года  и 13 января в 2027 году. 

Настоящий DevOps решает такие задачи одной левой, за что его и ценят. Для инженера, который отвечает за инфраструктуру, смена правил SSH на GitHub — рядовая задача: ключи учтены, доступы в CI описаны кодом, проверка запускается скриптом. Освоить эти навыки можно на программе Хекслета «DevOps-инженер с нуля»: Linux, сети, контейнеры, CI/CD, мониторинг, Terraform и Kubernetes — всё в ваших руках.