24 marzo, 2016

Backups remotos con rsync a través de ssh sin contraseña

Por jdiaz JDomo 0 comentarios

«Si la copia de seguridad se hace, y además está correcta, en el momento que sea necesario hacer uso de ella fallará el soporte donde se haya hecho»

Lo dice una ley de Murphy, y efectivamente, me ha pasado… Y como de sabios es rectificar (depurar, que diría un servidor), aquí tenemos esta entrada en el blog.

En una entrada anterior vimos como hacer un backup de las partes que nos interesaran de un sistema (ver aquí), y al final dejaba como posibilidad el poder enviar los backups a un servidor SFTP o similar. Pues en esta entrada vamos a ver como hacerlo.

Tenemos dos sistemas, el Cliente, del que queremos hacer la copia de seguridad, y enviarla de forma segura y automática al Servidor. Una herramienta muy útil para esto es rsync, ya que nos compara los ficheros en origen y en destino y solo envía los cambios hacia el destino, con los ahorros de ancho de banda que ello implica. En la entrada que os comentaba arriba, veíamos como hacer copia de todo el sistema a nivel de sistema de archivos (dispositivo de bloques), como la copia es semanal, los cambios son mínimos (base de datos, gráficas de cacti, logs y poco más) por tanto rsync se ajusta bastante a lo que necesitamos.

Vamos a ello.

Lo primero que necesitamos hacer es crear un usuario en nuestro Servidor (equipo que recibirá las copias a través de rsync/SSH), ya que después lo usaremos para logearnos desde el equipo Cliente y enviar la información (no conviene usar el usuario root, por motivos obvios de seguridad). Luego crearemos las carpetas donde ese usuario tendrá permiso de escritura, y finalmente crearemos el certificado (clave pública y clave privada, en realidad el cliente usará la clave privada para acceder al servidor y éste la clave pública para verificarla) con el que ese usuario se podrá logear en el Servidor, desde el Cliente, a través de SSH:

En el Servidor

root@servidor:~# addgroup jdomo
Adding group `jdomo` (GID 1003) ...
Done.
root@servidor:~# adduser --ingroup jdomo jdomo
Adding user `jdomo` ...
Adding new user `jdomo` (1003) with group `jdomo` ...
Creating home directory `/home/jdomo` ...
Copying files from `/etc/skel` ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for jdomo
Enter the new value, or press ENTER for the default
    Full Name []: Usuario para Backups
    Room Number []:
    Work Phone []:
    Home Phone []:
    Other []:
Is the information correct? [Y/n] Y

root@servidor:~# mkdir /mnt/Compartido/jdomo/backup

root@servidor:~# mkdir /mnt/Compartido/jdomo/backup/img

root@servidor:~# chown jdomo:jdomo -R /mnt/Compartido/jdomo/backup

root@servidor:~# ls -ali /mnt/Compartido/jdomo
total 1444
77332481 drwxr-xr-x 4 root root 4096 Mar 23 21:29 .
2 drwxr-xr-x 8 root root 4096 Mar 18 11:49 ..
77332482 drwxr-xr-x 3 jdomo jdomo 4096 Mar 14 13:26 backup

root@servidor:~#

Ya tenemos el usuario creado, y las carpetas donde almacenaremos los datos que recibamos, con los permisos oportunos dados.

En el Cliente

Una vez creado el usuario en el Servidor, podemos comprobar que el acceso desde el Cliente funciona correctamente, usando la contraseña que le hayamos puesto al usuario jdomo:

root@cliente:~# ssh jdomo@servidor
jdomo@servidor's password:
Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.10.80-121 armv7l)
* Documentation:  https://help.ubuntu.com/

33 packages can be updated.
5 updates are security updates.

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

root@servidor:~#

Para poder automatizar el envío de ficheros a través de rsync y ssh necesitamos decirle a nuestro Servidor que con determinado certificado (que crearemos a continuación), vamos a permitir loguearse al usuario jdomo en el sistema, sin necesidad de usar contraseña (en su lugar usará un certificado). Vamos a crearlo, y cuando nos pregunte la passphrase debemos dejarla en blanco (muy importante, si no, al usarlo nos la preguntará, y no es lo que queremos):

