rsync con certificado

Seguramente la herramienta más utilizada que hay hoy en día para hacer copias de seguridad sea «rsync«, si resulta que las copias son entre servidores remotos, pues su compeñero ideal será «ssh«.

Las opciones de «rsync» que necesitaría si quiero que se copien todos los archivos y una vez copiados se vaya actualizando con los nuevos archivos o los modificados:

  • -r: Aplica recursividad al origen de la copia. Se lleva los archivos y directorios que están dentro de la ruta que marquemos como origen.
  • -u: Modo de actualización, tan sólo se lleva los archivos que sean más nuevos en el origen que en el destino.
  • -o -g: Transfiere la propiedad de usuario (-o) y grupo (-g). Esto se aplica a los números de UID, no al nombre de usuario concreto. Si en nuestro origen el usuario con UID 3333 es usuario1 y en el destino el UID 3333 corresponde a usuario 2, habrá un problema de permisos ya que usuario 2 de repente pasará a tener control sobre esos datos.
  • -X: Transferir atributos extendidos que tengan aplicados los archivos
  • -p: Transfiere los permisos del archivo (diferente a la propiedad del mismo)
  • -t:Conserva las fechas de modificación, haciendo que rsync marque en el destino la misma fecha de modificación que tenía el archivo en origen.
  • -l: Conserva los enlaces simbólicos copiándolos como tales y apuntando al mismo destino, exista o no.
  • -D: Copia dispositivos especiales
  • -S: Manejar archivos dispersos de forma eficiente, de tal manera que si tenemos un archivo que tiene marcados 4GB como tamaño pero solo usa 100MB, lo transfiera con mayor efectividad.
  • -x: No cruzar filesystems. Es útil cuando tenemos un punto de montaje dentro de nuestro origen y no queremos llevarnos su contenido.
  • –remove-source-files: Elimina los archivos del ORIGEN una vez copiados. Interesante a la hora de archivados.
  • –delete: Borrará los archivos que haya en DESTINO y que no estén en origen. Útil para mantener una copia exacta 1:1 del origen
  • -z: Aplica compresión a los datos durante la transferencia. Muy útil si se transfieren logs.
  • –progress: Mostrará información del archivo que se está transfiriendo, así como del tiempo que se espera que tardará la transferencia en terminar. Si no hay cambios en los archivos, –progress no mostrará nada.
  • -e: Permite especificar opciones al comando que usaremos de shell remota. Por ejemplo, si tenemos el servidor ssh remoto en el puerto 1234, ejecutaremos: rsync -e «ssh -p 1234» -otrasopciones origen destino
  • -a: Esta es una metaopción, que activa de golpe las opciones -rlptgoD.
  • -W: Esta opción activa la copia completa de los archivos, para que no haya que dedicar tiempo a calcular los diferenciales.
  • -c: Esta opción desactiva la comprobación de checksum de datos, es decir, solo utiliza fecha de modificación y tamaño para determinar si un archivo se transfiere o no.
  • -avz

luego si queremos usar «ssh» lo haremos con la opción:

  • e: «-e ssh«

si lo que queremos es una copia exacta usaremos:

  • –delete-after: que eliminaría en e lservidor 2, los archivos eliminados antes de hacer la copia del servidor 1.

La idea ahora sería poner en el servidor 2 un cron que copie los archivos del servidor 1.

$ rsync -e shh -avz usuario1@ip-servidor1:/directorio/servidor1 /directorio/servidor2

