Ejercicios Criptografía en SSH Francisco Javier Cervigon Ruckauer

Ejercicios Criptografía en SSH

Ejercicio: Robustecer el servidor SSH

La configuración del servidor SSH se halla en el fichero "/etc/ssh/sshd_config".  El servidor la lee una vez al arrancar y posteriormente cada vez que recibe la señal SIGHUP. Por tanto, cuando se cambia el fichero de configuración es necesario informar al servidor usando la orden "service ssh reload".

Aunque existen múltiples aspectos que considerar, los más relevantes son:

• Restringir el acceso al servidor. Aunque es recomendable usar herramientas complementarias como tcpd y el filtrado de paquetes para limitar el acceso al servidor, se puede limitar las interfaces en que escucha el servidor usando la opción ListenAdress.
• Permitir únicamente la versión 2 del protocolo SSH. La versión 1 es menos segura, y todos los servidores y clientes actuales soportan la versión 2. (Opción Protocol).
• Cambiar el puerto de escucha. Muchos de los intentos de ataque van dirigidos a servidores SSH que escuchan en el puerto 22. Aunque cambiar el puerto de escucha no protege frente a ataques dirigidos, sí evitará muchos intentos. Lo mejor es usar un puerto no privilegiado, como el 50000. (Opción Port).
• Deshabilitar métodos de autenticación inseguros, y todos los que no se vayan a usar. La autenticación basada en nodos es insegura (opciones RhostsRSAAuthentication y HostbasedAuthentication), y también lo es permitir el acceso sin contraseña (opción PermitEmptyPasswords). Si es posible, dejar únicamente la autenticación mediante clave privada (se aborda en el siguiente ejercicio).
• Utilizar preferiblemente autenticación mediante clave privada. (Se aborda en el siguiente ejercicio).
• Restringir los usuarios que pueden acceder mediante SSH. Se puede permitir selectivamente que solamente accedan ciertos usuarios y/o grupos (opciones AllowUsers y AllowGroups). Alternativamente se puede denegar selectivamente el acceso a ciertos usuarios y/o grupos (opciones DenyUsers y DenyGroups). Sin embargo, desde el punto de vista de la seguridad, siempre es preferible denegar por defecto y permitir explícitamente (primera opción).
• Restringir el acceso del administrador. Aunque el acceso por SSH, especialmente si se usa criptografía asimétrica, es seguro, es recomendable impedir el acceso directo del administrador (opción PermitRootLogin) y exigir a los usuarios que usen su o, mejor, sudo, para realizar tareas de administración.

El servidor SSH envía sus mensajes al registro del sistema usando el identificador auth, por lo que en Debian 6 los mensajes van a "/var/log/auth.log". Una forma sencilla de monitorizar este fichero para comprobar el funcionamiento del servicio es mediante la orden "tail -f /var/log/auth.log".

Acciones a realizar:

1. Configurar de forma segura el servidor SSH de dmzc, permitiendo el acceso mediante usuario y contraseña al usuario user1 exclusivamente. (La autenticación por clave privada se abordará en el siguiente ejercicio).
2. Asegurarse de que el servidor carga la la nueva configuración.
3. Comprobar que los cambios son efectivos.

Ejercicio: Autenticación mediante criptografía asimétrica en SSH

Usar criptografía asimétrica aumenta la seguridad (respecto a la contraseña tradicional), pues el usuario necesita tener acceso a la clave privada que, a su vez, está protegida por una contraseña robusta (idealmente una frase de paso).

El primer paso para usar criptografía asimétrica es crear un par de claves en la máquina desde la que se va a iniciar la conexión al servidor SSH. En este caso se usará como máquina de trabajo base.example.net. La orden ssh-keygen crea un par de claves RSA (la pública y la privada). Ambas son almacenadas por defecto en el directorio ".ssh" del directorio inicial del usuario. La clave privada se denomina por defecto "id_rsa" y la pública "id_rsa.pub".

Acciones a realizar:

1. Crear un par de claves RSA en base.example.net como usuario user1. (Es importante usar una frase de paso segura).
2. Localizar el fichero con la clave pública y el fichero con la clave privada.

El segundo paso es depositar una copia de la clave pública en el servidor. La copia (el contenido del fichero con la clave pública) debe ser añadida al fichero ".ssh/authorized_keys" del directorio inicial del usuario correspondiente en el servidor. Por ejemplo, para permitir el acceso como user3, la copia debería ser añadida al fichero "/home/user3/.ssh/authorized_keys". (Si el directorio no existe, debe ser creado con permisos de lectura, escritura y ejecución exclusivamente para el dueño, sin ningún permiso para el resto).

Una vez añadida la copia, si se intenta una conexión SSH, el sistema debe solicitar la frase de paso con la que desbloquear la clave privada. La petición viene del cliente SSH, pues el servidor nunca solicita la clave privada; lo que hace es enviar un reto cifrado con la clave pública del usuario, de forma que sea necesario usar la clave privada para resolverlo.

Acciones a realizar:

1. Si no existe, crear el directorio "/home/user1/.ssh" en dmzc con permisos solamente para el dueño. (Sugerencia: usar "mkdir -m go= /home/user1/.ssh").
2. Depositar la copia de la clave pública en "/home/user1/.ssh/authorized_keys".
3. Probar a conectarse desde base a dmzc  como user1.
4. Comprobar que se solicita la frase de paso de la clave privada y no la contraseña de user1 en dmzc.