root@cliente:~# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/jdomo_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/jdomo_rsa.
Your public key has been saved in /root/.ssh/jdomo_rsa.pub.
The key fingerprint is:
68:e7:1a:a7:65:7d:90:70:2b:56:21:59:ca:12:1a:8e root@cliente
The key`s randomart image is:
+--[ RSA 2048]----+
|    . . .oo      |
|   o o o.o .     |
|  E o . + o      |
|       o + o     |
|      o S +      |
|     . + o .     |
|      . = . .    |
|       B   .     |
|      o          |
+-----------------+

root@cliente:~# ls .ssh/
jdomo_rsa  jdomo_rsa.pub

root@cliente:~# cat .ssh/jdomo_rsa.pub | ssh jdomo@servidor `cat >> .ssh/authorized_keys`
The authenticity of host `servidor (192.168.3.35)` can`t be established.
ECDSA key fingerprint is a2:84:83:8c:49:4d:33:0d:43:1f:d8:9a:b5:8a:fb:6d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added `servidor` (ECDSA) to the list of known hosts.
jdomo@servidor's password:

root@cliente:~#

Ahora solo tenemos que acceder al servidor usando la clave privada (archivo que no acaba en .pub) que nos acaba de generar, y ¡listo!:

root@cliente:~# ssh -i .ssh/jdomo_rsa jdomo@servidor

Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.10.80-121 armv7l)

* Documentation: https://help.ubuntu.com/

Last login: Thu Mar 24 14:33:59 2016 from 192.168.2.216
jdomo@servidor:~$

Con todo esto ya tenemos el login automático del usuario jdomo preparado, solo nos queda enviar los archivos mediante algún comando desde el cliente hacia el servidor, y vivir más tranquilos, sabiendo que tenemos nuestra copia en dos lugares distintos (por si las moscas…).

Enviando nuestro backup con rsync de forma segura

Uno de los modos de envío de ficheros de rsync es a través de un túnel ssh. Suponiendo que tenemos en nuestro equipo Cliente, los archivos de imagen del sistema de archivos en /mnt/Data/backup/img, podemos enviarlos de forma segura mediante el siguiente comando rsync:

root@cliente:~# ls -ali /mnt/Data/backup/img
total 2008896
1332741 drwxr-xr-x 2 root root      4096 mar 23 22:41 .
1320779 drwxr-xr-x 3 root root      4096 mar 24 06:25 ..
1320787 -rw-r--r-- 1 root root 209715200 mar 23 21:29 mmcblk1.img.aa
1320788 -rw-r--r-- 1 root root 209715200 mar 23 21:36 mmcblk1.img.ab
1320789 -rw-r--r-- 1 root root 209715200 mar 23 21:47 mmcblk1.img.ac
1320790 -rw-r--r-- 1 root root 209715200 mar 23 21:58 mmcblk1.img.ad
1320791 -rw-r--r-- 1 root root 209715200 mar 23 22:06 mmcblk1.img.ae
1320792 -rw-r--r-- 1 root root 209715200 mar 23 22:15 mmcblk1.img.af
1320793 -rw-r--r-- 1 root root 209715200 mar 23 22:24 mmcblk1.img.ag
1320794 -rw-r--r-- 1 root root 209715200 mar 23 22:32 mmcblk1.img.ah
1320795 -rw-r--r-- 1 root root 209715200 mar 23 22:41 mmcblk1.img.ai
1320796 -rw-r--r-- 1 root root 169621072 mar 23 22:55 mmcblk1.img.aj

