Hoy ampliamos un poco más sobre la serie de la configuración del servidor SSH en GNU/Linux. En la entrega anterior nos quedábamos en la distribución de las claves, y ahora vamos con la creación del canal seguro, el cambio del tamaño de la clave y la creación de las claves para autenticación de usuarios.
Creación del canal seguro
El Handshake son todas las acciones que se realizan entre el cliente y el servidor para verificar que los dos son quien dicen ser y establecer una clave de cifrado simétrica que pueda utilizarse para generar un canal de comunicaciones seguro.
En primer lugar, el cliente manda un mensaje "Hello" al servidor junto con la lista de algoritmos de firma y cifrado que soporta.
El servidor, contestará con el envío de la clave pública de host con su identidad es decir, la Host Key, los algoritmos que van a utilizar en la comunicación, si es que el cliente soporta alguno de los permitidos por el servidor, junto la parte pública de una clave RSA de sesión que se genera cada cierto tiempo.
El cliente verificará la identidad del servidor comprobando la host key recibida con la información almacenada en la carpeta de host conocidos. Una vez verificado generará, basándose en los algoritmos marcados por el servidor, una clave de cifrado simétrico de sesión de 256 bits que enviará al servidor cifrada con la clave pública de sesión recibida.
El servidor, después de este paso, enviará una copia al cliente con todo lo acordado ya cifrado simétricamente. Una vez el canal esta creado, ya pueden intercambiar datos de forma segura. OpenSSH utiliza Diffie Hellman efímero que es uno de los métodos más seguros.
Cambio del tamaño de la clave de sesión
Otra de las recomendaciones para fortificar la comunicación es cambiar el tamaño de la clave de sesión para que sea de 1024 bits y no de 768 bits como se configura por defecto. Esta recomendación es debido a que durante este año se han realizado pruebas de concepto en las que se han roto las claves 768 bits.
Creando el par de claves en el cliente para autenticarse
Lo primero que se va a intercambiar tras el establecimiento del canal seguro es la petición de login por parte del servidor y en este caso se va a configurar una autenticación basada en certificados de usuario. Para ello se utiliza el esquema de clave pública y privada. Con esta técnica se pretende que el usuario no envíe una contraseña cada vez que intente entrar al sistema remoto sino que se utilicen claves RSA.
ssh-keygen –q –f ~/.ssh/id_rsa –t rsa o ssh-keygen (a secas).
Para el passphrase se recomienda no utilizar la contraseña de usuario que tiene en el sistema, ni dejarla en blanco. Se recomienda que al menos tenga 16 caracteres de longitud, y que se mezclen caracteres alfanuméricos, no solamente letras.La clave privada y pública del usuario deben estar en el cliente, almacenadas en la ruta configurada para ello en el cliente SSH.
Es por ello que el Path dónde se encuentre el par de claves, que en los sistemas Linux es ~/.ssh debe tener seguridad respecto a otros usuarios del sistema. Por lo que sería buena idea dotar de permisos 700 al directorio .ssh.
Con este artículo ponemos fin a la serie sobre la configuración de un servidor SSH en GNU/Linux, aunque este tipo de configuración puede ser exportada fácilmente a sistemas operativos como Android, iOS o el propio Mac OS X. Gracias a todos los fieles de la serie, el límite es tu imaginación.
Parte de este artículo fue escrito por mi y Chema en Seguridad Apple.=================================================- Configuración Servidor SSH en GNU/Linux (Parte I)- Configuración Servidor SSH en GNU/Linux (Parte II)- Configuración Servidor SSH en GNU/Linux (Parte III)- Configuración Servidor SSH en GNU/Linux (Parte IV)- Configuración Servidor SSH en GNU/Linux (Parte V)- Configuración Servidor SSH en GNU/Linux (Parte VI)=================================================
[...] Configuración Servidor SSH en GNU/Linux (VI) [...]
ResponderEliminarUn articulo fantastico y de mucha ayuda, por el auth.log estamos viendo muchos intentos de conexion al servidor y ahora ya reforzaremos la seguridad.
ResponderEliminar