10 мая веб-сервис для хостинга IT-проектов и их совместной разработки GitHub добавил поддержку ключей безопасности для аутентификации по SSH при использовании Git. Разработчики теперь могут использовать внешние портативные устройства, работающие с протоколом FIDO2, для дополнительной защиты от попыток перехвата учетной записи и предотвращения случайного раскрытия секретного ключа.
Пользователям сервиса по-прежнему придется создавать пару из открытого и закрытого ключей, но секретные биты в этом случае будут генерироваться и храниться в ключе безопасности FIDO2, а открытая его часть будет храниться на ПК разработчика, как и любой другой открытый ключ SSH. Хотя часть закрытого ключа и будет храниться на ПК — это лишь ссылка на физический ключ безопасности, который бесполезен без доступа к фактическому устройству.
Ранее пользователи GitHub обычно использовали ключи RSA или ed25519. Теперь они могут задействовать два дополнительных типа ключей безопасности: ecdsa-sk и ed25519-sk.
GitHub советует разработчикам заменить все их ранее зарегистрированные SSH-ключи на SSH-ключи с поддержкой ключей безопасности. Только это сможет гарантировать, что только обладатель ключа безопасности FIDO2 будет единственным пользователем, кто может управлять данными Git своих проектов по SSH. В этом случае отпадает необходимость отслеживать все генерируемые ранее ключи SSH, поскольку они станут бесполезны без доступа к ключу безопасности, с которым они связаны.
В 2019 году исследователи из университета штата Северная Каролина (NCSU) обнаружили, что из более чем 100 тыс. репозиториев GitHub произошла утечка токенов API и криптографических ключей (SSH и TLS) после сканирования примерно 13% общедоступных репозиториев GitHub в течение почти шести месяцев. Ими было также обнаружило, что из тысячи новых репозиториев продолжают ежедневно утекать данные по токенам и ключам.
15 декабря 2020 года GitHub предупредил всех пользователей о плановом переходе на токены и SSH-ключи при доступе к Git. Доступ только по паролям к Git будет заблокирован с 13 августа 2021 года. Это делается для защиты пользователей и предотвращения использования злоумышленниками похищенных или взломанных паролей.
amarao
А что будет, если токен утерян? И как быть с автоматизацией, полагающейся на ключи?
arren
Если потерять токен, то:
— не будет доступа по ключу публичная часть которого находится в github
— как вариант, купить новый токен и сгенерить заново ключ
— можно использовать хранение паролей в GPG
Автоматизация полагающаяся на ключи никуда не исчезнет в статье идет речь о доступе по паролям
amarao
По каким паролям? Вы о чём? Статья о предложении всем перейти с обычных ssh-ключей на "токены". Поддержка такого — хорошо. Предложение всем перейти — плохо.
А "хранение паролей в GPG" это вообще удивительная история. В каком месте gpg вы хотите хранить пароли? В
.text,.rodataили в.data?arren
Спасибо за минус, заберите себе, я ничего неправильного не сказал
Перефразирую по другому:
— автоматизация по ключам и будет дальше работать никто не форсирует переход на -sk, все понимают что есть автоматы которые ходят в гитхаб, поддержка хорошо да и совет перейти хорошо, только удобство сомнительное так как оно заставляет постоянно тискать ключ
— хранение в gpg – я имел ввиду использовать gpg-agent вместо ssh-agent, где приватная часть дешифруется аппаратным ключем (я именно так и использую, есть некоторые неудобства, но в целом оказалось удобнее чем вариант с -sk)
— что за .data, .rodata вы про embedded разработку или что? причем тут это?
amarao
Я на такую ерунду не размениваюсь (минусовать за разумную дискуссию).
И я не понимаю часть про хранение паролей в gpg-агенте. Там же gpg-ключи хранятся. Или вы хотите приватные ключи в gpg-агенте хранить?
А подписывать коммиты тогда ssh-ключами, или как?
arren
В GPG ключи разного типа есть (usage): Sign, Auth, Encrypt. Еще есть Certify он нужен для подписи ключей S/A/E в цепочке.
gpg-agent использует A ключ, ну и если его больше одного можно указать по номеру в конфиге sshcontrol. Он появится в ssh-add -L с номером ключа в инфо.
Подпись соответственно делается через Sign и тоже указывается в .gitconfig
Подробнее вы можете почитать в документации.
arren
Я полагаю Вы уверены что автоматизация перестанет работать так как форсируют переход на токены, Вы наверное думали про API token? здесь говорится про «токен» как про устройство (ну по крайней мере я так понял)
Ну и то что отключат доступ по паролям, вот это хорошо
amarao
Нет, я уверен, что ближайший git push от робота сломается, если начнут требовать приватный ключ через токен.