root@cliente:~# rsync -av --progress -e "ssh -i /root/.ssh/jdomo_rsa" \
/mnt/Data/backup/img/mmcblk1.img* jdomo@servidor:/mnt/Compartido/jdomo/backup/img
sending incremental file list
mmcblk1.img.aa
    209,715,200 100%    3.34MB/s    0:00:59 (xfr#1, to-chk=9/10)
mmcblk1.img.ab
    209,715,200 100%    3.28MB/s    0:01:00 (xfr#2, to-chk=8/10)
mmcblk1.img.ac
    209,715,200 100%    3.32MB/s    0:01:00 (xfr#3, to-chk=7/10)
mmcblk1.img.ad
    209,715,200 100%    3.20MB/s    0:01:02 (xfr#4, to-chk=6/10)
mmcblk1.img.ae
    209,715,200 100%    3.26MB/s    0:01:01 (xfr#5, to-chk=5/10)
mmcblk1.img.af
    209,715,200 100%    3.33MB/s    0:01:00 (xfr#6, to-chk=4/10)
mmcblk1.img.ag
    209,715,200 100%    3.29MB/s    0:01:00 (xfr#7, to-chk=3/10)
mmcblk1.img.ah
    209,715,200 100%    3.25MB/s    0:01:01 (xfr#8, to-chk=2/10)
mmcblk1.img.ai
    209,715,200 100%    3.25MB/s    0:01:01 (xfr#9, to-chk=1/10)
mmcblk1.img.aj
    169,621,072 100%    3.13MB/s    0:00:51 (xfr#10, to-chk=0/10)

sent 2,057,560,687 bytes  received 206 bytes  3,432,128.26 bytes/sec
total size is 2,057,057,872  speedup is 1.00

root@cliente:~# rsync -av --progress -e "ssh -i /root/.ssh/jdomo_rsa" \
/mnt/Data/backup/img/mmcblk1.img* jdomo@servidor:/mnt/Compartido/jdomo/backup/img
sending incremental file list

sent 213 bytes  received 12 bytes  150.00 bytes/sec
total size is 2,057,057,872  speedup is 9,142,479.43

Si comparamos con una copia completa normal, con scp, tenemos que la primera copia con rsync y scp tardan más o menos lo mismo, pero las siguientes (si los ficheros originales no varían), con rsync es instantánea, pero con scp no (tarda lo mismo que si no estuvieran los archivos en destino).

root@cliente:~# scp -i /root/.ssh/jdomo_rsa /mnt/Data/backup/img/mmcblk1.img* \
jdomo@192.168.3.35:/mnt/Compartido/jdomo/backup/img
mmcblk1.img.aa                                          100%  200MB   3.3MB/s   01:00    
mmcblk1.img.ab                                          100%  200MB   3.4MB/s   00:59    
mmcblk1.img.ac                                          100%  200MB   3.4MB/s   00:59    
mmcblk1.img.ad                                          100%  200MB   3.3MB/s   01:00    
mmcblk1.img.ae                                          100%  200MB   3.2MB/s   01:03    
mmcblk1.img.af                                          100%  200MB   3.3MB/s   01:01    
mmcblk1.img.ag                                          100%  200MB   3.2MB/s   01:02    
mmcblk1.img.ah                                          100%  200MB   3.3MB/s   01:00    
mmcblk1.img.ai                                          100%  200MB   3.3MB/s   01:00    
mmcblk1.img.aj                                          100%  162MB   3.4MB/s   00:48    

root@cliente:~#

Tan solo nos queda insertar el comando rsync anterior en un archivo, darle permisos de ejecución y ponerlo dentro de /etc/cron.daily para que se ejecute cada día. Si ejecutamos el envío de los archivos al servidor con rsync cada día, pero los archivos los generamos una vez a la semana, nos aseguramos de que se hacen 7 intentos de envío de los archivos entre copia semanal y copia semanal. No esta mal pensado ya que la conexión puede fallar por mil motivos (se corta la conexión de internet, el servidor y el cliente no están activos a la vez, …), y si se hacen varios intentos de copia, si la primera se completa, las siguientes no tardarán nada, ya que los archivos ya estarán en destino (y no se consumirá casi ancho de banda).

Y con esto, ya tenemos el sistema un poco más seguro… o no… jajajajaaaa 🙂