На всякий: в общем-то описанное ранее все работает и даже не вызывает раздражения, но только если ваша работа не связана с регулярными походами по многим ssh серверам. В реальности регулярное ожидание “прикоснитесь к токену” начинает раздражать уже на втором десятке коннектов. А если запустить какой-нибудь ансибл плейбук, так сидишь и настукиваешь по токену, пока плейбук пройдет по серверам. А потом, где-то на середине, опять начинаешь, ибо сессия протухла. В общем, бесит неимоверно.
После гуглежа выяснилось, что у юбиков для fido2 нет опции “не требовать прикосновения Н времени”. Для gpg есть, а для fido – нет. Боль и печаль. Поэтому самый простой способ купировать это поведение – это использовать controlpath в ssh.
Для ssh это лечится добавлением в .ssh/config следующих строк:
ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p.socket
ControlPersist 120mТеперь, стоит вам зайти на любой хост, как любой последующий вход в течении двух часов будет происходить по уже установленной сессии. Никаких касаний и прочего не будет. Для ансибла делаем аналогично:
$ cat .ansible.cfg
[defaults]
[ssh_connection]
ssh_args=-C -o ControlPath=~/.ssh/master-%r@%h:%p.socket -o ControlMaster=auto -o ControlPersist=120mТеперь что ssh, что ansible будут использовать одни и те же пути, что приводит к повышению производительности. Но боль “коснись 100500 раз” просто загоняется вглубь. Что при первом запуске, что при последующих – все тоже самое. Опять гуглю. Выходит, что мимо gpg хоть так, хоть так не пройти. Ладно, у меня есть gpg!
$ gpg -K
...
sec rsa4096 2017-09-11 [SC]
F60000F98C6BC1B31FCAE943D9C4611813E9F51E
uid [ultimate] Viacheslav Kaloshin <kiltum@kiltum.tech>
ssb rsa4096 2017-09-11 [E]Ох, аж с 2017 живет и есть пить-не просит, это хорошо. Так как у нас нынче не моден RSA, то добавляю 3 ключа ed25519:
$ gpg --quick-add-key F60000F98C6BC1B31FCAE943D9C4611813E9F51E ed25519 sign never
...
$ gpg --quick-add-key F60000F98C6BC1B31FCAE943D9C4611813E9F51E cv25519 encr never
...
$ gpg --quick-add-key F60000F98C6BC1B31FCAE943D9C4611813E9F51E ed25519 auth never
...
$ gpg -K
...
sec rsa4096 2017-09-11 [SC]
F60000F98C6BC1B31FCAE943D9C4611813E9F51E
uid [ultimate] Viacheslav Kaloshin <kiltum@kiltum.tech>
ssb rsa4096 2017-09-11 [E]
ssb ed25519 2025-03-04 [S]
ssb cv25519 2025-03-04 [E]
ssb ed25519 2025-03-04 [A]В принципе, для ssh можно добавить только последний ключ, для auth. Но я решил танцевать по-максимуму. Так, если верить докам, то сейчас у меня уже должена появиться возможность проэкспортить ssh ключ
$ gpg --export-ssh-key F60000F98C6BC1B31FCAE943D9C4611813E9F51E
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIImOGsDlDGh27/geO2YAf+lHcQAANqjjASvNhqY0Dp1H openpgp:0x0629B65FДа, появилось. Это не может не радовать. Быстренько добавляю в стартап скрипты следующие строки, попутно вынося все, что было с ssh-agent
export GPG_TTY="$(tty)"
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
gpgconf --launch gpg-agentИ добавляю поддержку ssh в gpg-agent
echo enable-ssh-support >> $HOME/.gnupg/gpg-agent.confОткрываю соседний терминал и смотрю
$ ssh-add -L
The agent has no identities.Вот на тебе по всей морде, а не ssh ключ! Обидно, гуглю дальше. Оказывается, gpg-agent слишком секурный и просто так никому ничего не покажет. Ему надо конкретно указать, какой ключ нужен. Для этого смотрим ид ключей и добавляем в спец-файлик
$ gpg -K --with-keygrip
/Users/vvkaloshin/.gnupg/pubring.kbx
------------------------------------
sec rsa4096 2017-09-11 [SC]
F60000F98C6BC1B31FCAE943D9C4611813E9F51E
Keygrip = 5F821C94AA751454412CE7887AD0026C75AC3E54
uid [ultimate] Viacheslav Kaloshin <kiltum@kiltum.tech>
ssb rsa4096 2017-09-11 [E]
Keygrip = 282D042F0CA040CF13C881FBBCD190D4FF3B895E
ssb ed25519 2025-03-04 [S]
Keygrip = 0D336DFDE44B04C2135022A5E486A4610C0F80EA
ssb cv25519 2025-03-04 [E]
Keygrip = EE62D0C4FE020623BC0372ED44196435A269A045
ssb ed25519 2025-03-04 [A]
Keygrip = AE9CE2AC2E83722BE5F0508C7D131E91CD5FA317
$ echo AE9CE2AC2E83722BE5F0508C7D131E91CD5FA317 >> .gnupg/sshcontrol
$ ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIImOGsDlDGh27/geO2YAf+lHcQAANqjjASvNhqY0Dp1H (none)Ура! Заработало! Можно раскидать публичный ключик по серверам и попробовать. Лично у меня заработало…
И работало некоторое время, пока опять не начало клянчить пароль, но на этот раз от gpg. Ну это лечится гораздо проще:
$ cat .gnupg/gpg-agent.conf
...
default-cache-ttl 34560000
max-cache-ttl 34560000Итого, оно работает. Но где тут yubikey? А с ним оказалось еще проще. Надо просто перенести ключик из внутренней базы gpg в токен.
ВНИМАНИЕ! Сделайте бекап каталога .gnupg! Он понадобится для второго токена
Для начала выбираем ключ
gpg --edit-key kiltum@kiltum.tech
gpg> key 1
sec rsa4096/D9C4611813E9F51E
created: 2017-09-11 expires: never usage: SC
trust: ultimate validity: ultimate
ssb* rsa4096/B2698444DC05C50F
created: 2017-09-11 expires: never usage: E
ssb ed25519/406890D12CB9E70B
created: 2025-03-04 expires: never usage: S
ssb cv25519/973D20344A973490
created: 2025-03-04 expires: never usage: E
ssb ed25519/24C65C290629B65F
created: 2025-03-04 expires: never usage: A
[ultimate] (1). Viacheslav Kaloshin <kiltum@kiltum.tech>
gpg> key 4
sec rsa4096/D9C4611813E9F51E
created: 2017-09-11 expires: never usage: SC
trust: ultimate validity: ultimate
ssb* rsa4096/B2698444DC05C50F
created: 2017-09-11 expires: never usage: E
ssb ed25519/406890D12CB9E70B
created: 2025-03-04 expires: never usage: S
ssb cv25519/973D20344A973490
created: 2025-03-04 expires: never usage: E
ssb* ed25519/24C65C290629B65F
created: 2025-03-04 expires: never usage: A
[ultimate] (1). Viacheslav Kaloshin <kiltum@kiltum.tech>
gpg> key 1
sec rsa4096/D9C4611813E9F51E
created: 2017-09-11 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa4096/B2698444DC05C50F
created: 2017-09-11 expires: never usage: E
ssb ed25519/406890D12CB9E70B
created: 2025-03-04 expires: never usage: S
ssb cv25519/973D20344A973490
created: 2025-03-04 expires: never usage: E
ssb* ed25519/24C65C290629B65F
created: 2025-03-04 expires: never usage: A
[ultimate] (1). Viacheslav Kaloshin <kiltum@kiltum.tech>Обратите внимание на звездочку около ssb – команда key триггерит выбор ключа, а не отменяет последний выбор! И наконец, записываю ключ в yubi
gpg> keytocard
Please select where to store the key:
(3) Authentication key
Your selection? 3
sec rsa4096/D9C4611813E9F51E
created: 2017-09-11 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa4096/B2698444DC05C50F
created: 2017-09-11 expires: never usage: E
ssb ed25519/406890D12CB9E70B
created: 2025-03-04 expires: never usage: S
ssb cv25519/973D20344A973490
created: 2025-03-04 expires: never usage: E
ssb* ed25519/24C65C290629B65F
created: 2025-03-04 expires: never usage: A
[ultimate] (1). Viacheslav Kaloshin <kiltum@kiltum.tech>
Note: the local copy of the secret key will only be deleted with "save".
gpg> save
Вроде ничего не произошло страшного, кроме запроса admin кода, верно? Проверяю
[vvkaloshin@sc-mac-00565 ~]$ gpg -K
/Users/vvkaloshin/.gnupg/pubring.kbx
------------------------------------
sec rsa4096 2017-09-11 [SC]
F60000F98C6BC1B31FCAE943D9C4611813E9F51E
uid [ultimate] Viacheslav Kaloshin <kiltum@kiltum.tech>
ssb rsa4096 2017-09-11 [E]
ssb ed25519 2025-03-04 [S]
ssb cv25519 2025-03-04 [E]
ssb> ed25519 2025-03-04 [A]Теперь у ключика, который в yubi, появился символ >. Дескать, он во внешней штуке. Так и должно быть. Но у меня есть второй yubi, в него бы тоже этот ключик засунуть… Как быть? А очень просто: убиваем gpg-agent, восстанавливаем бекап .gnupg, вставляем второй ключ и повторяем операцию с записью ключа. Один-в-один, без всяких изменений.
И теперь барабанная дробь! Проверяю
$ ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIImOGsDlDGh27/geO2YAf+lHcQAANqjjASvNhqY0Dp1H cardno:23_059_666
$ ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIImOGsDlDGh27/geO2YAf+lHcQAANqjjASvNhqY0Dp1H cardno:23_059_689Выше я, абсолютно ничего не делая, просто поменял токен. gpg-agent опять оказался достаточно разумным, чтобы разрулить эту ситуацию. Теперь у меня есть аж два варианта работы с этим ключем: либо с помощью юбиков, либо восстановить .gnupg из бекапа и забить на юбики. Ключ не изменится! А что самое главное, ключ защищен аж в двух местах: пароль на gpg и пин на юбике. Оба хоть и кешируются (тут удобство для меня), но при перезагрузке/смене ключа спрашиваются (тут радуется внутренний безопасник).
Что необходимо сделать следующим? Во-первых, положить бекап .gnupg в сухое место. Во-вторых, пройтись по всяким серверам и сервисам и добавить новый ssh ключ. И наконец, самое больное: пройтись по всяким серверам и сервисам и заменить публичный pgp ключ. Причина простая и прозаическая: мы добавили новых ключей и всякие git (вы же пользуете подпись в git?) стали автоматом использовать свежее и более защищенное. Пруф:
$ git log --show-signature -1
commit 37ad3b5134621b1df18644b10884b8d17f2879f9 (HEAD -> main, origin/main, origin/HEAD)
gpg: Signature made Tue Mar 4 14:12:19 2025 MSK
gpg: using EDDSA key 12D3317E74826BD633976A76406890D12CB9E70B
gpg: Good signature from "Viacheslav Kaloshin <kiltum@kiltum.tech>" [ultimate]Вообще зря я вас пугал болью (смаил). Это делается просто:
$ gpg --armor --export
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBFm2d2MBEACy9YyMqPeEZEIgndjhyYOOz61WXBZtyrOaeNXlfRy2HjZZ9os2
....
=KxVu
-----END PGP PUBLIC KEY BLOCK-----И вот этот вот текст вы суете во всем места, где просят GPG public key.
Где были проблемы? На моем пути была только одна: если у вас в gpg стоит pinentry не графический (читай: просто pinentry или pinentry-ncurses), то при попытке добавления другого, старого и проверенного ключа я получал облом.
$ ssh-add .ssh/backup/id_ed25519
Enter passphrase for .ssh/backup/id_ed25519:
Could not add identity ".ssh/backup/id_ed25519": agent refused operationЛечится это странной командой
$ echo UPDATESTARTUPTTY | gpg-connect-agent
OK
$ ssh-add .ssh/backup/id_ed25519
Enter passphrase for .ssh/backup/id_ed25519:
Identity added: .ssh/backup/id_ed25519 (kiltum@kiltum.tech)На всякий: удаляются такие ключи из базы gpg тоже не сложно:
$ gpg-connect-agent 'keyinfo --ssh-list' /bye
S KEYINFO AE9CE2AC2E83722BE5F0508C7D131E91CD5FA317 D - - - P - - S
S KEYINFO 716AA423769B73317BBA874ECFD11765948B5EFD D - - - P - - S
OK
$ gpg-connect-agent "delete_key --force 716AA423769B73317BBA874ECFD11765948B5EFD" /bye
OK
