Claves Pública y Privada: Estableciendo Autentificación No Interactiva

ssh-keygen

Recordemos como se establece una autentificación por clave pública-privada. La generación de una pareja de claves pública-privada se realiza ejecutando en el cliente ssh-keygen:

$ ssh-keygen  -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx user@machine

En esta ocasión no indicamos passphrase.

Las claves generadas por ssh-keygen se almacenan por defecto en ~/.ssh/, quedando el directorio así:

$ ls -l
total 12
-rw-------  1 user user  883 2005-08-13 14:16 id_rsa
-rw-r--r--  1 user user  223 2005-08-13 14:16 id_rsa.pub
-rw-r--r--  1 user user 1344 2005-08-04 02:14 known_hosts

Los ficheros id_rsa e id_rsa.pub contienen respectivamente las claves privada y pública. El fichero known_hosts contiene la lista de las claves públicas de las máquinas reconocidas.

Estas son alguas de las opciones que admite ssh-keygen:

Computando la Huella de una Máquina

Es posible generar el fingerprint de una clave pública usando la opción -l:

$ ssh-keygen -l -f mykeyfile.pub

Ya vimos que cuando nos conectabamos a un host por primera vez via ssh obteníamos un mensaje como:

teide:~$ ssh teide
The authenticity of host 'teide (134.2.14.48)' can't be established.
RSA key fingerprint is 9e:1a:5e:27:16:4d:2a:13:90:2c:64:41:bd:25:fd:35.
Are you sure you want to continue connecting (yes/no)?

Normalmente respondemos yes y entramos nuestra clave. ¿Cómo podemos comprobar que el fingerprint es auténtico?

¿Donde están los ficheros de claves del servidor? Normalmente en el directorio /etc/ssh/.

