Comments 8
А что будет, если токен утерян? И как быть с автоматизацией, полагающейся на ключи?
Если потерять токен, то:
— не будет доступа по ключу публичная часть которого находится в github
— как вариант, купить новый токен и сгенерить заново ключ
— можно использовать хранение паролей в GPG
Автоматизация полагающаяся на ключи никуда не исчезнет в статье идет речь о доступе по паролям
— не будет доступа по ключу публичная часть которого находится в github
— как вариант, купить новый токен и сгенерить заново ключ
— можно использовать хранение паролей в GPG
Автоматизация полагающаяся на ключи никуда не исчезнет в статье идет речь о доступе по паролям
По каким паролям? Вы о чём? Статья о предложении всем перейти с обычных ssh-ключей на "токены". Поддержка такого — хорошо. Предложение всем перейти — плохо.
А "хранение паролей в GPG" это вообще удивительная история. В каком месте gpg вы хотите хранить пароли? В .text, .rodata или в .data?
Спасибо за минус, заберите себе, я ничего неправильного не сказал
Перефразирую по другому:
— автоматизация по ключам и будет дальше работать никто не форсирует переход на -sk, все понимают что есть автоматы которые ходят в гитхаб, поддержка хорошо да и совет перейти хорошо, только удобство сомнительное так как оно заставляет постоянно тискать ключ
— хранение в gpg – я имел ввиду использовать gpg-agent вместо ssh-agent, где приватная часть дешифруется аппаратным ключем (я именно так и использую, есть некоторые неудобства, но в целом оказалось удобнее чем вариант с -sk)
— что за .data, .rodata вы про embedded разработку или что? причем тут это?
Перефразирую по другому:
— автоматизация по ключам и будет дальше работать никто не форсирует переход на -sk, все понимают что есть автоматы которые ходят в гитхаб, поддержка хорошо да и совет перейти хорошо, только удобство сомнительное так как оно заставляет постоянно тискать ключ
— хранение в gpg – я имел ввиду использовать gpg-agent вместо ssh-agent, где приватная часть дешифруется аппаратным ключем (я именно так и использую, есть некоторые неудобства, но в целом оказалось удобнее чем вариант с -sk)
— что за .data, .rodata вы про embedded разработку или что? причем тут это?
Я на такую ерунду не размениваюсь (минусовать за разумную дискуссию).
И я не понимаю часть про хранение паролей в gpg-агенте. Там же gpg-ключи хранятся. Или вы хотите приватные ключи в gpg-агенте хранить?
А подписывать коммиты тогда ssh-ключами, или как?
В GPG ключи разного типа есть (usage): Sign, Auth, Encrypt. Еще есть Certify он нужен для подписи ключей S/A/E в цепочке.
gpg-agent использует A ключ, ну и если его больше одного можно указать по номеру в конфиге sshcontrol. Он появится в ssh-add -L с номером ключа в инфо.
Подпись соответственно делается через Sign и тоже указывается в .gitconfig
Подробнее вы можете почитать в документации.
gpg-agent использует A ключ, ну и если его больше одного можно указать по номеру в конфиге sshcontrol. Он появится в ssh-add -L с номером ключа в инфо.
Подпись соответственно делается через Sign и тоже указывается в .gitconfig
Подробнее вы можете почитать в документации.
И как быть с автоматизацией, полагающейся на ключи?
Я полагаю Вы уверены что автоматизация перестанет работать так как форсируют переход на токены, Вы наверное думали про API token? здесь говорится про «токен» как про устройство (ну по крайней мере я так понял)
Ну и то что отключат доступ по паролям, вот это хорошо
Sign up to leave a comment.
GitHub добавил поддержку ключей безопасности SSH