Este comando evidentemente nos pedirá la contraseña por lo que para poner en un cron, no nos sirve, para solucionar esto tenemos dos posibilidades:

  • utilizar la aplicación sshpass dentro de rsync.
    • sshpass -p 'elpassword' rsync --progress -avz -e ssh usuario1@ipservidor1:/servidor1/directorio/* /servidor2/directorio
  • o utilizar llaves públicas y llaves privadas.

En el servidor 2 vamos a crear las claves:

$ ssh-keygen -tdsa

A todas las preguntas las dejamos en blanco, esto genera id_dsa.pub en el directorio oculto /home/admin/.ssh/ la clave pública que copiaremos en el servidor1

Para ello simplemente:

 ssh-copy-id root@<ip-del-que-se-quiere-conectar>

 


Comentarios 0

ssh-keygen

Como crear los “keys” para “ssh login” automático

Para los que bregamos con paginas web y desarrollo de aplicaciones basadas en tecnología web, el hacer ssh (remote login) a un servidor en el web es cosa de todos los dias.Vía ssh tenemos control absoluto de esos servidores remotos y nos permite usar herramientas como SVN o Git para desplegar (deploy) nuestras aplicaciones o web sites.

El problema es que si uno esta conectandose a varios servidores muchas veces al día y cada uno de estos tiene un password diferente, la cosa se vuelve complicada. Tengo una aplicación que me ayuda a recordar los passwords pero estoy cansado de copiar y pegar el mismo password 10 veces al día.

La solución a este problema es usar un ssh key. Cuando tienes un ssh key configurado no tienes que entrar el password cada vez que te conectas a un servidor que tiene tu “public key”. Para entender mejor un public key es como una cerradura en una puerta y el private key es la llave que lo abre. Puedes poner la misma cerradura a muchas puertas (servidores) y usar la misma llave para entrar a todas.

Para entender más facilmente (suponiendo que sabes trabajar con ssh):

  1. Tienes que crear un Public y un Private key
  2. Debes guardar el private key como si tu vida dependiera de ello
  3. Debes enviar el public key a todos los servidores o computadoras que te quires conectar

1. En tu computadora personal (Mac OS X / Linux) debes crear el Private y Public key. Esto es muy fácil, simplemente abre el terminal y entra:

ssh-keygen

Luego de entrado este comando te preguntará por un nombre para la pareja de “keys”. En este caso para dejar el nombre que pone por defecto, presionando enter en el teclado. Esto produce tanto el Public (id_rsa) como el Private key (id_rsa.pub). Luego te preguntará por un “passphrase” para el que puedes poner lo que quieras, pero debes recordarlo. Los dos files (id_rsa y id_rsa.pub) se crearán en el directorio .ssh dentro del home folder. Es importante el nombre de estos ficheros, a que renombrándolos no me ha funcionado.

2. Haz un backup de estos dos files. Son muy importantes y si alguien tiene acceso a ellos tambien tendrá acceso a todos los servidores o computadoras que usen esa pareja de llaves.

3. Ahora vamos a colocar el public key (id_rsa.pub) o la cerradura de la puerta al servidor donde queremos conectarnos. Para esto es necesario hacer login al servidor remoto via ssh para decirle que use este file cuando se este tratando de hacer un login desde nuestra computadora personal.

ssh [email protected]

Verifica que el directorio .ssh tiene permisos 700. Si no haces:

chmod 700 .ssh/

cd ~/.ssh

Ahora hay que crear un file para guardar los keys que este servidor acepta.

touch authorized_keys

chmod 600 authorized_keys

Ahora hay que poner nuestro Public key en este file.

Copiamos el contenido de id_rsa.pub con :

cat id_rsa.pub

Editamos el fichero donde almacenaremos esta clave:

joe /root/.ssh/authorized_keys

y pegaremos el contenido del id_rsa.pub que generamos en el servidor o equipo desde el que queremos acceder.

Listo ahora debemos volver a nuestra computadora personal. Si todo salió bien el servidor deberia permitirte conectarte sin perdir ningun password mas allá del passphrase que usaste al principio para genera los keys. De este momento en adelante podrás conectarte al servidor remoto usando solamente:

ssh [email protected]

En caso de tener algún problema al conectarnos por ssh del tipo:

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

debemos editar el fichero “known_hosts” para eliminar la línea que ha almacenado  cuando nos hemos conectado anteriormente desde la misma IP, para ello ejecutamos:

#ssh-keygen -f "/root/.ssh/known_hosts" -R [IP]:PUERTO_SSH

ejemplo:

#ssh-keygen -f "/root/.ssh/known_hosts" -R [192.168.0.1]:22

Aquí les dejo el enlace al mejor articulo que encontré sobre el tema.

Crear un servidor https en IIS

Crear un servidor https en IIS

Las firmas digitales sirven para encriptar información, por un lado tenemos la firma pública que junto con una clave privada nos permite firmar digitalmente un documento. Ese documento o información viajará por la red de forma encriptada y únicamente el receptor a partir de su clave privada podrá descifrar el mensaje.

Cuando montamos un servidor https, estamos intentando hacer algo parecido queremos que nuestros datos (dni, tarjetas, claves, etc.) viajen por la red cifrados, es decir entre la capa TCP y la HTTP vamos a insertar la capa SSL.

Un CSR  (Certificate Signing Request) es un bloque de texto cifrado que se puede generar en el servidor donde el certificado SSL será utilizado, aunque también existe la posibilidad de generarlo online o a través de aplicaciones.

El CSR incluirá entre otras cosas:

  1. Datos de la empresa de la empresa (organization)
  2. Dominios para los que han sido generados (common name)
  3. La clave pública (que será generada automáticamente)

Luego por otro lado necesitas CA (Certificate Authority) o Autoridad Certificadora que es la empresa que debe generar tu SSL a partir del CSR. Hay varias empresas empresas que hacen esta labor, pero casi todas son de pago excepto algunas gratuitas que te proporcionan un certificado con una caducidad rápida de 30 a 90 días.

  1. Certbot, es una empresa que nos proporciona certificados de forma gratuita para sistemas linux.
  2. Sino queremos liarnos mucho Certify the Web, nos proporciona una herramienta de pago para la gestión de nuestros certificados en sistemas windows (la versión gratuita tiene un límite de 5 dominios)

 

 

 

 

 

Instalación de VestaCP sobre Ubuntu

VestaCP Panel de ControlVestaCP es un panel de control para servidores Web.

Página web para generar el comando de instalación: https://vestacp.com/install/

En nuestro caso solicitaremos los siguientes servicios:

  • nginx + apache
  • proftpd
  • iptables + fail2ban
  • BD: MySQL
  • Repositorio remi
  1. # Conectarse a nuestro servidor via SSH ssh [email protected]
  2. # Descargar el script script curl -O http://vestacp.com/pub/vst-install.sh
  3. # Ejecutar  sudo bash vst-install.sh –nginx yes –apache yes –phpfpm no –named no –remi yes –vsftpd no –proftpd yes –iptables yes –fail2ban yes –quota no –exim no –dovecot no –spamassassin no –clamav no –mysql yes –postgresql no –hostname ri-gata.lared.com.es –email [email protected] –password LaClaveQueSea

Pantalla Instalación VestaCP

 

Luego de la instalación porbaríamos a entrar al panel de control:

https://200.200.200.32:8083/login/

VestaCP

La versión de PHP instalada es la 7

juanjo@ri-gata:~$ php -v
PHP 7.0.18-0ubuntu0.16.04.1 (cli) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
 with Zend OPcache v7.0.18-0ubuntu0.16.04.1, Copyright (c) 1999-2017, by Zend Technologies
juanjo@ri-gata:~$

Para añadir ciertos módulos del PHP como son php-zip

sudo apt-get install php-zip

vjh

Instalación de un Servidor Ubuntu

En este ejemplo vamos a instalar un Ubuntu Server 16.

Previamente hemos descargado la ISO básica que vienen a ser unos 800 Mb.

1.- Instalación Ubuntu

Arrancamos la máquina con la ISO y después de pedirnos que seleccionemos el idioma tenemos nuestra primera parada en la configuración de red, sin decirnos nada el intenta encontrar un DHCP y si lo encuentra pues no da la opción de continuar con la configuración automática, no obstante en nuestro caso ya que se trata de un servidor vamos a obligarle a tener una IP fija de nuestra red por lo que le diremos «NO» nos vale esa configuración automática y pasaremos a una manual:

Configura tarjeta red linux ubuntu

Configura red manualmente

En nuestro caso utilizando la notación CIDR será la 200.200.200.32/26 (que se corresponde con la máscara 255.255.255.192) el Gateway y servidor DNS será el propio router: 200.200.200.1

Poniendo la IP en Ubuntu

Hay que indcar también un nombre de máquina: loquesea.com por ejemplo.

Luego nos pide un usuario, a diferencia de otros sistemas como  CentoOS que nos permite trabajar sólo como root, Ubuntu nos obliga a crear un usuario:

usuario en ubuntu

Luego nos pedirá dos veces el password.

Poniendo el password

Luego le decimos que no queremos cifrar nuestra carpeta personal, que la zona horaria es la Península, y que queremos utilizar el disco completo:

Particionado de disco

Escribir cambios en discoConfoirmación particionado disco

Empieza la instalación básica del sistema Ubuntu:

Instalando Sistema Linux Ubuntu

A mitad instalación … nos pregunta si estamos trabajando con algún proxy, en nuestro caso lo dejamos en blanco porque trabajamos directamente con el Router:

proxy

Casi finalizando nos pregunta si queremos que se instalen actualizaciones automáticas, a lo cual diremos que sí.

Actualizaciones automáticas

Casi último le indicamos que paquetes queremos instalar, en nuestro caso son las utilidades standard y el openSSH Server para conectarnos en remoto:

Paquetes de instalación

Se terminan de instalar los programas:

INstalación de programas

Para finalizar le indicamos si tiene que instalar el GRUB, en nuestro caso como se trata de un servidor con un único sistema podemos insertarlo sin miedo, si la máquina tuviera distintos sistemas instalados hay que tener cuidado al instalar el GRUB porque puede que luego no sea accesible alguno de los sistemas:

Instalación GRUB

Antes de reiniciar el equipo hay que asegurarse que no se encuentre la ISO montada o el CD de instalción para que no vuelva a intentar instalarse.

Fin de la Instalación

2.- Comprobación del correcto funcionamiento del sistema

Normalmente la tarjeta de red no suele estar activa al arrancar o bien se puede quedar mal configurada, vemos como debería activarse manualmente y/o configurarla manualmente:

Editamos el archivo interfaces:

sudo nano /etc/network/interfaces

interfaces

Luego para reiniciar la tarjeta:

sudo /etc/init.d/networking restart

Ahora podemos arrancar en remoto con un ssh como bitvise:

bitvise

ssh - bitvise

Para comprobar si tenemos bien configurada la tarjeta de red y la salida a internet instalamos un pequeño paquete como es el nmap que nos servirá para ver que puertos tiene abiertos nuestro servidor.

sudo apt-get install nmap

Si ejecutamos la la instruccion sudo nmap 127.0.0.1:

juanjo@ri-gata:~$ sudo nmap 127.0.0.1

Starting Nmap 7.01 ( https://nmap.org ) at 2017-05-27 20:23 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000018s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh

Nmap done: 1 IP address (1 host up) scanned in 1.64 seconds

Vemos que sólo está abierto el puerto del SSH

3.- Actualización del sistema.

Al arrancar el sistema por primera vez ya nos avisa de que hay paquetes por actualizar y actualizaciones de seguridad:

terminal ubuntu

una actualización del mismo:

sudo apt-get update
sudo apt-get upgrade

En nuestro caso se descargará unos 70 Mb de actualizaciones.

upgrade ubuntu