teide:~$ ls /etc/ssh/*key*
/etc/ssh/ssh_host_dsa_key      /etc/ssh/ssh_host_key.pub
/etc/ssh/ssh_host_dsa_key.pub  /etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_key          /etc/ssh/ssh_host_rsa_key.pub

Este servidor tiene tres claves. Sólo el root puede leer las privadas, pero las públicas tienen permisos de lectura. En el mensaje anterior, el cliente ssh muestra el fingerprint esperado. Podemos obtenerlo con:

teide:~$ ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub 
2048 9e:1a:5e:27:16:4d:2a:13:90:2c:64:41:bd:25:fd:35 /etc/ssh/ssh_host_rsa_key.pub

El primer número (2048) es la longitud en bits de la clave. El segundo 9e:1a:...:fd:35 es la huella, el último /etc/ssh/ssh_host_rsa_key.pub es el nombre del fichero con la clave pública.

Ejercicio 84.3.1   Este método es inseguro. ¿Por qué?

El método seguro es contactar al administrador para obtener la huella (se supone que el administrador la guardó en lugar seguro) en vez de utilizar un canal que pueda estar comprometido.

ssh-copy-id

Ahora se debe copiar la clave pública al servidor, al fichero ~/.ssh/authorized_keys. El fichero authorized_keys es el fichero que contiene las claves públicas utilizadas durante el proceso de autentificación pública.

Para la copia se utiliza el comando ssh-copy-id:

$ssh-copy-id -i ~/.ssh/id_rsa.pub user@machine1
$ssh-copy-id -i ~/.ssh/id_rsa.pub user@machine2

ssh-copy-id es un script que se conecta a la máquina y copia el archivo (indicado por la opción -i) en ~/.ssh/authorized_keys, y ajusta los permisos de forma adecuada:

Una configuración de permisos inadecuada puede prevenir que podamos acceder a la máquina, sobre todo si la configuración del servicio SSH tiene activado StrictModes (que suele ser la opción por defecto):

root@server:/etc/ssh# grep -i strictmode *
sshd_config:StrictModes yes

Si se desea publicar la clave en un cierto número de máquinas que comparten la misma clave es posible (pero no recomendable) hacerlo usando el programa sshpass con un comando como este:

$ for i in host1 host2 ... hostN; do sshpass -pmipassword ssh-copy-id -i .ssh/identity $i; done

Copia Manual

Si no se dispone del programa ssh-copy-id se puede realizar una copia manual a la máquina remota del fichero conteniendo la clave pública (por ejemplo usando scp o sftp) y añadir su contenido al fichero ~/.ssh/authorized_keys.

En la máquina servidor añadimos una línea en el fichero ~/.ssh/authorized_keys que contiene exactamente la única línea que estaba en el fichero en el que se guardó la clave pública (id_rsa.pub o filename.pub o como se llamara). Después de eso el fichero .ssh/authorized_keys tendría una línea parecida a esta:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAybmcqaU/Xos/GhYCzkV+kDsK8+A5OjaK
5WgLMqmu38aPo56Od10RQ3EiB42DjRVY8trXS1NH4jbURQPERr2LHCCYq6tHJYfJNhUX
/COwHs+ozNPE83CYDhK4AhabahnltFE5ZbefwXW4FoKOO+n8AdDfSXOazpPas8jXi5bE
wNf7heZT++a/Qxbu9JHF1huThuDuxOtIWl07G+tKqzggFVknM5CoJCFxaik91lNGgu2O
TKfY94c/ieETOXE5L+fVrbtOh7DTFMjIYAWNxy4tlMR/59UVw5dapAxH9J2lZglkj0w0
LwFI+7hZu9XvNfMKMKg+ERAz9XHYH3608RL1RQ== Este comentario describe la
clave

excepto que he descompuesto la línea en varias líneas para hacerla mas legible.

La forma usual de completar el proceso requeriría de dos autentificaciones: una para la copia con scp y otra para añadir la identidad en el fichero .ssh/authorized_keys y asegurarse de los permisos.

Una forma de realizar el proceso con una sola autentificación es la siguiente:

europa:~/.ssh$ cat prueba.pub | \
  ssh nereida "umask u=rwx,g=,o=; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys"

La máscara por defecto umask u=rwx,g=,o= se ha establecido de manera que los ficheros creados tengan permisos rw------- y los nuevos directorios tengan permisos rwx----- (véase la entrada de umask en la Wikipedia).

Conexión sin Clave

Ahora la conexión debería funcionar sin necesidad de introducir la clave.

   ssh -i ~/.ssh/filename remotehost
o bien:
   slogin -i ~/.ssh/filename remotehost
Una vez que se ha establecido un esquema de autentificación automática es trivial ejecutar un comando en la máquina remota:

pp2@nereida:/tmp$ ssh remotename@machine uname -a
Linux machine 2.6.8-2-686 #1 Tue Aug 16 13:22:48 UTC 2005 i686 GNU/Linux

Permisos en .ssh

Si no funciona es posible que sea un problema de permisos en los ficheros. Los permisos correctos deben ser similares a estos:

    $ chmod go-w $HOME $HOME/.ssh
    $ chmod 600 $HOME/.ssh/authorized_keys

Inténtelo de nuevo usando la opción -v de ssh:

pp2@nereida:/tmp$ ssh -v -v remotename@machine uname -a

Véase también

Ejercicios

Ejercicio 84.3.2   Cree una identidad y transfierala manualmente.

Ejercicio 84.3.3   Cámbiele la passphrase a una identidad

Ejercicio 84.3.4   Cámbiele el comentario a una identidad

Ejercicio 84.3.5   Copie el fichero de clave privada de su cuenta de usuario u1 en m1 a otra cuenta u2 en la máquina m1. Intente ahora conectarse siendo el usuario u2 de m1 a la máquina rm en la que situó la clave pública como usuario ru:

u2@m1:~/$ ssh ru@rm

¿Sigue funcionando la autentificación automática?

Ejercicio 84.3.6   Copie ahora el fichero de clave privada de su cuenta de usuario u1 en m1 a otra cuenta w1 en una máquina distinta mw. Conéctese desde mw a rm en la que situó la clave pública como usuario ru:
mw@w1:~/$ ssh ru@rm
¿Funciona? ¿Como afectan los resultados a su percepción de la seguridad de las comunicaciones con ssh?

Ejercicio 84.3.7   Considere una intranet en la que su HOME de usuario esta en un sistema de archivos compartido. Genere (si no la ha echo ya) su pareja de claves privada y pública. Publique la clave usando $ssh-copy-id o bien - si $ssh-copy-id no está disponible - copiando la clave pública en el fichero authorized_keys. ¿Se obtiene autorización automática entre dos máquinas cualesquiera de la red?



Subsecciones
Casiano Rodriguez León 2015-06-18