универсальны для защиты ключей ssh

u2f наверное не про это. Пробовал u2f такой https://github.com/Crystalix007/U2FDevice
С namecheap работает, файл с ключами в plain text лежит.

А если ключ сгорит?

Это вопрос. У физических ключей вроде как не особо предусматривают варианты бэкапов, несекурненько типа.

Взял юбикей 5 nfc и хрен что можно понять с ним

Если првильно понимаю, то разные ключи могут поддерживать разные протоколы, потому и путаница, каждый лепит свой комбайн. Надо про каждый внимательно смотреть

Взял юбикей 5 nfc и хрен что можно понять с ним. Ключи для ssh, что с ними генерятся, работают без всякого ключа

напиши хотя бы, как генеришь их и как они потом работают. Хрустальных шаров тут нет ни у кого)

https://github.com/drduh/YubiKey-Guide

Купи криптовалютный аппаратный кошелёк (лучше сразу два). Некоторые поддерживают fido u2f, ssh, openpgp и кучу крипто тугриков (ledger например). Один девайс держишь в одном месте, другой в другом, или таскаешь с собой. Если один девайс пролюбил, покупаешь новый и восстанавливаешь все свои ключи по сид фразе, или генерируешь новые. В любом случае у тебя остаётся доступ ко всем твоим данным и бедкойнам.

А вообще удивляет, что на дворе почти середина 21в., а проблема 2fa так в интернетах толком и не решена, хотя технологиям типа ключей с мультиподписями уже сто лет в обед.

Отдельный вопрос, какие ключи позволяют импортировать в них ключи, а не только генерировать их на устройстве?

Никакие. В этом их суть.

Если тебе просто хочется держать несколько копий ssh ключей, тебе аппаратный ключ не нужен.

держать несколько копий ssh ключей, тебе аппаратный ключ не нужен

Иногда хочется странного: аппаратный ключ всегда с собой, а его цифровое содержимое где-нибудь в сейфе для ситуации пролюбливания и безболезненного восстановления полной копии.

Иногда хочется странного: аппаратный ключ всегда с собой, а его цифровое содержимое где-нибудь в сейфе для ситуации пролюбливания и безболезненного восстановления полной копии.

Зачем? Надо так организовывать свой доступ, что бы потеря ключа не приводила к потере доступа.

Надо так организовывать свой доступ

На словах-то да, все Львы Толстые
А как это делать на практике при наличии массы стандартов, разных подходах у разных сервисов и т.д. мало кто представляет.

А что тут странного, если это - стандартная практика?

Приватный ключ генерируется на доверенной машине, записывается на аппаратный токен, копия сохраняется подальше в надёжном месте. Руководитель организации имеет на крайний случай доступ к приватным ключам сотрудников.

Если ключ для подписи, то тогда резервировать его не нужно.

Моё «странное» в том, что вроде как нынешние общеупоребительные хардварные ключи не имеют возможности делать бэкапы.

Для быстрого доступа можно просто мобилу использовать с openkeychain. Смысл аппаратного ключа как раз в том, чтобы он сам генерировал ключи, которые без этого девайса использовать невозможно.

хардварные ключи не имеют возможности делать бэкапы

Имеют. Например, все ключи в ledger можно восстановить по сид фразе. Только фразу эту нужно хранить как зеницу ока.

Ты не понял. Можно генерировать приватный ключ сразу на смарт карте, тогда его копии гарантированно нет нигде. Это применяют для цифровой подписи.

А можно генерировать ключ на доверенной машине и записывать его на смарт карту.

А «бекап» тебе не даст сделать ни одна смарт карта, в этом ее смысл.

Руководитель организации имеет на крайний случай доступ к приватным ключам сотрудников.

Руководитель имеет подписанный ssh-сертификат на role-access, имеющий principal руководителя.

Ну и сотрудники получают role-access к серверам на основе кратко-живущих сертификатов, пофиг, на основе каких ключей, так-как сами ключи не авторизуются на серверах, и толку от утери этих ключей нет никакого.

В общем, схема стандартная.

А в HSM храним ключи CA - три штуки на трех разных устройствах.

Моё «странное» в том, что вроде как нынешние общеупоребительные хардварные ключи не имеют возможности делать бэкапы.

Хардверные ключи для этого и придумали, что бы генерить неэкспортируемые ключи, что бы владение устройством означало однозначное владение ключем. «Бакап» тупо уничтожает саму суть железного ключа.

Ну не придирайся уж, смысл же ясен. Дело не в том, как назвать - «бэкап» или «ранее сгенерённый ключ». Хочется возможности беспроблемного восстановления в случае, когда ключ перестал работать, упав в лужу с соляным раствором.

не даст сделать ни одна смарт карта

