Escrito 410
Relaciones de confianza entre dos Linux
- Dejar comentario ↓
- 21.01.07 / 23:45
- 2136 veces visto.
- Tags: confianza, linux, relacion, ssh
Me voy a apuntar esto porque he estado una semana intentándolo y no lo conseguí.
Ahora mismo tengo por un lado el VPS (con Gentoo y en USA) y por otro lado la torre (con Ubuntu y en casa), la que hace meses hacía de servidor en mi casa de León con el ADSL. Lo que ahora quiero es que la torre haga de servidor de backups del VPS por si alguna vez pasa algo o simplemente quiero cambiar de VPS.
Mi idea es que la torre cada día vaya al VPS (por SSH) y se pille lo que yo le diga. Todo de forma automática, sin tener que lanzar el proceso yo cada día. El VPS no tiene porqué saber nada, no va a hacer nada, será la torre la que se preocupe de ese proceso.
Para ello necesito hacer login desde la torre en el VPS, pero sin que me pida contraseña cada vez. Esto se consigue con las relaciones de confianza. La cosa funciona más o menos así: desde el cliente (en este caso la torre) se genera una clave pública y privada (el formato, protocolo y demás es lo de menos). La clave pública se manda al servidor (en este caso el VPS), y con eso ya cada vez que se intente hacer login por SSH desde el cliente al servidor se contrastarán las claves y si son válidas le dejará pasar sin pedirle contraseña ni nada.
Esto es como si un amigo nos dice que quiere venir a nuestra casa y nos enseña las llaves que tiene... y nosotros ponemos a nuestras puertas unas cerraduras a medida para esas llaves. Suena raro, pero es así :P
Vista la explicación para que nunca más se me olvida, voy con los 4 comandos que se necesitan.
Primero genero la clave pública y privada en el cliente con
ssh-keygen -t dsa. Pedirá dónde lo queremos guardar y un passphrase, el cual dejaremos en blanco. por defecto nos guardará los dos archivos en ~/.ssh/id_dsa*.
Luego tengo que mandar la clave pública al servidor para que reconozca al cliente. En el cliente haremos un cd ~/.ssh/ y mandamos la clave pública al servidor con scp id_dsa.pub usuario@host.de.servidor.com:. El usuario es un usuario válido del servidor, yo usé root...
Bien, ya tenemos la clave pública en el servidor, ahora la añadimos a la lista de claves autorizadas. Desde el cliente mismamente entramos al servidor con ssh -l usuario host.de.servidor.com y hacemos un cat id_dsa.pub >> ~/.ssh/authorized_keys. Borramos el archivo id_dsa.pub del servidor y salimos.
Por ahí he visto que la gente da permisos 700 a ~/.ssh/ y 600 al ~/.ssh/authorized_keys, pero yo creo que no lo necesité.
OK, pues ya se puede probar a ver si va bien... desde el cliente volvemos a intentar hacer login en el servidor con ssh -l usuario host.de.servidor.com y si no nos pide contraseña... YA ESTA! :D
Bueno, hay más información en Gentoo-wiki, SECURITY SSH without a password. Ahora ya solo me queda montar el script que haga los backups. Posiblemente use rdiff-backup, que me suena mucho de haberlo visto por los foros de Gentoo. Ya contaré. 9 comentarios
Hermann comentó:
- #1
- 22-1/11:39
Yo hice algo similar para los backups de los servidores donde trabajo y use rsync, escribi un tutorial que puede que te sirva.
@ndreX! comentó:
- #2
- 23-1/00:56
Mmm... para qué liarse tanto?... existen comandos muy lindos como el scp, es como un cp, pero segura, lo pones al contrab y listo!!!.
El comando es mas o menos asi:
scp -r user@192.168.0.1:/home user@192.168.0.2:/backup
y listo.
xergio comentó:
- #3
- 23-1/07:14
Claro, pero el scp también pide contraseña :P
Si lo dices por usar scp en vez de rsync, la cosa es usar el menor ancho de banda posible, con rsync solo se copiarán los archivos que hayan cambiado, los demás no los copiará porque ya tendré uno igual en la torre.
@ndreX! comentó:
- #4
- 23-1/16:19
Pero al scp puedes predefinirle la password... :).
O lo que tu quieres es copiar sin que te pídan ningún password...?
xergio comentó:
- #5
- 23-1/16:39
Claro, no quiero dejar contraseñas por ahí ni mandarlas en el comando. Además quiero que sea para todos los comandos, no solo para scp.
Y la principal razón de usar rsync es la de no tener qeu hacer una copia completa cada día como pasaría con scp, copiaré solo los archivos que han cambiado en el servidor respecto a la copia de casa.
Juan comentó:
- #6
- 23-1/23:50
rsync está muy bien, el consumo de ancho de banda para copias remotas es muy poco y la sincronización es relativamente rápida. El inconveniente es que en el lugar de almacenamiento de backups los datos te ocupan exáctamente lo mismo que en el origen, no hay compresión de los datos almacenados.
Llevo un tiempo usando rsync pero ahora he migrado a otro sistema, te cuento:
Un día a la semana hago un backup total comprimiendo con tar y bzip2 y cifrando los datos con gnupg. El archivo resultante lo copio al destino. (a tí te vale con scp o sshfs, por ejemplo)
El resto de días de la semana mediante el mismo sistema hago backup sólo de los archivos que han cambiado desde el último backup(para esto el tar tiene el parámetro -N).
Con esto consigo backups muy comprimidos y cifrados, y combino los backups totales e incrementales para no tener que copiar todo cada día.
Los archivos antiguos de backups se van purgando, borrándose todos los anteriores a n días(definidos en el script) y al acabar el backup el script me manda un mail con hora de inicio, hora de fin, estado de los filesystems(df -h) y tamaño del archivo de backup.
Quizá te aporte alguna idea. El tema del cifrado es muy importante si el destino del backup no es 100% confiable (¿y que lo es a día de hoy?)
Juanlu comentó:
- #7
- 29-1/18:22
El uso de relaciones de confianza es muy cómodo, yo me beneficio de su uso a diario, no tengo que preocuparme de introducir una y otra vez las claves. Lo uso tanto en casa como en el trabajo.
danne comentó:
- #9
- 19-6/19:35
excelente artículo!
en cuanto al scp .. si ya han establecido una relación de confianza, cualquier comando del tipo "secure" nunca pedirá contraseña ya que hay confianza entre los dos equipos.
Deja un comentario
Pulsa en los títulos para ver información sobre cómo comentar.
Autocompletado de nicks
Todos los campos del formulario son opcionales menos el del PIN.
Usa el tabulador para autocompletar los nicks de otros comentaristas.
Si escribes @ y pulsas la tecla tabulador varias veces podrás recorrer la lista de nicks usados
Y si escribes # (almoadilla) y número (Ej.: #5) se substituirá directamente el nick del comentario correspondienmte al pulsar el tabulador.
Tags HTML permitidos
Tags: a, strong, b, em, u, code, cite.
El tag a admite la propiedad href="..." para indicar la dirección.
Los tags también tienen autocompletado (al igual que los nicks). Para usarlos se pone por ejemplo strong + TABULADOR.
Formulario para comentar
Todo el contenido bajo el dominio XERGIO.NET está sujeto a la licencia Creative Commons con las condiciones BY-SA. Web estandarizada en XHTML 1.0, CSS 2, RSS 2 y Atom 1.0.