Чи слід створити новий приватний ключ ssh для кожної системи?


10

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

Наприклад, у мене є основна настільна система Ubuntu та MacBook Pro з ssh. І в мене встановлена ​​нетбук на базі Windows з Putty. І в мене є телефон Android з ConnectBot. З будь-якого з цих пристроїв мені може знадобитися SSH для десятків різних фізичних та віртуальних серверів.

Кожен сервер потребує встановлення мого відкритого ключа. Крім того, для моїх облікових записів GitHub та Codaset потрібен мій відкритий ключ.

Для спрощення управління ключами я думаю використовувати один і той же приватний ключ для всіх цих систем. Це звичайна практика, чи краще мати приватний ключ у кожній системі?

Відповіді:


3

Якщо ви використовуєте один і той же відкритий ключ у кожній системі, і приватний ключ стає порушеним, то будь-яка система, що використовує цей ключ, забороняючи інші обмеження, буде доступною.

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

У нашій управлінській практиці ми маємо низькі, середні та високі "ролі" в безпеці. У кожній ролі використовується інший ключ. Приватні ключі високої безпеки ніколи не передаються до зовнішніх активів, використовуються на ноутбуках, які можуть бути втрачені / викрадені тощо. Ключі середньої та низької безпеки можна використовувати в більш широкому діапазоні сценаріїв.

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

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

Як захисні модулі, так і смарт-карти можна використовувати для безпечного зберігання приватних ключів SSH, що дозволяє виконувати всі криптографічні операції на пристрої, а не на ваших операційних системах. Однак вони не є панацеєю, оскільки для цього потрібні пристрої резервного копіювання, у разі відмови обладнання.


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

2

Абсолютно слід. Ви завжди можете додати всі ключі до файлу дозволеного_keys2. Мені подобається пропозиція jeffatrackaid. Однак я б використовував різні приватні ключі для кожного пристрою - чому б і ні. Втрачайте свій Android. Простий, видаліть ключ із списку дозволених ключів. Якщо цього не зробити, вам доведеться знову відновити цей рівень ключа.

Однак, це залежить від того, як ви сприймаєте ризик цих активів. Очевидно, ви не хочете втрачати ключі, але деякі ви можете піддавати більшому ризику, наприклад, github vs root, наприклад, для вашого vps.


FYI, authorized_keys2застаріла з 2001 року - OpenSSH зараз використовує authorized_keys(хоча все ще читає обидва файли для сумісності)
user1686

Ну добре дякую. Я завжди заважаю вимкнути SSHv1 та шифри низької міцності тощо

2

Ви пам’ятаєте, коли у Debian була така маленька проблема ентропії під час генерації SSH-ключів? Саме тоді я добре засвоїв свій урок.

У мене є свої приватні ключі для власних речей, наприклад, потрапляння на мої особисті сервери. У мене є ключ "Всецільовий", який переносить мене в більшість ящиків розробки, а потім вирізає ключі на кожного клієнта, який я обслуговую.

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.