¿Cuál es la forma correcta de tener un usuario de "respaldo" que pueda leer todo para crear copias de seguridad con rsnapshot?

¿Cuál es la forma correcta de tener un usuario de "respaldo" que pueda leer todo para crear copias de seguridad con rsnapshot?

Me gustaría usar rsnapshot para hacer una copia de seguridad de mi computadora local y de dos máquinas remotas en un dispositivo de almacenamiento portátil. Mi plan era usarlo rsnaphoten la máquina local, crear un backupusuario en las máquinas remotas y permitir que mi raíz local acceda a la backupcuenta a través de claves públicas ssh. No quería habilitar el inicio de sesión como root, pensé que podría ser una característica de seguridad.

Entonces comienza el problema: el usuario de respaldo remoto debería poder leer tanto como sea posible. ¿Cómo puedo lograr esto? Podría agregar este usuario a cada grupo existente, de esta manera podrá leer todos los archivos que sean legibles por el grupo. Pero de esta manera, este usuario también podría escribir, eliminar,… esos archivos. O podría cambiar el grupo de cada archivo backupo algo así, pero, por supuesto, esto sería demasiado invasivo y, por cierto, muy loco.

Copiar la clave pública de mi raíz local a la cuenta de raíz remota y habilitar el inicio de sesión de raíz sería la forma más fácil, ¿eh? ¿Debería hacerlo?

¿Cómo se hace esto correctamente?

Respuesta1

http://www.rsnapshot.org/howto/using-rsnapshot-and-ssh.html (Archivo web)me ayudo mucho. Terminé usándolo rooten las máquinas remotas y también rooteando en mi máquina local (a través de, sudopor supuesto).

La idea es tener varias claves y restringirlas a ciertos comandos. Por ejemplo, configuré mi host remoto de una manera que no permite rootiniciar sesión, pero permite ejecutar un determinado comando (en mi caso creo que es rsync, debo admitir que solo usé el validate-rsyncscript como se sugiere en el documento vinculado sin pensar). demasiado) si se autentica con clave pública. Así que incluso si alguienteníaAl acceder a mi rootcuenta local, no pude iniciar sesión directamente (sí, tal vez podría sincronizar archivos corruptos y algo así, también corromperlos, allowed_keysetc.).

Por el momento, creo que este es el mejor equilibrio entre usabilidad y seguridad.

información relacionada