Очень даже даст, если апплет там твой собственный.

Хочется возможности беспроблемного восстановления в случае, когда ключ перестал работать, упав в лужу с соляным раствором.

В самом примитивном случае - 2 ключа. Один носишь, другой - в сейфе. Авторизуешь на всех рабочих серверах оба публичных ключа.

тупо уничтожает саму суть железного ключа

Тогда нужно уточнять, что за ключи и сфера использования.
Мне вот будет греть душу знание о потенциальной несложной возможности восстановления доступа, если я протрачу хардварный токен для логина на сайт с бабами.
В данном случае железный ключ это аналог стойкого неупираемого пароля. Чем плохо иметь возможность забэкапить такой ключ (u2f например)?

Ключи - это всего-лишь инструмент, а не уникальное, нотариально-заверенное завещание.

Просто не должно быть ситуаций, когда доступ восстанавливается на стороне утерянного ключа. Доступ должен восстанавливаться на стороне сервера путем авторизации нового. А сам ключ просто упрощает авторизованный доступ.

В данном случае железный ключ это аналог стойкого неупираемого пароля. Чем плохо иметь возможность забэкапить такой ключ (u2f например)?

Бакап превращает его в упираемый, не? :)

Ну там гайд на три строчки

ssh-keygen -t ecdsa-sk работает, генерит пару в ~/.ssh, ключ после этого реально не нужен

ssh-keygen -t ecdsa-sk -O resident уже не работает. судя по выводу fido-token, он не поддерживает хранение ключей в себе.

ssh-keygen -t ed25519-sk не работает ни в каком виде. Похоже, этот алгоритм не поддерживается вовсе. Все это хотелось бы узнавать до покупки…

Бакап превращает его в упираемый, не?

Если бэкап обезличен и защищён от протрачивания лучше железного ключа, то нет.

А вот ещё стало интересно, те, кто вообще пользуется железными ключами, пользуются проприетарными или исключительно open hardware/source?

Криптопро вполне себе имеет функцию копирования.

Большинство токенов имеют функцию импорта ключей. Этого более чем достаточно. И да, неизвлекаемость кдюча это хорошо, поскольку позволяет выдавать ключ на время.

ну так я и взял два ключа для этого. Тот еще вариант, учитывая то, что некоторые сервисы вполне могут не позволять вписывать два ключа и то, что необходимо проверять работу второго ключа, что может оказаться весьма хлопотно.

Нашел табличку сравнения.

https://yubikey.ru/compare-yubikey/

По ней выходит, что я взял не yubikey, а security key. Убогая поделка, в общем.

Мой ключ не поддерживает pgp

Вот ещё такое есть

https://solokeys.com/

Я, правда, в итоге Yubikey 5 купил, но выглядит интересно.

nano или обычный?

ssh-keygen -t ecdsa-sk -O resident поддерживает?

Неизвлекаемые ключи сделаны для защиты от угона ключа троянами и прочей вирусней. Импортировать при этом ключ можно без проблем.

А аппаратные криптокошельки в этом плане полный маразм, если импортировать нельзя и извлечь нельзя. При этом он выдает тебе словарь из нескольких слов для полного восстановления приватного ключа на любом постороннем девайсе, любым человеком.

Обычный.

Для SSH я GPG использую, но вечерком могу проверить ssh-keygen (если оно, конечно, не потрёт мне существующие ключи).

Не работает

Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator: 
Key enrollment failed: requested feature not supported

Версия прошивки 4.2.8.

Неизвлекаемые ключи сделаны для защиты от угона ключа троянами и прочей вирусней

Интересная теория, но кто мешает делать аппаратные ключи, которые могут делать бэкап по пин коду, допустим, а не просто так по просьбе любого трояна.

А что мешает трояну подсмотреть пин-код и утащить ключ?

Хотя для бэкапа, конечно, можно и отдельный пин сделать.

но кто мешает делать аппаратные ключи, которые могут делать бэкап по пин коду, допустим

Видимо, в этом случае он превращается из аппаратного ключа (гарантирующего физическое владение ключом) в обычную хранилку ключей, мало отличающуюся, например, от USB-storage.

Вообще-то резервное копирование в аппаратных ключах не обязательно. Вполне достаточно иметь однонаправленный импорт в токен.

И как я посмотрел, в полной версии ubikey импорт есть.

https://www.aliexpress.com/item/4000913035210.html

https://wiki.makerdiary.com/nrf52-u2f/

Можешь бэкапить, разрешаю.

в обычную хранилку ключей, мало отличающуюся, например, от USB-storage.

На самом деле, это просто отсутствие возможности снять бэкап с всей памяти стандартными средствами. На защищённость особо не влияет.

