Отримання приватного ключа від адміністратора сервера: нормально чи ні?

Я маю отримати доступ до віддаленого сервера SFTP. Адміністратор створив для мене користувача і створив для мене пару відкритих / приватних ключів. Потім він надійно надіслав мені файл приватного ключа, який я використовую для автентифікації. Я вважаю, що це не добре, я повинен створити пару ключів і дати йому відкритий ключ. Але я не в змозі придумати жодної вагомої причини, чому це погано, якщо я використовую цей ключ лише для входу на цей сервер, без інших серверів. Чи є такі причини?

authentication ssh-keys private-key

— matthiash
джерело

Погана гігієна безпеки для одного. Адміністратор сервера повинен краще знати, і не повинен «навчати» користувачів очікувати отримання приватних ключів із зовнішніх джерел.

— wmorrell

Кому ще він це дає? Завжди думайте, що найгірше, що могло статися?

— mckenzm

Я насправді не думаю, що це так погано. Нижче наведена аналогія (Ерік Тауерс) з наданням користувачеві "початкового пароля", який потім потрібно негайно змінити. Якщо говорити з особистого досвіду, пояснення того, які ключі користуються сто разів, може бути трохи стомлюючим - адміністратор все ще людина. Дати вам приватний ключ ліниво - так, але ніщо не може перешкодити вам замінити його самостійно. По суті, після того, як s / він надіслав його вам, вам більше не потрібно буде турбувати sysadmin (якщо вони не вирішили вимкнути дозволи на запис у файл ... тоді просто дратуйте їх).

— Рей

@matthiash це питання підходить для цього веб-сайту, але, як і FYI, є веб-сайт з інформаційної безпеки для інших питань безпеки.

— топ

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

— GnP

Відповіді:

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

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

— HBruijn
джерело

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

— cornelinux

Адміністратор повинен допомогти користувачеві створити та захистити приватний ключ.

— Алекс

Ви абсолютно праві. Але часто адміністраторам краще з комп'ютерами, ніж з людьми, -)

— cornelinux

Адміністратор може видати себе за будь-який випадок.

— користувач253751

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

— JamesRyan

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

Можливо, ви зможете скористатись наданими ключами правами запису, оновити свої авторизовані ключі та додати свій ключ та видалити наданий ключ.

— Зоредаче
джерело

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

— Ерік Тауерс

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

— жіноча

@EricTowers Чи можливо це вимагати навіть із сучасними реалізаціями SFTP (або навіть SSH, якщо ви самі не готові щось обробляти разом)?

— CVn

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

— JamesRyan

@marcelm: Є причина, чому я сказав "часто потрібно", а не "завжди абсолютно обов'язковий за будь-яких обставин, не виняток". Оскільки той, хто насправді регулярно запитує (і приймає) хеши для паролів та відкритих ключів, я знаю, що набагато більший бар'єр, щоб хтось надавав хешированний пароль (із захищеною сіллю та іншим), ніж відкритий ключ. Якщо у вас є клієнт SSH, у вас є інструмент генерації ключів. Те ж саме не можна сказати і для чогось здатного закликати crypt(2) у своїх багатьох розважальних формах.

— жіночий