Cómo reforzar el cliente OpenSSH en Ubuntu 20.04

Jamie Scaife escribió una versión anterior de este tutorial .

Introducción

Los servidores Linux suelen administrarse de forma remota mediante SSH conectándose a un servidor OpenSSH , que es el software de servidor SSH predeterminado que se utiliza en Ubuntu, Debian, CentOS, FreeBSD y la mayoría de los demás sistemas basados ​​en Linux/BSD. Se dedica un esfuerzo considerable a proteger el aspecto del servidor de SSH, ya que SSH actúa como la entrada a su servidor.

Sin embargo, también es importante considerar la seguridad del lado del cliente, como el cliente OpenSSH.

El cliente OpenSSH es el lado “cliente” de SSH, también conocido como el sshcomando. Puede obtener más información sobre el modelo cliente-servidor de SSH en Conceptos básicos de SSH: cómo trabajar con servidores, clientes y claves SSH .

Al reforzar SSH en el lado del servidor, el objetivo principal es dificultar el acceso de actores maliciosos a su servidor. Sin embargo, el refuerzo en el lado del cliente es muy diferente, ya que en su lugar se trabaja para defender y proteger su conexión SSH y su cliente de varias amenazas diferentes, entre ellas:

• Atacantes en la red, conocidos como ataques de “persona en el medio”.
• Servidores comprometidos o maliciosos que envían paquetes de datos malformados, secuencias de control nefastas o grandes cantidades de datos para sobrecargar a su cliente.
• Error humano, como escribir mal las direcciones del servidor o los valores de configuración.

En este tutorial, fortalecerá su cliente OpenSSH de Ubuntu 20.04 para ayudar a garantizar que las conexiones SSH salientes sean lo más seguras posible.

Prerrequisitos

Para completar este tutorial, necesitarás:

• Un dispositivo que utilizará como cliente SSH, por ejemplo:

  • Tu computadora personal
  • Un “host de salto” o “host bastión” de SSH
  • Un servidor Ubuntu 20.04 configurado siguiendo la Configuración inicial del servidor con Ubuntu 20.04 , incluido un usuario sudo no root

• Un servidor SSH al que desea conectarse, por ejemplo:

  • Un servidor en la nube
  • Un servicio público como GitHub o GitLab
  • Un dispositivo de terceros al que se le permite acceder

Una vez que tenga esto listo, inicie sesión en su dispositivo cliente SSH como un usuario no root para comenzar.

Paso 1: endurecimiento general

En este primer paso, implementará algunas configuraciones de fortalecimiento iniciales para mejorar la seguridad general de su cliente SSH.

La configuración de protección exacta más adecuada para su cliente depende en gran medida de su propio modelo de amenazas y umbral de riesgo . Sin embargo, la configuración descrita en este paso es una configuración general y segura que debería ser adecuada para la mayoría de los usuarios.

Muchas de las configuraciones de protección del cliente OpenSSH se implementan mediante el archivo de configuración global del cliente OpenSSH, que se encuentra en /etc/ssh/ssh_config. Además de este archivo, algunas configuraciones también se pueden establecer mediante el archivo de configuración SSH local para su usuario, que se encuentra en ~/.ssh/config.

Para configurar la mayoría de las opciones de protección en este tutorial, es recomendable crear una copia de seguridad del archivo de configuración existente para poder restaurarlo en el improbable caso de que algo salga mal.

Cree una copia de seguridad del archivo utilizando el siguiente cpcomando:

sudo cp /etc/ssh/ssh_config /etc/ssh/ssh_config.bak
cp ~/.ssh/config ~/.ssh/config.bak

Estos comandos guardarán copias de seguridad de los archivos en su ubicación predeterminada, pero con la .bakextensión agregada.

Tenga en cuenta que es posible que su archivo de configuración SSH local ( ~/.ssh/config) no exista si no lo ha utilizado en el pasado. Si este es el caso, puede ignorarlo por ahora.

Ahora puede abrir el archivo de configuración global usando nanosu editor de texto favorito para comenzar a implementar las medidas de fortalecimiento iniciales:

sudo nano /etc/ssh/ssh_config

Nota: El archivo de configuración del cliente OpenSSH incluye muchas opciones y configuraciones predeterminadas. Según la configuración del cliente existente, es posible que ya se hayan configurado algunas de las opciones de protección recomendadas.

