Realizar copias de seguridad remotas con llaves SSH de propósito único

Introducción.

Es muy común que se deban desarrollar actividades en los servidores así como el subir y descargar archivos necesarios para o producto de estas actividades.  Un caso muy especial de este tipo de necesidades es la realización de copias de seguridad.

Del lado del servidor se acostumbra (si no se opta por una solución mas elaborada) crear scripts (1 y 2) que crean las copias empaquetadas de los archivos los cuales deben ser resguardados.  Generalmente la ejecución de esta tarea se realiza periódica y automáticamente a través de un proceso cron del sistema operativo.  Queda pendiente el problema de transferir esta información desde el servidor hasta el equipo local de manera segura y en lo posible automatizada.

La mejor opción para el transporte de los archivos es utilizar un método seguro basado en SSH, sin embargo el uso de contraseñas entorpece el desarrollo ya que estas dificultan la implementación y se constituyen como un riesgo ya que estas deben estar disponibles de manera legible en el cliente para ejecutar la utilidad de transferencia de archivos (como scp).

Gracias a la flexibilidad del protocolo SSH, es posible obviar la autenticación por contraseñas y utilizar un método basado en llaves, a través del cual se autoriza en el servidor el acceso directo a los usuarios que tengan su llave registrada en él.  De esta forma el usuario puede acceder a los datos de la cuenta y transmitirlos si es necesario.  La llave privada envuelta en esta configuración se cifra con una passphrase para mayor seguridad.  Esto hace que sea necesario introducirla, al menos una vez por sesión, antes de poder realizar satisfactoriamente la autenticación basada en llaves.

Esta situación va en contra de los requerimientos de la automatización ya que sería necesaria la intervención humana para realizar las copias de seguridad, al menos al inicio de esta.  Por suerte es posible eliminar la necesidad de esta passphrase de la llave privada, sin embargo se incurre en un significativo riesgo de seguridad (especialmente en servidores compartidos) ya que quien se apodere de los archivos de la llave, tendrá acceso total a la cuenta del usuario en el servidor remoto.

La solución final a este dilema es la utilización del esquema basado en llaves que he mencionado anteriormente pero utilizando llaves que tengan un fin único y específico, es decir, las llaves no permitirán el acceso total a la cuenta en el servidor sino que permitirán solamente la ejecución de una instrucción específica y previamente determinada, de esta manera no será tan crítica la eliminación de la passphrase.

Crear la llave de propósito único.

Generar la pareja de llaves.

$ ssh-keygen -t dsa -f ~/.ssh/demokey

Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase):      [ENTER]   [1]
Enter same passphrase again:                     [ENTER]
[1]
Your identification has been saved in /home/jimezam/.ssh/demokey.
Your public key has been saved in /home/jimezam/.ssh/demokey.pub.
The key fingerprint is:
77:71:75:7e:d2:7a:f3:af:3f:77:cf:2d:77:6a:79:f3 jimezam@jimezam-ultra
The key’s randomart image is:
+–[ DSA 1024]—-+
|                o|
|               +.|
|            . o +|
|             o o.|
|        S . . …|
|         . .   .o|
|               ..|
|              ++O|
|             .oBE|
+—————–+

Especifique una passphrase vacía cuando se le solicite [1] para evitar que se le solicite nuevamente cada vez que vaya a ser utilizada la llave.  Tenga en cuenta el impacto de seguridad que esto pueda traer a su sistema.

Verifique la existencia de los archivos generados los cuales deberán ser similares a los siguientes.

$ ls -l ~/.ssh/

-rw——- 1 jimezam jimezam  668 2010-09-23 00:56 demokey
-rw-r–r– 1 jimezam jimezam  611 2010-09-23 00:56 demokey.pub

Especificar el propósito único de la llave.

Cree una copia de la llave pública recién generada.

$ cp ~/.ssh/demokey.pub tempkey

Esta tendrá un contenido similar al siguiente.

$ cat tempkey

ssh-dss AAAAB3Nza…(mas caracteres)… jimezam@mi-cliente

Modifíquelo de la siguiente manera.

$ vi tempkey

command=echo I’m `/usr/bin/whoami` on `/bin/hostname`,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3Nza…(mas caracteres)… jimezam@mi-cliente

Transmitir la llave de propósito único al servidor.

$ cat tempkey | ssh jimezam@mi-servidor ‘sh -c “cat – >>~/.ssh/authorized_keys2″‘

Por seguridad remueva la copia de la llave de propósito único después de haberla transmitido al servidor.

$ rm tempkey

Verificar el funcionamiento de la llave de propósito único.

La prueba se realiza intentando acceder al servidor utilizando SSH y la cuenta del usuario que posee la llave de propósito único.

$ ssh jimezam@mi-servidor

I’m jimezam on mi-servidor
Connection to mi-servidor closed.

Modificar el propósito único de la llave.

Siendo la precondición del artículo la necesidad de realizar copias de seguridad del servidor remoto, se va a modificar el propósito de la llave a crear un tar que contenga los archivos importantes y que será posteriormente transmitido al cliente a través de SSH.  La complejidad de este comando depende de los requerimientos que se tengan, sin embargo el ejemplo a continuación servirá como lineamientos básicos para su elaboración.

Como fácilmente se podrá concluír el comando es referenciado por la sección command al comienzo de la línea de la llave de propósito único.  Este comando puede ser especificado desde el cliente en el contenido de la llave si no se ha transmitido aún al servidor o podrá ser manipulado desde el servidor en el archivo ~/.ssh/authorized_keys2.

$ vi ~/.ssh/authorized_keys2

(modificar la llave específica)
from=”*.jorgeivanmeza.com,10.20.*command=”tar zcf – ~/tmp 2> /dev/null“,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3Nza…(mas caracteres)… jimezam@mi-cliente

El modificador from permite limitar desde cuales ubicaciones es posible utilizar la llave privada para acceder a la funcionalidad de las copias de seguridad.  En este caso sólo es posible acceder a través de SSH utilizando esta llave de propósito único desde cualquier equipo del dominio jorgeivanmeza.com o desde cualquier equipo de la subred 10.20.xxx.xxx.

En este caso particular, la llave de propósito único crea un tar de un directorio específico (~/tmp) y envía su flujo de bytes a través de la conexión SSH.

Obtener el archivo de la copia de seguridad.

Del lado del cliente el proceso inverso consiste en abrir una conexión SSH con el servidor utilizando la cuenta a la cual pertenece la llave de propósito único y obtener el archivo enviado a través de un flujo binario.

$ ssh -T -i ~/.ssh/demokey jimezam@mi-servidor | cat > miCopiaDeSeguridad.tgz

El parámetro -i es opcional y permite especificar el archivo con la identidad (llave privada) que se va a utilizar, mientras que el parámetro -T es necesario para transmitir un flujo binario de información.

Finalmente después de la ejecución anterior, en el cliente local se encuentra el archivo miCopiaDeSeguridad.tgz con la copia de seguridad del directorio ~/tmp del servidor.

Agradecimientos.

Gracias a Paul Keck por ayudarme a encontrar la dirección correcta para solucionar el problema del flujo binario de información (-T).

Enlaces.

2 thoughts on “Realizar copias de seguridad remotas con llaves SSH de propósito único”

Leave a Reply

Your email address will not be published. Required fields are marked *