В прошлой части я писал про resident ключи. И вроде все работало. А теперь решил попробовать поработать с non-resident. И тут же столкнулся с тем, что хоть ssh-add и работал, но заходить на сервера не получалось. Если запустить ssh -v, то можно было увидеть строчки from agent: agent refused operation
Немного нагуглив, я нашел рецепт: дескать, ssh-agent нужно подтвердить, а ему не у кого. И дескать, лечится установкой ssh-askpass и правки скрипта, который пускает ssh-agent. Ок, правлю вот так:
Все остальное оставляю прежним. Грохаю все и пытаюсь зайти
...
debug1: Will attempt key: /Users/xxxxxx/.ssh/id_ed25519
debug1: Will attempt key: /Users/xxxxxx/.ssh/id_ed25519_sk
debug1: Will attempt key: /Users/xxxxxx/.ssh/id_xmss
debug1: Offering public key: xxxxxx@yyyyy.ru ED25519-SK SHA256:4GX39PbvB7LoXoBzPrxABAt5xC+x05y6WNtgW3qAN+A authenticator agent
debug1: Server accepts key: xxxxxx@yyyyy.ru ED25519-SK SHA256:4GX39PbvB7LoXoBzPrxABAt5xC+x05y6WNtgW3qAN+A authenticator agent
sign_and_send_pubkey: signing failed for ED25519-SK "xxxxxx@yyyyy.ru" from agent: agent refused operation
debug1: Offering public key: xxxxxx@yyyyy.ru ED25519-SK SHA256:W/dXsAitpJKpPcYNf2zB+ucsG+zx50R0hSzIQ2Lwl74 authenticator agent
debug1: Server accepts key: xxxxxx@yyyyy.ru ED25519-SK SHA256:W/dXsAitpJKpPcYNf2zB+ucsG+zx50R0hSzIQ2Lwl74 authenticator agent
debug1: Enabling compression at level 6.
Authenticated to 10.34.178.1 ([10.34.178.1]:22) using "publickey".
debug1: setting up multiplex master socket
...
В логах видно, что у меня два ключа. Первый я вынул и спрятал. А вот второй – на месте. Вот где я добавил пустую строчку – там он стал ждать прикосновения к ключу. Никаких запросов или там окошек всплывающих не появилось. Нафига нужен ssh-askpass? Не знаю. Я даже попробовал перезагрузиться и ключ вставить-вынуть – ничего не поменялось…
Ситуация совершенно стандартная: есть что-то из proxmox, vmware, openstack и нам изредка требуется создавать в нем машинки. Можно пойти классическим путем: закачиваем исошку, создаем виртуалку с этой исошкой и ставим туда все, что нужно. Для ускорения можно добавить cloud-init, всякие конфиги для анаконд и прочее. Ну и потом все это полирнуть ансиблом и паппетом по вкусу. Есть хипстерский вариант: затащить какой-нить терраформ и клауд образа и им штамповать машинки. Больно, долго и муторно, как и все в IaaC.
А можно совместить приятное с полезным. Сделать виртуалку, напихать в нее всё, что надо и как надо, а потом преобразовать ее в темплейт. И уже потом из этого темплейта штамповать виртуалки в любом количестве. По скорости разворота этот способ уделывает все остальные на порядок.
Но тут есть маленькая проблемка: если сделать все прямо в лоб, то все новые машинки будут иметь одинаковые ссш ключи и будут получать один и тот же ip адрес. Итак, рецепт ниже.
Шаг первый: подготавливаем виртуалку как надо вам.
Долго ли, коротко, но в руках у меня снова оказался yubikey. Да, вот эта вот штука, которая устами манагеров обещает устойчивость ко взлому, фишингу и прочим ужасам современного ИТ-мира. Прошлый мой подход к юбикам окончился полной неудачей из-за кривого софта, драйверов и в общем-то моим нежеланием разбираться во всей этой мешанине букв и аббревиатур. Но тут отступать оказалось некуда, поэтому пришлось разбираться.
Итак, для начала. Если вы это делаете для себя, то берите минимум (подчеркиваю, минимум) два юбика. Дело в том, что юбики из-за природы своей не бекапятся, не обновляют прошивку и так далее и тому подобное. Если вам это вручили на работе, то вся боль по поводу работоспособности юбиков совершенно не ваша забота.
В общем, для начала надо заиметь свой юбик и поставить на комп Yubikey Manager. Ставим, запускаем, втыкаем ключ и вы должны увидеть что-то подобное этому:
Если увидели, то хорошо. Не увидели – дальше нет никакого смысла продолжать, надо разбираться, почему оно не алле.
Так как я хочу для начала настроить ssh, то (тут пропущено часов Н чтения мануалов и страничек) сходить на вкладку Applications – FIDO2 и нажать на кнопачку Change Pin. Ибо стандартный пин 123456 совершенно не секурный и вообще. После смены пина должно получиться следующее:
Ну а теперь самое интересное: необходимо сделать новый ssh ключ. Старые не подойдут, но в общем-то и не очень и хотелось. И тут внезапно появляется выбор: какой ключ делать? Если по типу шифрования вопросов нет – только ed25519, то вот резидентный или не резидентный ключ генерить…
Немного погуглив, я выяснил, что Discoverable Credential или Resident ключ – это тот, который полностью хранится в памяти ключа. А вот Non-Resident – это хранение ключей как обычно, в файликах, но без юбика они бесполезны. В чем проблема? Если у вас resident ключ и у вас сперли юбик, то злой дядька хакер сможет ходить на ваши сервера как к себе домой. Надежда на пин-код слабая, ибо подсмотреть его как нефиг делать. А если у вас non-resident ключи, то вам нужно будет таскать файлики ключей по своим рабочим машинкам. Выбирать вам. Лично я тут топлю за non-resident.
Далее все совершенно стандартно. Генерим ключ (ВНИМАНИЕ! -O resident тут сами понимаете для чего)
ssh-keygen -t ed25519-sk -O resident
… И копируем получившийся id_ed25519_sk.pub по нужным местам. Тут процедура тоже совершенно стандартная и описана 100500 раз везде.
В общем-то почти все. Набираем ssh user@host и получаем… облом по полной. Полное впечатление, что ssh тупо завис. Однако это не так, ssh просто ждет касания ключа, только почему-то не пишет об этом. Если оно горит (мне нет), то опять гуглим. Оказывается, если у вас для ssh есть обычные ключи и они уже добавлены в ssh-agent (вот тут не уверен), то для нового ключа ssh ничего решает не спрашивать. Правим .ssh/config
И пробуем снова. У меня получилось и он стал спрашивать. Так как я делал resident ключ, то теперь радостно размахивая шашкой, удаляю все честно нагенеренное, имитируя новую машину. Или после ребута. Смотрим, какие есть ключи
Вот. ED25519-SK это тот, что “спрятан” в юбике. Пробуем ходить по ssh… ходится! На этом этапе можно начинать бросать чепчики в воздух и кричать “ура!”.
Ну и на всякий, ssh-keygen -K “вытащит” из юбика публичный ключ прямо в текущий каталог. Правда, получившийся приватный ключ получится фейковым non-resident и все равно, без юбика ничего работать не будет.
