Комментарии 20
Т.е. у вас получилось через pcks#11 использовать ключи 25519? Сам не пробовал пока, но гугл говорит, что они пока в черновике, а официально пока только ECDSA.
У меня там RSA2048. Примеры надерганы из разных источников :)
Ну, так неинтересно. А в ssh ещё и ed448 на подходе.
Да не, ec25519 вроде уже вполне эллиптическая.
И в gnuk включается при генерации (если генерировать прямо на ключе) путём ввода размера ключа как 25519.
Выбор типа ключа (подпись, аутентификация или шифрование) тоже довольно логичны. Просто надо быть чуть-чуть в теме и понимать, что и для чего.
Разница вполне понятна — я пришлю вам зашифрованный вашим паб-ключом запрос подписать перевод на мою карту ляма баксов.
И тут разница между "encryption" (прочитать содержимое), "sign" (подтвердить согласие на перевод бабла) и "authentication" (который в этой ситуации вообще не применим) становится достаточно ясной.
Но вот один момент — между gpg-agent и pkcs — так и остаётся неясным.
Последний вообще никак не хочет запускаться. Жалуется то ли на ошибку либы, то ли на её отсутствие. Так что все пошаговые руководства, которые рулят именно в его сторону — в топку, ни одно не работает.
А вот use_agent и gpg-agent который всё делает — зайчики!
ssh-add -L — и вот она заветная строчка, чтоб дописать удалённо в authorized_keys.
Остальное — как часы. Есть токен в порту — в консоли спрашивает текстом, в графике — всплывает окошко. Работает и на линуксе, и на маке. И всякую возможность "разболтать кому-нибудь реквизиты доступа" устраняет на ура (максимум — разболтаете пин-код от брелка. Если сам брелок не потеряли — ну, смените пинкод).
А что-то вроде юбикей можно получить таким образом? https://thekernel.ru/compare-yubikey-5-series/
Или вопрос мимо темы?
Вопроса не понял. Что именно надо то?
Не, там U2F и прочие вкусности требуют больше ресурсов, чем осиливает стм-ка в stlink.
Максимум, что видел из модификаций gnuk — это ещё припаивают кнопку на пару контактов, оставшихся от программатора. Чтобы создать фактор присутствия.
И вроде выглядит уже почти прямо как U2F, но я так понял, запрограммировать это всё вместе ресурсов не хватает (та самая кнопка во всех найденных вариантах — это внешний костыль, примотанный изолентой. Увидели запрос ключа — помигали светодиодом, подождали кнопку, выдали ключ. Софт снаружи ни про какую кнопку не знает, а просто ощущает задержку).
Когда пробовал 4 года назад использовать gpg в качестве ssh-agent, столкнулся с багом, что эта шарманка падала в segfault при использовании ключа на большом количестве хостов параллельно. Подробностей не помню, но, кажется, он перегружает ключ из одного буфера в другой при каждом обращении, и этот второй буфер на тот момент был 64к. Соответственно, 4к RSA? Не более 16 параллельных соединений. А это было непреемлимо. К вопросу не возвращался, но рекомендовать использовать подобную схему не буду никому.
Из разряда ОБС, коллега криптопанк пробовал использовать yubico 4 в связке с ssh через gpg. Когда я спросил, как оно, порекомендовал не связываться.
Там 16 разных хостов нужно или на один можно?
Тест, который показывает ненадёжность конструкции.
Входные данные:
- gpg-agent с поддержкой ssh
- Ключ
4096 SHA256:+PGWt9Lde6CxeYqvX7jx23QF5hJXtF2yGot3X4DZui8 - Программа
pdsh-2.34 (+readline) - Запущенный sshd, у пользователя в
~/.ssh/authorized_keysдобавлен вышеозначенный ключ
Запускаю агент, добавляю ключ. Команда теста выглядит следующим образом:
printf '%.0slocalhost\n' {1..10} | pdsh -w^- -f1 echo I am fine
localhost: I am fine
localhost: I am fine
localhost: I am fine
localhost: I am fine
localhost: I am fine
localhost: I am fine
localhost: I am fine
localhost: I am fine
localhost: I am fine
localhost: I am fineПараметр -f1 указывает количество параллельных подключений. На 4 параллельных подключениях гарантированно хотя бы один раз pdsh не может установить соединение. Вот строчка из логов gpg-agent:
failed to build S-Exp (off=1884): Cannot allocate memory.
При работе с тысячами хостов я запускаю параллельно до 150 соединений со стандартным ssh-agent, не зная бед.
Спасибо за вопрос, он заставил воспроизвести баг и иметь обоснованные аргументы против использования фичи ssh-agent в gpg.
Я думаю тут даже стоит заморочиться сходить заполнить баг у gnupg :)
https://dev.gnupg.org/T3027#107618
Звучит как "не используйте нас"
И еще раз про аппаратные ключи GPG за копейки