риск использования открытых ключей ssh

Да, это одна из проблем с SSH-ключами без пароля. Если вы храните закрытый ключ на сервере A, который позволяет вам подключаться к серверу B, получение доступа к серверу A фактически означает получение доступа к серверу B. (Не обратное неверно - получение доступа к серверу B не приведет к немедленная компрометация сервера A, при условии, что у вас также не настроены ключи SSH, позволяющие входить в систему без пароля в этом направлении.

Есть несколько способов смягчить это:

• Если процесс не требует полной автоматизации, добавьте пароль к своим SSH-ключам. (Это, вероятно, не сработает для вас, поскольку вы заметили, что это резервная копия)
• Для входа без пароля под вашей учетной записью на нескольких машинах я рекомендую создать ключ с паролем для каждой машины, на которой вы физически печатаете, и использовать агент SSH для хранения ключа в памяти, пока вы его используете. Переадресация агента должна позволять вам «перепрыгивать» с хоста на хост без создания ключей на каждом удаленном хосте.
• Для автоматических ключей SSH без пароля я рекомендую ограничить команды, которые может запускать ключ. В твоем authorized_keys файла, добавьте к каждому ключу префикс:
  command="<разрешенная командная строка здесь>",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 authorized_keys разрешает Моррис-червь типа атаки, по милям (световым годам) он все равно лучше, чем .r сервисы и телнет

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

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

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