Лучшая система для управления ключами SSH? [закрыто]


42

У меня есть несколько клиентских компьютеров (например, ноутбуки, настольные компьютеры и т. Д.), И я подключаюсь к нескольким серверным компьютерам, которыми управляю, и подключаюсь к ним всем через SSH. Я могу представить несколько схем управления ключами SSH, которые имеют смысл, и мне любопытно, что делают другие.

Вариант 1: одна глобальная пара открытых / закрытых ключей.

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

Вариант 2: одна пара ключей на сервер.

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

Вариант 3: одна пара ключей на клиентский компьютер.

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

Вариант 4: одна пара ключей на пару клиент / сервер

Полностью за бортом?

Какой из них лучше? Есть ли другие варианты? Какие критерии вы используете для оценки правильной конфигурации?

Ответы:


33

Я использую вариант 3: одна пара ключей на клиентскую машину, и это имеет для меня наибольшее значение. Вот некоторые из причин:

  • Если клиент скомпрометирован, то этот ключ (и только этот ключ) необходимо удалить с серверов.
  • Он достаточно гибок, чтобы решить, к чему я могу получить доступ откуда угодно, не предоставляя общий доступ ко всем серверам от всех клиентов.
  • Очень удобно. Там только 1 ключ для ssh-add, нет путаницы.
  • Простота установки и администрирования через Вариант 4

Вариант 4 хорош, но просто слишком много работы. Вариант 3 дает вам 98% с гораздо меньшими хлопотами.


4
Я не вижу смысла в Варианте 4. Он вообще не имеет смысла.
niXar

26

Я использую решение, которое немного сложнее, но очень универсально, так как я хочу сохранить некоторое разделение в ключах идентификации 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 каталога Я создал keys.d в качестве символической ссылки на путь к каталогу на зашифрованном диске USB , когда он правильно установлен.

% Л выражение переводится как локальный клиентские машины имя хоста и % 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

Вы даже можете использовать выражение % r для поиска ключа, определенного для имени пользователя удаленного сервера, или % h для имени хоста удаленного сервера, точно так же, как были использованы % u и % l .

Обновление: теперь я фактически использую gn-agent GnuPG с совместимостью с ssh-agent, чтобы просто читать и использовать ключ аутентификации с моей смарт-карты OpenPGP v2.


Вау, отличное решение, спасибо! Мне нравится универсальный конфиг в ~ / .ssh / config
slacy

Оказалось, что довольно удобно держать вещи отдельно для работы, личных и консалтинговых клиентских сетевых серверов ... Я не хочу смешивать аутентификацию между ними, но хочу, чтобы мне было легко.
Джереми Бауз

Удивительно! Я действительно люблю это.
Балу

Я предполагаю, что вы используете разные USB-ключи для разных клиентских машин. Иначе какой смысл в отдельных ключах, если все они хранятся в одном месте? В случае нарушения вам нужно будет отозвать их все. Если (и возможно) я что-то упускаю, это, кажется, только усложняет ситуацию.
Халил Озгюр

@ HalilÖzgür, Да, я консультируюсь и не всегда хочу использовать один и тот же ключ. Поскольку USB-ключ зашифрован и не подключен к какому-либо компьютеру, за исключением случаев, когда он мне нужен для подключения, нет проблем с нарушением работы сервера, а пароль для расшифровки файловой системы диска достаточно длинный, чтобы сделать отзыв ключей достаточно простым.
Джереми Бауз

6

Я бы исключил оба варианта 1 (из которых я подозреваю, что один должен быть вариантом 2 ;-), потому что закрытые ключи являются конфиденциальными данными, и имеет смысл хранить их в как можно меньшем количестве мест). Лично я никогда не копировал бы закрытый ключ с одного компьютера на другой (или даже из одного файла в другой на том же компьютере), за исключением, может быть, резервного копирования. Хотя в отличие от большинства ключей шифрования, если ключ SSH теряется, это не конец света (просто создайте новый, вы не потеряете данные).


Да, переименован в правильный «Вариант 2», мне нравится правило «никогда не копировать закрытый ключ». Это хорошее правило.
рабство

1

Вариант 3 и использовать что-то вроде Puppet для управления ключами.


Является ли это reductivelabs.com/trac/puppet/wiki/PuppetIntroduction ссылкой на Puppet?
Энди

Да это оно. Обязательно ознакомьтесь с некоторыми примерами на сайте. Помогает увидеть, что уже сделали другие - не нужно изобретать велосипед.
ВИК

1

Вариант 3

Это также позволяет вам контролировать, к каким серверам клиент может получить доступ. например, если клиент X нуждается в доступе к серверам A и B, но C или D, вы копируете его открытый ключ только на эти хосты.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.