Как правильно создать пользователя «резервного копирования», который может читать все, чтобы создавать резервные копии с помощью rsnapshot?

Question

Я хотел бы использовать rsnapshot для резервного копирования моего локального компьютера, а также двух удаленных компьютеров на переносное устройство хранения. Мой план состоял в том, чтобы использовать rsnaphot на локальном компьютере, создать backup пользователя на удаленных машинах и разрешить моему локальному корневому пользователю обращаться к backup учетной записи через открытые ключи ssh. Я не хотел включать root, я думал, что это может быть функция безопасности.

Итак, проблема начинается: пользователь удаленного резервного копирования должен иметь возможность читать как можно больше. Как я могу сделать это? Я мог бы добавить этого пользователя в каждую существующую группу, таким образом он сможет читать каждый файл, который доступен для чтения группой. Но таким образом, этот пользователь также сможет записывать, удалять ... эти файлы. Или я мог бы изменить группу каждого файла на backup или какую-то еще, но, конечно, это было бы слишком агрессивно и, кстати, очень безумно.

Скопируйте открытый ключ моего локального корня в удаленную корневую учетную запись, и включение входа в систему root будет самым простым способом, а? Я должен это сделать?

Как это сделать правильно?

Answer 1

http://www.rsnapshot.org/howto/using-rsnapshot-and-ssh.html (веб-архив) мне очень помог. В итоге я использовал root на удаленных машинах, а также root на своей локальной машине (конечно, через sudo ).

Идея состоит в том, чтобы иметь несколько ключей и ограничить ключи определенными командами. Например, я настроил свой удаленный хост так, чтобы он не разрешал вход в систему с root , но позволял выполнять определенную команду (в моем случае я думаю, что это rsync, я должен признать, что я просто использовал validate-rsync как предложено в связанный документ, не думая слишком много), если аутентифицирован с открытым ключом. Поэтому, даже если у кого-то был доступ к моей локальной учетной записи root , он не мог войти в систему напрямую (да, он, возможно, мог бы rsync поврежденные файлы и некоторые другие, а также повредить allowed_keys и т.д.).

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