Чому я повинен використовувати аутентифікацію з відкритим ключем для SSH?

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

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

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

Можливо, мені краще подати двофакторну автентифікацію.

Чи є якийсь аргумент, який я пропускаю? Який найкращий спосіб для мене?

якщо хтось зламає мій комп'ютер, він не просто отримує мій комп'ютер, але і мій сервер?

Це все одно вірно з кейлоггерами: як тільки ви увійдете на свій сервер зі зламаного комп'ютера, вони отримують пароль.

Але є три переваги для клавіш:

1) Кеш аутентифікація. Введіть свою парольну фразу один раз, виконайте кілька команд ssh. Це дуже корисно, якщо ви використовуєте щось, що використовує ssh як транспорт, наприклад scp, rsync або git.

2) Масштабована аутентифікація. Введіть свою парольну фразу один раз, увійдіть на кілька машин . Чим більше у вас машин, тим корисніше це. Якщо у вас 100 машин, що ви робите? Ви не можете використовувати той самий пароль (якщо це не ферма-клон), і ви не можете запам’ятати стільки. Тож вам доведеться використовувати менеджер паролів, і ви повернетесь до єдиної точки компромісу. Ефективно ключовою парольною фразою є ваш менеджер паролів.

2b) Це масштабується інакше, якщо у вас є кілька адміністраторів, які використовують одні і ті ж системи, оскільки ви можете відкликати ключі від користувача A, не повідомляючи B, C, D, E, F ..., що пароль змінився.

(Це також можна зробити з окремими акаунтами та судо, але тоді вам доведеться якось надати ці акаунти)

3) Автоматизація та часткове делегування. Ви можете налаштувати SSH для запуску певної команди, коли підключається ключ . Це дає змогу автоматизованому процесу в системі A робити щось у системі B, не маючи повної довіри без паролів між ними.

(Це заміна rlogin / rsh, який був весело небезпечним)

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

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

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

Є подібні повідомлення:

1. Опублікувати з сервера за замовчуванням .
2. Повідомлення від безпеки stackexchange .
3. Повідомлення від суперпользователя .

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

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

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

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

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

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

Ви маєте рацію щодо претензії "вам не потрібен пароль". Це дійсно небезпечно з боку клієнта.

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

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

Можливо, мені краще подати двофакторну автентифікацію.

Одна з можливостей 2FA для SSH (і така, що вимагає відносно невеликої настройки / складності) - це фактично використання відкритого ключа та пароля.

Я вірю, що щось AuthenticationMethods publickey,keyboard-interactiveможна зробити, /etc/ssh/sshd_configщоб зробити цю роботу.

Загалом, проблема полягає в тому, що паролі (поодинці) не є чудовим методом аутентифікації, оскільки вони часто мають сумнівну якість. Дуже простий «аргумент» для ключів проти паролів полягає в тому, що ключ, як правило, буде не менше 2048 біт, а часто і більше (для ключів EC, це буде ефективнішою силою, а не фактичним розміром). Ці біти також генеруються за допомогою криптологічно захищеного (або відповідного) механізму.

Пароль часто менше 2048 біт і часто не отримується з криптографічно захищеного джерела.

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

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