Должен ли я создать новый закрытый ключ SSH в каждой системе?


10

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

Например, у меня есть основная настольная система на основе Ubuntu и MacBook Pro с ssh. И у меня есть нетбук на базе Windows с установленной Putty. И у меня есть телефон Android с ConnectBot. С любого из этих устройств мне может потребоваться SSH для подключения к десяткам различных физических и виртуальных серверов.

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

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

Ответы:


3

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

Я уверен, что вы используете защищенные паролем закрытые ключи?

В нашей практике управления мы выполняем «роли» с низким, средним и высоким уровнем безопасности. Каждая роль использует свой ключ. Закрытые ключи с высоким уровнем защиты никогда не следует передавать на внешние ресурсы, которые используются на ноутбуках, которые могут быть утеряны / украдены и т. Д. Ключи со средним и низким уровнем защиты можно использовать в более широком диапазоне сценариев.

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

Рассматривали ли вы возможность размещения своего закрытого ключа SSH на аппаратном устройстве, с которого его нельзя украсть, что исключает возможность потенциальной компрометации ключа в качестве проблемы?

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


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

2

Абсолютно, вы должны. Вы всегда можете добавить все ключи в свой файл author_keys2. Мне нравится предложение Jeffatrackaid. Однако я бы использовал разные закрытые ключи для каждого устройства - почему бы и нет. Потерять свой Android. Просто удалите ключ из списка авторизованных ключей. Если вы этого не сделаете, вам придется снова восстановить этот уровень ключа.

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


К вашему сведению, authorized_keys2устарел с 2001 года - теперь OpenSSH использует authorized_keys(хотя все еще читает оба файла для совместимости)
user1686

Ах, хорошо, спасибо. Я всегда обращаю внимание на отключение SSHv1, шифров с низкой прочностью и т. Д.

2

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

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

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

Для всего, что серьезно, я просто использую LDAP / PAM, на случай, если мне придется спешить удалить кого - то еще .

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