SSH: Безпечно для клієнта для розміщення приватного ключа RSA?

Чи безпечно генерувати пару на відкритому / приватному ключах на сервері, додати відкритий ключ до списку дозволених ключів, а потім скопіювати приватний ключ для кожного клієнта, як описано тут ( http://www.rebol.com/docs/ ssh-auto-login.html ) Припустимо, ви підтримуєте постійний контроль над кожним клієнтом? (тобто той самий користувач, багато комп'ютерів).

Типовою процедурою є генерування пари відкритого / приватного ключів на клієнті, а потім додати відкритий ключ клієнта до списку дозволених ключів на сервері, як описано тут ( http://www.linuxproblem.org/art_9.html ). Якщо у вас є декілька комп'ютерів-клієнтів, кожен з них повинен бути об'єднаний у список дозволених ключів і підтримуватися з часом.

Вітаємо, ви знайшли Інтернет-підручник з поганими порадами.

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

Що стосується цього підручника, напрочуд погана порада створити ключ на сервері та скопіювати приватний ключ до клієнта . Це цілком відстале. Натомість ключ клієнта повинен генеруватися на клієнті, а відкритий ключ скопіювати на сервер. Існує навіть помічник сценарію, ssh-copy-idякий робить саме це, і попутно переконує, що всі дозволи є правильними, клієнт отримує ключ хоста сервера тощо.

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

Найбільша проблема з протоколом, описаним у цьому підручнику, полягає в тому, що він не вказує, як ви "захищаєте приватний ключ на клієнтську машину" захищеним чином (тобто це запобігає підслуховуванню). Якщо у вас ще немає захищеного каналу, ключ, імовірно, буде перенесено через Інтернет (HTTP, FTP, електронна пошта тощо). Можна використовувати HTTPS, але якщо у вас немає справжнього сертифіката, MITM може нюхати ключ. Просто робіть так, як вам належить; згенерувати ключ на клієнтській машині, перенести відкритий ключ на сервер і не забудьте перевірити контрольну суму файлу, щоб переконатися, що він не був змінений при передачі.