Una manera cómoda de resolver accesos remotos a servidores puede ser autenticarse mediante llaves criptográficas. Esta opción es cómoda, pero quizás no es recomendable para gestionar accesos remotos por SSH a servidores expuestos a tráfico. La autenticación automática es preferible hacerla en entornos controlados, entornos de pruebas sin datos sensibles o simplemente, entornos sin potenciales atacantes cercanos :)
En un entorno de pruebas, tener que introducir constantemente usuario y clave puede llegar a ser cansino. Lo más cómodo es emplear criptografía de llave pública para automatizar la autenticación. Respecto a clientes, ejemplificaremos para PuTTY, ya que probablemente es el cliente Windows para SSH más extendido. Los pasos a seguir son los siguientes:
Paso 1
Mediante el generador de llaves de PuTTY, que se llama PuTTY Key Generator (PuTTYgen), creamos un par de llaves empleando, por ejemplo SSH-2 RSA-2048. Es importante no utilizar llaves SSH-1, ya que son explotables. 1024 es una longitud aceptable en entornos controlados, si bien tampoco cuesta nada generar llaves de 2048 bits de longitud.
IMPORTANTE: El formato de llaves de PuTTY no es el formato de llaves nativo OpenSSH, así que la clave que nos interesa es la convertida, que aparece en el recuadro "Public key for pasting into OpenSSH authorized_keys file". Si empleamos la llave pública no convertida en el servidor SSH, la autenticación no funcionará. En el 99,9% de los casos, un mensaje "Server refused our key" al iniciar sesión se debe a que hemos empleado en authorized_keys la clave nativa de PuTTY y no la llave convertida, que recordemos, aparece en el recuadro "Public key for pasting into OpenSSH authorized_keys file".
NO MENOS IMPORTANTE: Para poder reutilizar las claves, hay que salvarlas. Además, como veremos en el paso siguiente, PuTTY necesita tener acceso a la llave privada generada, con lo que es imperativo salvarla. Podemos prescindir de passphrase para la llave privada, así el proceso de autenticación será transparente y no se nos preguntará por el passphrase de protección. En un entorno real, hay que proteger la llave privada siempre. Huelga decir que de la adeucada conservación de las llaves (especialmente la privada, la pública se puede distribuír) dependerá la seguridad final de nuestra plataforma.
Paso 2
Lo siguiente es incorporar las llaves públicas de los usuarios a los que queremos dotar de autologin en el fichero de llaves autorizadas de nuestro servidor SSH. Este fichero donde se encuentran las llaves autorizadas se llama habitualmente authorized_keys, y es normal encontrar estos ficheros en los directorios .ssh de los distintos home de los usuarios.
Pegamos allí nuestra llave pública (en formato nativo OpenSSH, no me cansaré de decirlo) creada con PuTTYgen.
Paso 3
En el cliente PuTTY, nos vamos a "Connection --> data", y escribimos el usuario con el que queremos hacer autologin. En "connection --> SSH --> Key", especificamos la llave privada que hemos generado con PuTTYgen. Volvemos a la pantalla principal, "Session" y salvamos esa configuración.
Paso 4
Reiniciamos el demonio SSH (FreeBSD /etc/rc.d/sshd restart, consultar Google para otros sistemas). A partir de ahora, nos autenticaremos automáticamente contra SSH, sin tener que emplear clave y contraseña.
Using username "root".
Authenticating with public key "usuario-root"
Last login: Sat Oct 6 15:09:05 2007 from 192.168.1.3
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 6.2-RELEASE-p4 (SMP) #0: Thu Apr 26 17:55:55 UTC 2007
Welcome to FreeBSD!
$
NOTAS
NOTA: Para usuarios regulares, que no son el root, crearemos, logueados como ese usuario, la carpeta .ssh y la dotaremos de permisos de lectura para sólo ese usuario:
$ mkdir /home/shernando/.ssh
$ chmod -R og= /home/shernando/.ssh
Dentro de esa carpeta colocaremos el fichero authorized_keys con la llave pública del usuario.
NOTA 2: Es importante que el demonio SSH admita autenticación basada en llave pública, con lo que en el fichero de configuración (/etc/ssh/sshd_config en FreeBSD, consulta Google para otras plataformas) tiene que tener los siguientes campos en "yes":
RSAAuthentication yes
PubkeyAuthentication yes
Fuente: SergioHernando