Вон выше скинул, можешь делать ключ и бэкапить себе на здоровье. Снимешь dd полный дамп, потерял - залил его на такой же донгл.

В криптоключах защищённые данные хранятся в специальной памяти, которую расковырять нельзя даже при физическом доступе и хитром оборудовании.

Ну или по крайней мере это максимально усложнено.

Сдампить не выйдет.

Проверил на yubikey 5 nano прошивка Firmware: 5.2.7

С дикими особенностями, но работает все:

ssh-keygen -t ecdsa-sk -О resident

ssh-keygen -t ed25519-sk -О resident

Из особенностей пин-код запрашивает только при добавлении ключа через ssh-add -K, потом при соединении требует только прикосновение. Ну и как требует, молча висит, пока не прикоснешься к ключу. Никаких приглашений нет.

Другая особенность, в токене есть место только под один ключ. При генерации следующего ключа текущий просто молча затирается! Это прям лютый вин.

И все равно это слабый вариант, поскольку есть требования к версии openssh на сервере. На соединении к centos 7 на сервере пишет в лог

userauth_pubkey: unsupported public key algorithm: sk-ecdsa-sha2-nistp256@openssh.com [preauth]

и не работает. С openssh 8.5 на сервере работает как надо. Но это все таки пока редкость…

все верно, поддержка таких ключей появилась в OpenSSH только в прошлом году. Если это не вариант, то придётся использовать gpg - оно умеет прикидываться ssh клиентом

которую расковырять нельзя даже при физическом доступе и хитром оборудовании.

Я тебе скинул, там обычный чип памяти. Её не нужно расковыривать, дампь прям как есть, зашифрованный раздел.

Сдампить не выйдет.

Если вся память доступна на чтение, то почему нет.

Такое не нужно. У юбикея например так не получится.

У юбикея например так не получится.

Такое есть, пример выше. Что там у проприетарщины от юбекеев нельзя, меня особо не интересует. Если бы юбикей хотел реализовать возможность снятия бэкапа, то сделал бы это.

И это никак бы не повлияло на безопасность.

Это сильно влияет на безопасность. Токен я могу дать человеку и знаю, что он его не скопирует. А твою штуку вполне можно.

Это сильно влияет на безопасность. Токен я могу дать человеку и знаю, что он его не скопирует. А твою штуку вполне можно.

Если ты даёшь токен передоверенному лицу, то в безопасности ты конечно спец. Он с ним и так стащит всё что ему нужно, без всякого бэкапа.

Это норма, например, это бухгалтер. Ключ у него. Уволился, ключ сдал.

Охохохоооо. Ну не знаю, где это норма. В нормальных организациях, вообще-то, если сотрудник уволился, его доступ отзывают, а новому сотруднику дают доступ с новым ключом. Только так.

Если речь про свою систему - да. А если речь про сторонние организации, где отзыв ключа это целая история и многа денек, это уже другое. Кроме того, это может быть аккаунт организации в каком нибудь отзовике. Нахрен постоянно теребонькать ключи туда-сюда, если можно просто дать ключ-взять ключ? Ты каждый раз личины меняешь в замке, когда просишь знакомого дверь твою открыть, например, цветы полить? А ведь эти ключи копируемые в любом металлоремонте, а были бы некопируемые, какие бы ты выбрал?

Это норма, например, это бухгалтер. Ключ у него. Уволился, ключ сдал.

U2F key вообще у бухгалтера не норма, что за вымышленные истории.

И уж тем более юбикеи у бухгалтеров, придумай что нибудь поинтересней.

Тут то крупные сервисы всё никак не разродятся на u2f, а у тебя уже бухгалтеры бегают с ними.

Кроме того, это может быть аккаунт организации в каком нибудь отзовике. Нахрен постоянно теребонькать ключи туда-сюда, если можно просто дать ключ-взять ключ?

Обычные usb токены, которые пачками за копейки продаются. Но нет, у тебя каждый раз все в организации бегают и usb брелками обмениваются.

Ты каждый раз личины меняешь в замке, когда просишь знакомого дверь твою открыть, например, цветы полить? А ведь эти ключи копируемые в любом металлоремонте, а были бы некопируемые, какие бы ты выбрал?

Ты что-то фильмов пересмотрел. Обычно если у тебя от квартиры стырили ключ, твоя квартира становится пустой максимально быстро. Никто не делает дубликат твоего ключа, и не пытается вернуть тебе оригинал.

Так и с твоим токеном будет. Возьмут какую надо информацию и всё. Дальше либо скопируют и вернут ключ, либо пропадут вместе с информацией.

На что в этой ситуации влияет бэкап ключа не совсем понятно, кроме того что он тебе не нравится просто так.