Para ejecutar comandos dentro de una conexión segura entre servidores, se necesita instalar el SSL y secure shell (ssh) primero, configurarlo y probarlo. Para los efectos de este ejemplo, el usuario ysanson del servidor alpha ejecutará comandos y copiará archivos en el servidor epsilon con el permiso del usuario apptest.1. Generar las llaves de identificación. En este caso utilizaremos la encriptación rsa:
ysanson@alpha:/home/ysanson $ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ysanson/.ssh/id_rsa):
Created directory '/home/ysanson/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ysanson/.ssh/id_rsa.
Your public key has been saved in /home/ysanson/.ssh/id_rsa.pub.
The key fingerprint is:pp:41:yy:84:4c:ta:c8:b4:90:e4:82:j9:5b:pp:fe:a9 ysanson@alpha
Solo necesitamos la llave pública (id_rsa.pub), no introducimos clave (porque añadiría un paso interactivo) y esta queda guardada en el directorio .ssh bajo el HOME del usuario.
2. Copiar el archivo público al servidor destino por de forma segura (scp), utilizando el usuario que nos permitirá la ejecución y copia remota, en este caso apptest.
ysanson@alpha:/home/ysanson/.ssh $scp id_rsa.pub apptest@epsilon:
The authenticity of host 'epsilon (1.70.1.210)' can't be established.
RSA key fingerprint is uu:ce:0a:xx:2b:83:a4:ii:a7:66:86:ed:ee:46:01:80.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'epsilon,1.70.1.210' (RSA) to the list of known hosts.
mailto:apptest@epsilon password:id_rsa.pub 100% 224 0.2KB/s 00:00
El archivo es copiado al HOME del usuario apptest en epsilon porque al final del hostname destino hay dos puntos.
3. Crear el directorio .ssh en el servidor epsilon bajo el HOME de apptest y anexamos el contenido que archivo id_rsa.pub dentro del otro denominado authorized_keys.
$ mkdir .ssh
$ chmod 755 .ssh
$ cd .ssh$ cat ../id_rsa.pub >> authorized_keys
Los permisos son necesarios para garantizar que la llave pueda ser leída. La anexión (>>) se debe a que el mismo archivo puede contener las llaves públicas de otros usuario y servidores.
4. Ejecutamos un comando remotamente utilizando el comando ssh:
April 2008
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30
o copiamos un archivo:
o copiamos un archivo:
ysanson@alpha:/home/ysanson/.ssh $scp prueba apptest@epsilon:
Nuevamente es importante los dos puntos al final sino el archivo prueba es copiado al mismo servidor bajo el nombre apptest@epsilon .
Este aparentemente sencillo proceso requiere de mucho cuidado ya que la colocación de los archivos y sus permisos es crítico para su funcionamiento. Un problema que he observado es que durante el proceso de generación de la llave, el ssh-keygen pregunta dónde queremos almacenar los id_rsa*, sin embargo cuando hacemos la copia remota (scp), el archivo known_hosts generado se crea bajo el $HOME del usuario. Esto no tiene mayor consecuencia si el usuario que ejecuta el proceso es único, pero cuando se realiza por medio de un usuario que tiene el mismo UID que otro -como ocurre con aquellos que reemplazan a root-, entonces los id_rsa* deben copiarse al directorio .ssh donde exista el archivo known_hosts.
Entradas
