Secure Shell Protocol- Es un protocolo utilizado para operar servicios de red de forma segura sobre una red insegura. SSH utiliza una arquitectura cliente servidor, en la cual un cliente SSH se conecta a un servidor SSH; lo cual nos permite realizar una gestión de nuestros servidores de forma remota, brindando más seguridad, dado que toda la comunicación está cifrada. Por lo anterior, SSH es una gran alternativa frente a protocolos como telnet, rlogin, rsh y rexec; los cuales no deberían ser utilizados bajo ninguna circunstancia, debido a que transmiten la información en texto plano. El nivel de cifrado que se utiliza con SSH busca garantizar la confidencialidad y la integridad de la información.

En este caso en particular, utilizaré el  mejor (en mi concepto) servicio ssh, el desarrollado por OpenBSD (https://www.openbsd.org) y conocido como OpenSSH

Principales características de OpenSSH

• Opensource
• Criptografía avanzada
• Reenvío de X11 (servidor gráfico ampliamente utilizado en Linux)
• Reenvío de puertos (port forwarding)
• Soporte para SFTP
• Fuertes mecanismos de autenticación

¿Cuáles son los archivos relacionados?

Ruta/Archivo	Descripción
/etc/ssh	Carpeta donde se alojan los archivos de configuración de ssh
/etc/ssh/sshd_config	Archivo de configuración principal del servidor ssh
C:\Users\usuario\.ssh	Carpeta donde se almacenan algunos archivos relacionados como “known_hosts” en Windows 10
/home/behackerpro/.ssh	Carpeta donde se almacenan algunos archivos relacionados como “known_hosts”, “”authorized_keys” en Linux
/home/behackerpro/.ssh/known_hosts	Este archivo contiene un listado de llaves públicas correspondientes a los host a los cuales se ha conectado el usuario
/home/behackerpro/.ssh/authorized_keys	En este archivo se encuentran las llaves públicas que pueden ser utilizadas para la autenticación de usuarios

¿Qué debo hacer para mejorar la seguridad de mi servidor ssh?

A continuación verá una serie de recomendaciones que le permitirán incrementar la seguridad de su servidor ssh y reducir la superficie de ataque.

Antes de iniciar este procedimiento, asegúrese de tener un acceso alternativo a su servidor ya sea que este se encuentre en físico, virtualizado o en cualquier proveedor de cloud computing, verifique que los cambios realizados no lo dejen sin acceso al mismo.

Verifique la versión de Openssh server que tiene instalada en su servidor:

¿Autenticación basada en contraseñas o en llaves?

En primer lugar, usted debe decidir si va a manejar la autenticación a través de contraseñas o utilizando criptografía de llave pública ¿Cuál de las dos opciones es mejor? Todo depende, ambas opciones tienen virtudes y defectos; si usted piensa que la utilización de criptografía de llave pública es infalible, puede estar equivocado; lo mismo sucede si usted cree que la autenticación a través de contraseñas es completamente confiable, veamos:

• Una contraseña puede ser susceptible a ataques por fuerza bruta, cientos de botnets a las cuales no les da sueño ni hambre, desde múltiples fuentes.

• Una contraseña puede ser tan compleja como difícil de recordar ¿Y si la apunto en un papel? (Re-Mala idea) ¿y si alguien consigue ese papel? ¿Y si se me pierde ese papel?

• Tengo la llave privada salvaguardada en mi laptop ¿Qué tal si me roban la laptop? ¿Qué tal si cualquiera puede acceder a mi laptop y sacar una copia de la llave privada que utilizo para ingresar al super servidor secreto?

• La llave privada la tengo en los dispositivos desde los cuales me conecto (móvil, tablet y laptop) hacia el server ¿Qué sucedería si pierdo esos dispositivos? ¿Será que esos dispositivos están bien protegidos?

Antes de iniciar con las modificaciones pertinentes, asegúrese de realizar una copia del archivo de configuración:

¿Chequear el protocolo utilizado y garantizar que sea Protocol 2?

En los archivos anteriores de /etc/ssh/ssd_config había una opción para configurar y garantizar que el protocolo fuese 1 o 2, esta línea u opción de configuración, ya no se encuentra disponible a partir de la versión OpenSSH 7.6 ver enlace https://www.openssh.com/txt/release-7.6.

Desactivar el acceso como root

Es una buena práctica permitir que solo usuarios regulares puedan iniciar sesión en el servidor ssh y, posteriormente si se requiere la realización de alguna tarea administrativa, este pueda elevar sus privilegios como root; es decir que este usuario pueda hacer uso de sudo (verifíquelo antes de realizar la siguiente configuración)

La línea debe quedar así

Cambiar el puerto por defecto

Cambiar el puerto de su valor por defecto (22)

A un puerto utilizable como el que se ve a continuación

Autenticación basada en llaves

Ubíquese en el host desde el cual quiere acceder hacia el servidor ssh y genera las llaves; en el caso de la imágen, se generó una llave de tipo RSA de 4096 bits 

Nunca olvide que la llave privada debe estar totalmente asegurada y nunca debe ser comprometida; solo usted debe verla, solo usted debe tenerla y solo usted debe controlarla, la llave pública puede ser de libre acceso. ¿Debo configurar un passphrase a la llave? Es recomendable hacerlo, ya que la passphrase cifra la llave privada, haciendo las cosas más difíciles a los malos; sin embargo, la decisión depende de las políticas de seguridad existentes, aunque ¿Por qué no hacerlo política?

En la siguiente imágen puede ver la llave privada denominada “NombreQueQuieraRsa4096” y la llave púlbica denominada “NombreQueQuierasRsa4096.pub”…Reitero ¡ojo con la llave privada, cuidela, en serio!

A continuación, usted debe llevar la llave pública al servidor ssh al cual se desea conectar, en este caso particular, se llevó la llave “NombreQueQuieraRsa4096.pub” al servidor ssh ¿Cómo puedo llevar la llave pública al servidor? Dependiendo del contexto, podría hacerlo a través de una USB (no me suena tanto esta idea, pero es viable), un servicio ftp (ftp es inseguro), un servicio sftp (buena idea, openssh ofrece el servicio), la utilidad scp (buena idea)

Supongamos que queremos ingresar al servidor ssh, con el usuario behackerpro; en ese caso, debemos llevar la llave pública a la ruta “/home/behackerpro/.ssh” en el servidor ssh; para el caso particular se utilizó scp, en el comando se indica que se transfiera el archivo “NombreQueQuieraRsa4096” hacia el servidor 192.168.0.10 con usuario behackerpro y, que se copie en la ruta “/home/behackerpro/.ssh”

A continuación puede ver la ruta en la cual quedó almacenado el archivo correspondiente a la llave pública.

Ahora, debe asegurarse de allegar el contenido de la llave pública hacia el archivo “authorized_keys” ubicado en la ruta “/home/behackerpro/.ssh”, en la imagen posterior, se puede ver como se redirecciona el contenido del archivo ”NombreQueQuierasRsa4096” al archivo “authorized_keys”

verifique que todo esté en orden, e inicie sesión vía ssh desde el host hacia el servidor mediante el comando:

ssh -i “RutaDeLaLLavePrivada” usuarioenelservidor@direcciónIPdelServidor

En la imágen posterior, puede ver cómo se inició sesión con el usuario behackerpro, en el servidor ssh cuya dirección ip se 192.168.0.10 mediante ssh, utilizando la llave privada denominada “NombreQueQuieraRsa4096”

Si ya compró el acceso a través de la llave y, verificó, en caso de necesitarlo, la posibilidad de utilizar “sudo” con el usuario regular, behackerpro; proceda a lo siguiente

Asegurarse de que el valor esté en “yes”

Asegurarse de deshabilitar la autenticación por contraseña

Deshabilitar la autenticación utilizando contraseña

La autenticación mediante el uso de contraseñas está habilitada,

Si usted ha decidido utilizar autenticación a través de llaves; ha generado las llaves, ha probado que estas funcionan, ha determinado que si le permiten iniciar sesión como usted lo requiere, puede deshabilitar la autenticación a través de contraseñas (¡Si no ha comprobado lo anterior, no la deshabilite!)

Deshabilitar contraseñas vacías

Deshabilitar el reenvío de X11

Si no es necesario mostrar aplicaciones gráficas a través de SSH, deshabilitelo, cambiar el valor de “yes” a “no” 

así debería quedar

Limitar intentos de autenticación

Deshabilitar los métodos de autenticación que no serán utilizados

Si ya usted determinó un método de autenticación, deshabilite los que no va a utilizar

Permita sólo las direcciones ip necesarias

Antes de determinar la dirección IP que va a tener en cuenta en esta lista, piense en lo siguiente: ¿Desde donde me voy a conectar? ¿Me voy a conectar desde mi casa?¿La IP de mi casa cambia constantemente? ¿Voy a utilizar un jumpserver? ¿Cambia la dirección IP de ese jumpserver? Tenga en cuenta las respuestas a las preguntas anteriores, dado que si la configuración no es adecuada, podría quedar sin acceso al servidor ssh.

En el caso de la imagen solo se permitirá iniciar sesión en el servidor ssh desde la ip 192.168.0.8 con el usuario behackerpro

¿Existen otras opciones avanzadas para asegurar aún más ssh?

Así es, existen muchas más opciones para brindarle mayor seguridad, sin embargo, serán tratadas en otras entradas.

Déjanos tus comentarios y únete a nuestra comunidad Hacker Pro! Te interesa algún tema en particular?