Al editar el archivo de configuración, es posible que algunas opciones estén comentadas de forma predeterminada mediante un solo carácter numeral ( #) al comienzo de la línea. Para editar estas opciones o habilitar la opción, deberá quitar el comentario eliminando el carácter numeral.

Primero, deshabilite el reenvío de pantalla X11 si no lo está utilizando configurando las siguientes opciones:

/etc/ssh/ssh_config

ForwardX11 noForwardX11Trusted no

El reenvío X11 permite la visualización de aplicaciones gráficas remotas a través de una conexión SSH, aunque esto rara vez se utiliza en la práctica. Al deshabilitarlo, puede evitar que servidores potencialmente maliciosos o comprometidos intenten reenviar una sesión X11 a su cliente, lo que en algunos casos puede permitir que se omitan los permisos del sistema de archivos o que se controlen las pulsaciones de teclas locales.

A continuación, considere desactivar la tunelización SSH. La tunelización SSH se utiliza bastante, por lo que es posible que deba mantenerla habilitada. Por lo general, sabrá si la está utilizando. Si no es necesaria para su configuración particular, puede desactivarla de manera segura como una medida de protección adicional:

/etc/ssh/ssh_config

Tunnel no

También debe considerar deshabilitar el reenvío del agente SSH si no es necesario, para evitar que los servidores soliciten usar su agente SSH local para autenticar conexiones SSH posteriores:

/etc/ssh/ssh_config

ForwardAgent no

En la mayoría de los casos, su cliente SSH estará configurado para utilizar autenticación con contraseña o autenticación con clave pública al conectarse a los servidores. Sin embargo, el cliente OpenSSH también admite otros métodos de autenticación, algunos de los cuales están habilitados de forma predeterminada. Si no son necesarios, se pueden deshabilitar para reducir aún más la superficie de ataque potencial de su cliente:

/etc/ssh/ssh_config

GSSAPIAuthentication noHostbasedAuthentication no

Si desea obtener más información sobre algunos de los métodos de autenticación adicionales disponibles dentro de SSH, puede revisar estos recursos:

• Autenticación GSSAPI
• Autenticación basada en host

El cliente OpenSSH le permite pasar automáticamente variables de entorno personalizadas al conectarse a servidores, por ejemplo, para establecer una preferencia de idioma o configurar los ajustes de la terminal. Sin embargo, si esto no es necesario en su configuración, puede evitar que se envíen variables asegurándose de que la SendEnvopción esté comentada o completamente eliminada:

/etc/ssh/ssh_config

# SendEnv

Por último, debe asegurarse de que la verificación estricta de la clave de host esté habilitada, para garantizar que se le advierta adecuadamente cuando la clave/huella digital del host de un servidor remoto cambie, o cuando se conecte a un nuevo servidor por primera vez:

/etc/ssh/ssh_config

StrictHostKeyChecking ask

Esto evitará que se conecte a un servidor cuando la clave de host conocida haya cambiado, lo que podría significar que el servidor ha sido reconstruido o actualizado, o podría ser indicativo de un ataque de intermediario en curso.

Al conectarse a un nuevo servidor por primera vez, su cliente SSH le preguntará si desea aceptar la clave de host y guardarla en su ~/.ssh/known_hostsarchivo. Es importante que verifique la clave de host antes de aceptarla, lo que generalmente implica preguntarle al administrador del servidor o consultar la documentación del servicio (en el caso de GitHub/GitLab y otros servicios similares).

Guardar y salir del archivo.

Ahora que ha completado el fortalecimiento de su archivo de configuración inicial, debe validar la sintaxis de su nueva configuración ejecutando SSH en modo de prueba:

ssh -G .

Puede sustituirlo .por cualquier nombre de host para probar/simular cualquier configuración contenida dentro de los bloques Matcho Host.

Si el archivo de configuración tiene una sintaxis válida, se imprimirán las opciones que se aplicarán a esa conexión específica. En caso de que se produzca un error de sintaxis, se mostrará un mensaje que describirá el problema.

No es necesario reiniciar ningún servicio del sistema para que la nueva configuración surta efecto, aunque será necesario restablecer las sesiones SSH existentes si desea que hereden la nueva configuración.

En este paso, completó algunas mejoras generales en el archivo de configuración del cliente OpenSSH. A continuación, restringirá los cifrados que están disponibles para su uso en conexiones SSH.

Paso 2: Restringir los cifrados disponibles

OpenSSH admite varios algoritmos de cifrado diferentes para cifrar datos en una conexión. En este paso, deshabilitará los conjuntos de cifrado obsoletos o antiguos en su cliente SSH.

Comience abriendo su archivo de configuración global en nanosu editor de texto preferido:

sudo nano /etc/ssh/ssh_config

Asegúrese de que la línea de configuración existente Ciphersesté comentada anteponiéndole un solo símbolo hash ( #).

Luego, agregue lo siguiente en la parte superior del archivo:

/etc/ssh/ssh_config

Ciphers -arcfour*,-*cbc

Esto deshabilitará los cifrados Arcfour heredados , así como todos los cifrados que utilizan Cipher Block Chaining (CBC) , cuyo uso ya no se recomienda.

Si existe un requisito para conectarse a sistemas que solo admiten estos cifrados heredados, puede volver a habilitar explícitamente los cifrados requeridos para hosts específicos mediante un Matchbloque. Por ejemplo, para habilitar el 3des-cbccifrado para un host heredado específico, se podría utilizar la siguiente configuración:

/etc/ssh/ssh_config

Match host legacy-server.your-domain  Ciphers +3des-cbc

Guarde y salga del archivo cuando haya terminado de editarlo. Si está utilizando la función, nanopresione CTRL+Oy luego ENTERpara guardar el archivo y luego CTRL+Xpara salir.

Por último, como en el paso 1, prueba la configuración de tu cliente SSH para verificar si hay posibles errores:

ssh -G .

Si ha agregado un Matchbloque para habilitar cifrados heredados para un host específico, también puede apuntar específicamente a esa configuración durante la prueba especificando la dirección de host asociada:

ssh -G legacy-server.your-domain

Ha protegido los cifrados disponibles para su cliente SSH. A continuación, revisará los permisos de acceso a los archivos que utiliza su cliente SSH.

Paso 3: Protección de los permisos de clave privada y archivo de configuración

En este paso, bloqueará los permisos de los archivos de configuración del cliente SSH y las claves privadas para ayudar a evitar cambios accidentales o maliciosos, o la divulgación de claves privadas. Esto es especialmente útil cuando se utiliza un dispositivo cliente compartido entre varios usuarios.

De manera predeterminada, en una nueva instalación de Ubuntu, los archivos de configuración del cliente OpenSSH están configurados para que cada usuario solo pueda editar su propio archivo de configuración local ( ~/.ssh/config), y se requiere acceso sudo/administrativo para editar la configuración de todo el sistema ( /etc/ssh/ssh_config).

Sin embargo, en algunos casos, especialmente en sistemas que han existido durante mucho tiempo, estos permisos de archivos de configuración pueden haberse modificado o ajustado accidentalmente, por lo que es mejor restablecerlos para asegurarse de que la configuración sea segura.

Puede comenzar verificando el valor de los permisos actuales para el archivo de configuración del cliente OpenSSH de todo el sistema mediante el statcomando, que puede usar para mostrar el estado de los archivos y/o los objetos del sistema de archivos:

stat -c "%a %A %U:%G" /etc/ssh/ssh_config

Utilice el -cargumento para especificar un formato de salida personalizado.

Nota : En algunos sistemas operativos, como macOS, necesitarás usar la -fopción para especificar un formato personalizado en lugar de -c.

En este caso, las %A %a %U:%Gopciones imprimirán los permisos del archivo en formato octal y legible por humanos, así como el usuario/grupo que posee el archivo.

Esto producirá un resultado similar a lo siguiente:

Output644 -rw-r--r-- root:root

En este caso, los permisos son correctos, root es el propietario completo del archivo y solo root tiene permiso para escribir en él o modificarlo.

Nota: Si desea refrescar sus conocimientos sobre los permisos de Linux antes de continuar, puede revisar Introducción a los permisos de Linux .

Sin embargo, si su propia salida es diferente, debe restablecer los permisos a los valores predeterminados utilizando los siguientes comandos:

sudo chown root:root /etc/ssh/ssh_config
sudo chmod 644 /etc/ssh/ssh_config

Si repite el statcomando de anteriormente en este paso, ahora recibirá los valores correctos para el archivo de configuración de todo el sistema.

A continuación, puede realizar las mismas comprobaciones para su propio archivo de configuración de cliente SSH local, si tiene uno:

stat -c "%a %A %U:%G" ~/.ssh/config

Ahora el statcomando debería generar lo siguiente:

Output644 -rw--r--r-- user:user

Si los permisos para su propio archivo de configuración de cliente son diferentes, debe restablecerlos utilizando los siguientes comandos, de manera similar a lo indicado anteriormente en el paso:

chown user:user ~/.ssh/config
chmod 644 ~/.ssh/config

A continuación, puedes verificar los permisos de cada una de las claves privadas SSH que tienes dentro de tu ~/.sshdirectorio, ya que estos archivos solo deben ser accesibles por ti y no por ningún otro usuario del sistema.

Comience imprimiendo los valores actuales de permiso y propiedad para cada clave privada:

stat -c "%a %A %U:%G" ~/.ssh/id_rsa

Esto producirá un resultado similar a lo siguiente:

Output600 -rw------- user:user

Es extremadamente importante que bloquees adecuadamente los permisos para tus archivos de clave privada, ya que no hacerlo podría permitir que otros usuarios de tu dispositivo los roben y accedan a los servidores asociados o cuentas de usuarios remotos.

Si los permisos no están configurados correctamente, utilice los siguientes comandos en cada archivo de clave privada para restablecerlos a los valores predeterminados seguros:

chown user:user ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa

En este paso, evaluó y bloqueó los permisos de archivo para los archivos de configuración y las claves privadas de su cliente SSH. A continuación, implementará una lista de permitidos salientes para limitar los servidores a los que puede conectarse su cliente.

Paso 4: Restringir las conexiones salientes mediante una lista de host permitidos

En este último paso, implementará una lista de permitidos salientes para restringir los hosts a los que su cliente SSH puede conectarse. Esto es especialmente útil para sistemas compartidos o multiusuario, así como para hosts de salto SSH o hosts bastión.

Este control de seguridad está diseñado específicamente para ayudar a proteger contra errores humanos, como direcciones de servidor o nombres de host mal escritos. El usuario puede evitarlo fácilmente editando su archivo de configuración local, por lo que no está diseñado para actuar como defensa contra usuarios o actores malintencionados.

Si desea restringir las conexiones salientes a nivel de red, la forma correcta de hacerlo es mediante reglas de firewall. Esto queda fuera del alcance de este tutorial, pero puede consultar UFW Essentials: Common Firewall Rules and Commands (Conceptos básicos de UFW: reglas y comandos comunes de firewall) .

Sin embargo, si desea agregar algunas medidas de seguridad adicionales, este control de seguridad puede resultarle beneficioso.

Funciona mediante el uso de una regla comodín dentro del archivo de configuración del cliente SSH para enrutar todas las conexiones salientes, excepto aquellas a direcciones o nombres de host específicos. Esto significa que si alguna vez escribes mal por accidente la dirección de un servidor o intentas conectarte a un servidor al que no deberías, la solicitud se detendrá de inmediato, lo que te dará la oportunidad de darte cuenta de tu error y tomar medidas correctivas.

Puede aplicar esto a nivel de sistema ( /etc/ssh/ssh_config) o mediante el archivo de configuración de usuario local ( ~/.ssh/config). En este ejemplo, utilizaremos el archivo de configuración de usuario local.

Comience abriendo el archivo usando nano, creándolo si aún no existe:

nano ~/.ssh/config

Al final del archivo, agregue el siguiente contenido, sustituyendo su propia lista de direcciones IP y nombres de host permitidos:

~/.ssh/config

Match host !203.0.113.1,!192.0.2.1,!server1.your-domain,!github.com,*  Hostname localhost

Esta configuración le indica a su cliente SSH que, para cualquier host o IP que no esté incluido en la lista, el cliente debe sustituir el nombre localhostantes de intentar conectarse. La *opción de comodín ( ) sin un signo de exclamación prefijado al final de la Matchlínea garantiza que cualquier host que no esté incluido en la lista se enrutará de forma predeterminada a nulo.

Debe anteponer un signo de exclamación ( !) a las direcciones IP o los nombres de host, ya que esto le indica a SSH que no aplique el enrutamiento nulo para el nombre de host o la dirección IP. Además, debe usar comas para separar cada elemento de la lista.

Si también está ejecutando un servidor SSH en su máquina, es posible que desee utilizar un valor de nombre de host distinto de localhost, ya que esto hará que las conexiones enrutadas nulas se envíen a su propio servidor SSH local, lo que podría ser contraproducente o confuso. Cualquier nombre de host enrutado nulo es aceptable, como null, do-not-useo disallowed-server.

Guarde y cierre el archivo una vez que haya realizado los cambios.

Ahora puede probar que la configuración funciona al intentar conectarse a un destino no permitido mediante su cliente SSH. Por ejemplo:

ssh disallowed.your-domain

Si la configuración funciona correctamente, recibirás inmediatamente un error similar al siguiente:

OutputCannot connect to localhost: connection refused

Sin embargo, cuando intente conectarse a un destino permitido, la conexión se realizará con normalidad.

En este paso final, implementó algunas medidas de seguridad adicionales para ayudar a protegerse contra errores y equivocaciones humanas al usar su cliente SSH.

Conclusión

En este artículo revisó la configuración de su cliente OpenSSH e implementó varias medidas de fortalecimiento.

Esto mejorará la seguridad de sus conexiones SSH salientes, además de ayudar a garantizar que sus archivos de configuración local no puedan ser modificados accidental o maliciosamente por otros usuarios.

Es posible que desee revisar las páginas del manual del cliente OpenSSH y su archivo de configuración asociado para identificar posibles ajustes adicionales que desee realizar:

• Cliente OpenSSH
• Archivos de configuración del cliente OpenSSH

Por último, si desea fortalecer OpenSSH también en el lado del servidor, consulte Cómo fortalecer OpenSSH en Ubuntu 20.04 .