У меня есть несколько клиентских компьютеров (например, ноутбуки, настольные компьютеры и т. Д.), Я подключаюсь к нескольким серверным машинам, которыми управляю, и вхожу на них все через SSH. Я могу представить несколько разумных схем управления ssh-ключами, и мне любопытно, что делают другие.
Я бы сгенерировал одну пару открытого / закрытого ключей и поместил закрытый ключ на каждую клиентскую машину, а открытый ключ - на каждую серверную машину.
Я бы сгенерировал одну пару ключей на каждой серверной машине и поместил каждый закрытый ключ на свои клиентские машины.
Каждая клиентская машина будет иметь уникальный закрытый ключ, а каждая серверная машина будет иметь открытые ключи для каждой клиентской машины, с которой я хотел бы подключиться.
Совершенно за борт?
Что из этого лучше? Есть ли другие варианты? Какие критерии вы используете для оценки правильной конфигурации?
я использую Вариант 3. Одна пара ключей на клиентский компьютер и для меня это имеет смысл. Вот некоторые из причин:
Вариант 4 это хорошо, но это слишком много работы. Вариант 3 доставит вам 98% с гораздо меньшими хлопотами.
Я использую решение, которое немного сложнее, но очень универсально, так как я хочу сохранить некоторое разделение ключей идентификации SSH, используемых для моих серверов домашней сети, офисных серверов, серверов клиентской сети и других различных систем, в которых у меня есть учетные записи.
Теперь, когда я сказал, что я работаю почти исключительно с рабочих станций Linux, у меня есть USB-ключ, который настроен с использованием шифрования LUKS, а мой оконный менеджер X11 вместе с демоном HAL обнаруживает зашифрованный диск LUKS и запрашивает парольную фразу для дешифрования, когда он вставляется и пытается быть установленным. Сохраняя это на зашифрованном диске, как я это делаю, я никогда не храню свои ключи SSH ни на одной рабочей станции.
Затем у меня есть следующая конфигурация в моем ~/.ssh/config файл:
Host *
Protocol 2
IdentityFile %d/.ssh/keys.d/id_rsa.%l
IdentityFile %d/.ssh/keys.d/id_dsa.%l
IdentityFile %d/.ssh/keys.d/%u@%l
В % d преобразуется в домашний каталог пользователя OpenSSH и в ~ / .ssh каталог, который я создал ключи.d как символическую ссылку на путь к каталогу на зашифрованном USB-накопителе, когда он правильно установлен.
В % l выражение переводится как имя хоста локального клиентского компьютера и % u будет переведено на имя пользователя локального клиента.
Эта конфигурация позволяет SSH искать ключ, используя 3 разных выражения. Например, если имя пользователя моего локального клиента было jdoe и имя моей локальной клиентской машины было examplehost он будет искать в следующем порядке, пока не найдет ключ, который существует и был принят удаленным сервером.
/home/jdoe/.ssh/keys.d/id_rsa.examplehost
/home/jdoe/.ssh/keys.d/id_dsa.examplehost
/home/jdoe/.ssh/keys.d/jdoe@examplehost
Вы даже можете использовать %р выражение для поиска ключа, специфичного для имени пользователя удаленного сервера или %час для имени хоста удаленного сервера, как и % u и % l были использованы.
Обновление: теперь я фактически использую GnuPG gpg-agent с совместимостью с ssh-agent, чтобы просто читать и использовать ключ аутентификации на моей смарт-карте OpenPGP v2.
Я бы исключил оба ваших варианта 1 (из которых, как я подозреваю, один должен был быть вариантом 2 ;-), потому что закрытые ключи являются конфиденциальными данными, и имеет смысл хранить их в как можно меньшем количестве мест. Я лично никогда бы не скопировал закрытый ключ с одного компьютера на другой (или даже из одного файла в другой на том же компьютере), за исключением, возможно, создания резервных копий. Хотя, в отличие от большинства ключей шифрования, потеря SSH-ключа - это еще не конец света (просто создайте новый, вы не потеряете никаких данных).
Вариант 3 и используйте что-то вроде Puppet для управления ключами.
Вариант 3.
Это также позволяет вам контролировать, к каким серверам клиент может получить доступ. например если клиенту X нужен доступ к серверам A и B, но C или D, вы копируете его открытый ключ только на эти хосты.