риск использования открытых ключей 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 авторизованные_ключи допускают атаки типа « Морриса-червя », они все же лучше, чем сервисы .r и telnet в милях (световых годах)

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

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

Даже в этом случае вы по-прежнему подвержены локальным ошибкам повышения привилегий, так что будьте внимательны и тщательно отслеживайте ошибки безопасности.