Nota

Alternativamente, se puede usar en base, como "user1", la orden "ssh-copy-id -i /home/user1/.ssh/id_rsa.pub dmzc". El programa "ssh-copy-id" se encarga de comprobar que la clave no está registrada en dmzc y, si no lo está, de transferir la copia de la clave pública al sitio adecuado ("/home/user1/.ssh/authorized_keys"), creando la carpeta ".ssh" si es necesario.

Ejercicio: Usar el agente de autenticación de SSH.

Aunque usar la criptografía asimétrica tal y como se ha sugerido en el ejercicio anterior es seguro, tener que introducir la frase de paso de la clave privada cada vez que se desea iniciar una conexión resulta incómodo. Afortunadamente, el agente de autenticación es un proceso que guarda en memoria principal una copia sin cifrar de las claves privadas que se le indiquen.  Cuando se está ejecutando y el cliente de SSH necesita acceder a una clave privada, primero trata de obtenerla del agente y, si tiene éxito, no solicita la frase de paso. Por tanto, solamente habrá que introducir la frase de paso una vez por sesión.

En los entornos gráficos como KDE es habitual que el agente de ejecución se inicie automáticamente al iniciar la sesión gráfica. Si es así, se pueden añadir claves directamente. Éste es el caso de base. Para comprobar que se tiene acceso al agente de autenticación basta con ejecutar la orden "ssh-add -l". La respuesta debe ser similar a ésta:

user1@base:~> ssh-add -l 
The agent has no identities.
user1@base:~>

Si, en cambio, el mensaje es "Could not open a connection to your authentication agent.", entonces es necesario lanzarlo ejecutando la siguiente orden en la terminal de "base" que vayamos a utilizar:

eval $(ssh-agent)

La misma orden ssh-add permite también añadir claves privadas al agente (y eliminarlas). Por ejemplo, para añadir una copia de la clave privada al agente, user1 simplemente tendría que usar la orden "ssh-add /home/user1/.ssh/id_rsa". Lógicamente este proceso requiere introducir la frase de paso.

Si todo va bien, el listado de claves debería incluir un elemento:

user1@base:~> ssh-add -l 
2048 ed:ad:15:59:fc:48:d1:e0:97:42:67:81:b6:aa:71:37 [MD5] /home/user1/.ssh/id_rsa (RSA)
user1@base:~>

A partir de ese momento, el acceso a cualquier servidor en el que esté registrada esta clave, debería realizarse sin necesidad de volver a introducir la frase de paso.

Acciones a realizar:

1. Añadir la clave privada generada en el ejercicio anterior al agente de autenticación en base. (Como user1).
2. Conectarse desde base a dmzc como user1.
3. Comprobar que no es necesario introducir la frase de paso ni la contraseña.

Ejercicio: Usar claves para tareas específicas

Un aspecto muy interesante de la autenticación mediante criptografía asimétrica en SSH es la posibilidad de configurar el servidor para que aplique opciones de configuración específicas en función de la clave que utilice el cliente. Así, por ejemplo, si un usuario tiene un contenido como éste (donde parte de la clave ha sido sustituida por puntos suspensivos por legibilidad) en su fichero ".ssh/authorized_keys":

user1@dmzc:~$ cat /home/user1/.ssh/authorized_keys
ssh-rsa AAAA...nhfzxa9 user1@base
no-X11-forwarding ssh-rsa AAAA...Wtua+7 user1 - clave dos
command="/usr/local/bin/backup-server" ssh-rsa AAAA...gxgeZrn user1 - clave tres
user1@dmzc:~$

Entonces se cumple lo siguiente:

• La primera clave no tiene restricciones.
• Con la segunda no se pueden redirigir las conexiones X.
• Con la tercera, independientemente de la orden que se intente ejecutar, lo que ocurrirá es que se ejecutará el programa "/usr/local/bin/backup-server".

Estos ejemplos están descritos en la página del manual de authorized_keys. Aunque todas son interesantes, la tercera permite delegar tareas que pueden ser iniciadas remotamente de forma automática. Para ello bastaría usar una clave privada sin frase de paso.

Aunque de forma general se recomienda usar frases de paso robustas y usar el agente de autenticación para no tener que teclearlas frecuentemente, en este caso, al estar limitado el efecto que se puede causar, el riesgo es menor. Y, de todas formas, sigue siendo necesario el acceso a la clave privada, que debe estar bien protegida.

Acciones a realizar:

1. Crear un nuevo par de claves fácilmente identificable. (Sugerencias: no poner frase de paso, usar un nombre adecuado para el fichero como "clave_mantenimiento", y un comentario igualmente indicativo como "Clave para mantenimiento").
2. Copiar la clave pública en el "authorized_keys" de user1 en dmzc.
3. Editar el fichero para que con la nueva clave solamente se pueda averiguar quién está conectado y qué está ejecutando (orden "/usr/bin/w").
4. Comprobar que, usando la nueva clave, independientemente de lo que se intente, lo único que se obtiene es el listado esperado. (Sugerencias: asegurarse antes de que el agente de autenticación no tiene identidades cargadas; si las tiene, eliminarlas con "ssh-add -D"; y usar la opción "-i" para indicar qué clave debe usar el programa "ssh").

Francisco Javier Cervigon Ruckauer