ризик використання відкритих ключів ssh

У мене є сервер A і сервер B (резервне копіювання), і мені було цікаво, якщо хтось може прорватися на сервер A, чи може це бути потенційно небезпечним для проникнення на сервер B, якщо я налаштував без паролів вхід за допомогою ssh-відкритих ключів?

Я намагаюся налаштувати rsnapshot.

Дякую

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

Ви можете зробити кілька заходів, щоб пом'якшити це:

• Якщо процес не потрібно повністю автоматизувати, додайте пароль до ваших ключів SSH. (Це, ймовірно, не підійде для вас, оскільки ви зазначаєте, що це резервне копіювання)
• Для входу без паролів під власним обліковим записом на декількох машинах я рекомендую створити парольний ключ для кожної машини, на якій ви фізично набираєте, і використовувати SSH-агент для зберігання ключа в пам'яті під час його використання. Переадресація агента повинна дозволяти вам переходити з хоста на хост, не створюючи ключів на кожному віддаленому хості.
• Для автоматизованих, без паролів ключів SSH я рекомендую обмежити команди, які може виконувати ключ. У своєму authorized_keysфайлі приставте кожну клавішу за допомогою:
  command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

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

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

• створити єдиний цільовий обліковий запис для роботи: тобто користувача dnssyncна кожній машині
• якщо це можливо, зробіть файли доступними для цього користувача, а не покладаючись на root
• для тих бітів, яким дійсно потрібен привілейований доступ, створіть сценарій для цього та використовуйте sudo
• використання command=та from=параметри у authorized_keysфайлах для обмеження клавіш без паролів
• для передачі файлів напишіть скрипт, щоб це зробити за допомогою rsync, на приймальній машині, щоб віддалений доступ міг бути доступним лише для читання
• якщо це означає, що потрібен доступ до ініціюючої машини з віддаленої машини, використовуйте, ssh-agentа не створюючи другий ключ без пароля

Є декілька проблем із ключами ssh:

Немає централізованого способу відкликання ключа.

Ні в якому разі не застосовувати політики щодо паролів на ключах (чи закритий ваш приватний ключ, і якщо так, чи він зашифрований з хорошим паролем?).

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

У будь-якому випадку, хоча ssh-дозволені_кеї дозволяють здійснювати атаки типу morris-черв'як , це все-таки краще, ніж сервіси .r та telnet миль (світловий рік)

У будь-якому середовищі, над яким я мав контроль, я завжди був справжнім стикером за мінімально можливі привілеї для облікових записів послуг.

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

Навіть у цьому випадку ви все ще зазнаєте помилок ескалації місцевих привілеїв, тому будьте ретельними та слідкуйте за помилками безпеки.