Cómo configurar la autenticación de múltiples factores para SSH en CentOS 7

Introducción

Un factor de autenticación es una pieza única de información utilizada para demostrar que tiene los derechos para realizar una acción, como iniciar sesión en un sistema. Un canal de autenticación es la forma en que un sistema de autenticación entrega un factor al usuario o requiere que el usuario responda. Las contraseñas y los tokens de seguridad son ejemplos de factores de autenticación; los ordenadores y los teléfonos son ejemplos de canales.

SSH utiliza contraseñas para la autenticación por defecto, y la mayoría de las instrucciones de endurecimiento de SSH recomiendan utilizar una clave SSH en su lugar. Sin embargo, esto sigue siendo sólo un único factor. Si un mal actor ha comprometido su computadora, entonces pueden usar su clave para comprometer sus servidores también.

En este tutorial, vamos a configurar la autenticación de múltiples factores para combatir eso. La autenticación multifactor (MFA) requiere más de un factor para autenticar o iniciar sesión. Esto significa que un mal actor tendría que comprometer múltiples cosas, como tu ordenador y tu teléfono, para entrar. Los diferentes tipos de factores suelen resumirse como:

1. Algo que sabes, como una contraseña o una pregunta de seguridad
2. Algo que tienes, como una aplicación de autenticación o un token de seguridad
3. Algo que eres, como tu huella dactilar o tu voz

Un factor común es una aplicación OATH-TOTP, como Google Authenticator. OATH-TOTP (Open Authentication Time-Based One-Time Password) es un protocolo abierto que genera una contraseña de un solo uso, comúnmente un número de 6 dígitos que se recicla cada 30 segundos.

Este artículo repasará cómo habilitar la autenticación SSH utilizando una aplicación OATH-TOTP además de una clave SSH. El inicio de sesión en su servidor a través de SSH requerirá entonces dos factores a través de dos canales, por lo que es más seguro que una contraseña o una clave SSH sola. Además, repasaremos algunos casos de uso adicionales para MFA y algunos consejos y trucos útiles.

Requisitos previos

Para seguir este tutorial, necesitará:

• Un servidor CentOS 7 con un usuario sudo no root y una clave SSH, que puede configurar siguiendo este tutorial de configuración inicial del servidor.
• Un smartphone o tableta con una aplicación OATH-TOTP instalada, como Google Authenticator (iOS, Android).

Paso 1 – Instalación de PAM de Google

En este paso, instalaremos y configuraremos PAM de Google.

PAM, que significa Pluggable Authentication Module, es una infraestructura de autenticación utilizada en los sistemas Linux para autenticar a un usuario. Dado que Google ha creado una aplicación OATH-TOTP, también ha creado un PAM que genera TOTPs y es totalmente compatible con cualquier aplicación OATH-TOTP, como Google Authenticator o Authy.

Primero, tenemos que añadir el repo EPEL (Extra Packages for Enterprise Linux).

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

A continuación, instala el PAM. Es posible que se le pida que acepte la clave EPEL si es la primera vez que utiliza el repo. Una vez aceptada no se te pedirá de nuevo que aceptes la clave.

sudo yum install google-authenticator

Con el PAM instalado, usaremos una aplicación de ayuda que viene con el PAM para generar una clave TOTP para el usuario al que quieras añadir un segundo factor. Esta clave se genera usuario por usuario, no en todo el sistema. Esto significa que cada usuario que quiera utilizar una aplicación de autenticación TOTP tendrá que iniciar sesión y ejecutar la aplicación de ayuda para obtener su propia clave; no puedes ejecutarla una sola vez para habilitarla para todos (pero hay algunos consejos al final de este tutorial para configurar o requerir MFA para muchos usuarios).

Ejecuta la aplicación de inicialización.

google-authenticator

Después de ejecutar el comando, se te harán algunas preguntas. La primera pregunta es si los tokens de autenticación deben estar basados en el tiempo.

Output
Do you want authentication tokens to be time-based (y/n) y

Este PAM permite tokens basados en el tiempo o secuenciales. Usar tokens basados en la secuencia significa que el código comienza en un punto determinado y luego incrementa el código después de cada uso. El uso de tokens basados en el tiempo significa que el código cambia aleatoriamente después de un cierto tiempo. Nos quedaremos con los basados en el tiempo porque eso es lo que anticipan las aplicaciones como Google Authenticator, así que contesta y para que sí.

Después de responder a esta pregunta, se desplazará una gran cantidad de salida, incluyendo un gran código QR. En este punto, utiliza tu aplicación de autenticación en tu teléfono para escanear el código QR o escribe manualmente la clave secreta. Si el código QR es demasiado grande para escanearlo, puedes utilizar la URL que aparece encima del código QR para obtener una versión más pequeña. Una vez añadido, verás un código de seis dígitos que cambia cada 30 segundos en tu aplicación.

Nota: Asegúrate de registrar la clave secreta, el código de verificación y los códigos de recuperación en un lugar seguro, como un gestor de contraseñas. Los códigos de recuperación son la única forma de recuperar el acceso si, por ejemplo, pierdes el acceso a tu aplicación TOTP.

Las preguntas restantes informan al PAM sobre su funcionamiento. Las repasaremos una a una.

Output
Do you want me to update your "/home/sammy/.google_authenticator" file (y/n) y

Esto escribe la clave y las opciones en el archivo .google_authenticator. Si dices que no, el programa se cierra y no se escribe nada, lo que significa que el autentificador no funcionará.

Output
Do you want to disallow multiple uses of the same authenticationtoken? This restricts you to one login about every 30s, but it increasesyour chances to notice or even prevent man-in-the-middle attacks (y/n) y

Al responder sí aquí, estás previniendo un ataque de repetición al hacer que cada código expire inmediatamente después de su uso. Esto evita que un atacante capture un código que acabas de usar y se registre con él.

Output
By default, tokens are good for 30 seconds. In order to compensate forpossible time-skew between the client and the server, we allow an extratoken before and after the current time. If you experience problems withpoor time synchronization, you can increase the window from its defaultsize of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens). Do you want to do so? (y/n) n

Responder afirmativamente aquí permite hasta 8 códigos válidos en una ventana de cuatro minutos en movimiento. Respondiendo no, lo limitas a 3 códigos válidos en una ventana móvil de 1:30 minutos. A menos que encuentre problemas con la ventana de 1:30 minutos, responder no es la opción más segura.

Output
If the computer that you are logging into isn't hardened against brute-forcelogin attempts, you can enable rate-limiting for the authentication module.By default, this limits attackers to no more than 3 login attempts every 30s.Do you want to enable rate-limiting (y/n) y

La limitación de velocidad significa que un atacante remoto sólo puede intentar un cierto número de conjeturas antes de ser bloqueado. Si no ha configurado previamente la limitación de velocidad directamente en SSH, hacerlo ahora es una gran técnica de endurecimiento.

Nota: Una vez que termine esta configuración, si quiere hacer una copia de seguridad de su clave secreta, puede copiar el archivo ~/.google-authenticator a una ubicación de confianza. A partir de ahí, puedes desplegarlo en sistemas adicionales o volver a desplegarlo después de una copia de seguridad.

Ahora que el PAM de Google está instalado y configurado, el siguiente paso es configurar SSH para usar tu clave TOTP. Tendremos que decirle a SSH sobre el PAM y luego configurar SSH para usarlo.

Paso 2 – Configurar OpenSSH

Debido a que realizaremos cambios en SSH a través de SSH, es importante no cerrar nunca la conexión SSH inicial. En su lugar, abra una segunda sesión SSH para hacer pruebas. Esto es para evitar el bloqueo de su servidor si hubo un error en su configuración SSH. Una vez que todo funciona, entonces usted puede cerrar con seguridad cualquier sesión.

Para empezar vamos a editar el archivo de configuración sshd. Aquí, estamos usando nano, que no está instalado en CentOS por defecto. Puedes instalarlo con sudo yum install nano, o utilizar tu editor de texto alternativo favorito.

sudo nano /etc/pam.d/sshd

Añade la siguiente línea al final del archivo.

. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

La palabra nullok al final de la última línea le dice al PAM que este método de autenticación es opcional. Esto permite a los usuarios que no tienen un token OATH-TOTP iniciar la sesión utilizando su clave SSH. Una vez que todos los usuarios tengan un token OATH-TOTP, puedes eliminar nullok de esta línea para que la MFA sea obligatoria.

Guarda y cierra el archivo.

A continuación, configuraremos SSH para que soporte este tipo de autenticación. Abra el archivo de configuración de SSH para editarlo.

sudo nano /etc/ssh/sshd_config

Busque las líneas ChallengeResponseAuthentication. Comentar la línea no y descomentar la línea no.

. . .# Change to no to disable s/key passwordsChallengeResponseAuthentication yes#ChallengeResponseAuthentication no. . .

Guardar y cerrar el archivo, luego reiniciar SSH para recargar los archivos de configuración. Reiniciar el servicio sshd no cerrará las conexiones abiertas, por lo que no correrá el riesgo de bloquearse con este comando.

sudo systemctl restart sshd.service

Para comprobar que todo funciona hasta el momento, abra otra terminal e intente iniciar sesión a través de SSH. Si has creado previamente una clave SSH y la estás utilizando, te darás cuenta de que no has tenido que escribir la contraseña de tu usuario ni el código de verificación MFA. Esto se debe a que una clave SSH anula todas las demás opciones de autenticación por defecto. De lo contrario, debería haber obtenido una contraseña y un código de verificación.

Si quiere asegurarse de que lo que ha hecho hasta ahora funciona, en su sesión SSH abierta navegue a ~/.ssh/ y cambie el nombre del archivo authorized_keys, temporalmente, y abra una nueva sesión e inicie sesión con nuestra contraseña y código de verificación.

 
cd ~/.ssh
 
mv authorized_keys authorized_keys.bak
 

Una vez que haya verificado que su token TOTP funciona cambie el nombre del archivo ‘authorized_keys.bak’ a lo que era.

mv authorized_keys.bak authorized_keys

A continuación, tenemos que habilitar una clave SSH como un factor y el código de verificación como un segundo y decirle a SSH qué factores utilizar y evitar que la clave SSH anule todos los demás tipos.

Paso 3 – Hacer que SSH sea consciente de MFA

Reabrir el archivo de configuración sshd.

sudo nano /etc/ssh/sshd_config

Añadir la siguiente línea en la parte inferior del archivo. Esto le dice a SSH qué métodos de autenticación son necesarios. Esta línea le dice a SSH que necesitamos una clave SSH y una contraseña o un código de verificación (o los tres).

. . .# Added by DigitalOcean build processClientAliveInterval 120ClientAliveCountMax 2AuthenticationMethods publickey,password publickey,keyboard-interactive

Guarda y cierra el archivo.

A continuación, abre de nuevo el archivo de configuración PAM sshd.

sudo nano /etc/pam.d/sshd

Busca la línea auth substack password-auth hacia la parte superior del archivo. Coméntela añadiendo un carácter # como primer carácter de la línea. Esto le dice a PAM que no pida una contraseña.

. . .#auth substack password-auth. . .

Guarde y cierre el archivo, luego reinicie SSH.

sudo systemctl restart sshd.service

Ahora intente ingresar al servidor nuevamente con una sesión diferente. A diferencia de la última vez, SSH debería pedirle su código de verificación. Al introducirlo, se iniciará la sesión. Aunque no vea ninguna indicación de que su clave SSH fue utilizada, su intento de ingreso utilizó dos factores. Si quieres verificar, puedes añadir -v (para verbosidad) después del comando SSH:

Example SSH output\
. . .debug1: Authentications that can continue: publickeydebug1: Next authentication method: publickeydebug1: Offering RSA public key: /Users/sammy/.ssh/id_rsadebug1: Server accepts key: pkalg ssh-rsa blen 279Authenticated with partial success.debug1: Authentications that can continue: keyboard-interactivedebug1: Next authentication method: keyboard-interactiveVerification code:

Hacia el final de la salida, verás que SSH utiliza tu clave SSH y luego pide el código de verificación. Ahora puede iniciar sesión a través de SSH con una clave SSH y una contraseña de un solo uso. Si desea aplicar los tres tipos de autenticación, puede seguir el siguiente paso.

Paso 4 – Añadir un tercer factor (opcional)

En el paso 3, enumeramos los tipos de autenticación aprobados en el archivo sshd_config:

1. publickey (clave SSH)
2. password publickey (contraseña)
3. keyboard-interactive (código de verificación)

Aunque enumeramos tres factores diferentes, con las opciones que hemos elegido hasta ahora, sólo permiten una clave SSH y el código de verificación. Si desea tener los tres factores (clave SSH, contraseña y código de verificación), un cambio rápido habilitará los tres.

Abra el archivo de configuración PAM sshd.

sudo nano /etc/pam.d/sshd

Localice la línea que comentó anteriormente, #auth substack password-auth, y descomente la línea eliminando el carácter #. Guarde y cierre el archivo. Ahora, una vez más, reinicie SSH.

sudo systemctl restart sshd.service

Activando la opción auth substack password-auth, PAM pedirá ahora una contraseña además de la comprobación de una clave SSH y la petición de un código de verificación, que teníamos funcionando anteriormente. Ahora podemos utilizar algo que conocemos (la contraseña) y dos tipos diferentes de cosas que tenemos (la clave SSH y el código de verificación) a través de dos canales diferentes.

Hasta ahora, este artículo ha descrito cómo habilitar MFA con una clave SSH y una contraseña de un solo uso basada en el tiempo. Si esto es todo lo que necesitas, puedes terminar aquí. Sin embargo, esta no es la única manera de hacer la autenticación multifactor. A continuación hay un par de maneras adicionales de utilizar este módulo PAM para la autenticación de múltiples factores y algunos consejos y trucos para la recuperación, el uso automatizado, y más.

Consejo 1 – Recuperar el acceso

Como con cualquier sistema que usted endurece y asegura, usted se convierte en responsable de la gestión de esa seguridad. En este caso, eso significa no perder tu clave SSH o tu clave secreta TOTP y asegurarte de que tienes acceso a tu aplicación TOTP. Sin embargo, a veces ocurren cosas y puedes perder el control de las claves o las aplicaciones que necesitas para entrar.

Perder una clave SSH o una clave secreta TOTP

Si pierdes tu clave SSH o tu clave secreta TOTP, la recuperación puede dividirse en un par de pasos. El primero es volver a entrar sin saber el código de verificación y el segundo es encontrar la clave secreta o regenerarla para el inicio de sesión normal de MFA.

Para entrar después de perder la clave secreta que genera el código de verificación en un Droplet de DigitalOcean, puede simplemente utilizar la consola virtual de su tablero para iniciar sesión con su nombre de usuario y contraseña.

De lo contrario, necesitará un usuario administrativo que tenga acceso sudo; asegúrese de no habilitar MFA para este usuario, sino que utilice sólo una clave SSH. Si usted u otro usuario pierde su clave secreta y no puede ingresar, entonces el usuario administrativo puede ingresar y ayudar a recuperar o regenerar la clave para cualquier usuario usando sudo.

Una vez que se ha iniciado la sesión, hay dos maneras de ayudar a obtener el secreto TOTP:

1. Recuperar la clave existente
2. Generar una nueva clave

En el directorio principal de cada usuario, la clave secreta y la configuración del Autenticador de Google se guardan en ~/.google-authenticator. La primera línea de este archivo es la clave secreta. Una forma rápida de obtener la clave es ejecutar el siguiente comando, que muestra la primera línea del archivo google-authenticator (es decir, la clave secreta). Luego, tome esa clave secreta y escríbala manualmente en una aplicación TOTP.

head -n 1 /home/sammy/.google_authenticator

Si hay una razón para no usar la clave existente (por ejemplo, no poder compartir fácilmente la clave secreta con el usuario impactado de forma segura o la clave existente fue comprometida), puede eliminar el archivo ~/.google-authenticator directamente. Esto permitirá al usuario iniciar la sesión de nuevo utilizando un único factor, asumiendo que no has aplicado MFA eliminando ‘nullok’ en el archivo ‘/etc/pam.d/sshd’. Entonces pueden ejecutar google-authenticator para generar una nueva clave.

Perdiendo el acceso a la aplicación TOTP

Si necesitas iniciar sesión en tu servidor pero no tienes acceso a tu aplicación TOTP para obtener tu código de verificación, todavía puedes iniciar sesión usando los códigos de recuperación que se mostraron cuando creaste tu clave secreta por primera vez. Ten en cuenta que estos códigos de recuperación son de un solo uso. Una vez que se utiliza uno para iniciar la sesión, no se puede volver a utilizar como código de verificación.

Consejo 2 – Cambiar la configuración de autenticación

Si quieres cambiar la configuración de tu MFA después de la configuración inicial, en lugar de generar una nueva configuración con los ajustes actualizados, puedes simplemente editar el archivo ~/.google-authenticator. Este archivo está dispuesto de la siguiente manera:

<secret key><options><recovery codes>

Las opciones que se establecen en este archivo tienen una línea en la sección de opciones; si respondiste «no» a una opción en particular durante la configuración inicial, la línea correspondiente se excluye del archivo.

Aquí están los cambios que puede hacer en este archivo:

• Para permitir códigos secuenciales en lugar de códigos basados en el tiempo, cambie la línea " TOTP_AUTH a " HOTP_COUNTER 1.
• Para permitir múltiples usos de un solo código, elimine la línea " DISALLOW_REUSE.
• Para extender la ventana de expiración del código a 4 minutos, agregue la línea " WINDOW_SIZE 17.
• Para desactivar los inicios de sesión múltiples fallidos (limitación de la tasa), elimine la línea " RATE_LIMIT 3 30.
• Para cambiar el umbral de la limitación de la tasa, encuentre la línea " RATE_LIMIT 3 30 y ajuste los números. El 3 en el original indica el número de intentos durante un período de tiempo, y el 30 indica el período de tiempo en segundos.
• Para desactivar el uso de códigos de recuperación, elimine los cinco códigos de 8 dígitos en la parte inferior del archivo.

Consejo 3 – Evitar MFA para algunas cuentas

Puede darse la situación de que un solo usuario o unas pocas cuentas de servicio (es decir, cuentas utilizadas por aplicaciones, no por humanos) necesiten acceso SSH sin MFA activado. Por ejemplo, algunas aplicaciones que usan SSH, como algunos clientes FTP, pueden no soportar MFA. Si una aplicación no tiene una forma de solicitar el código de verificación, la solicitud puede quedarse atascada hasta que la conexión SSH se agote.

Si se configuran correctamente un par de opciones en /etc/pam.d/sshd, se puede controlar qué factores se utilizan en función de cada usuario.

Para permitir MFA para algunas cuentas y clave SSH sólo para otras, asegúrese de que las siguientes opciones en /etc/pam.d/sshd están activas.

#%PAM-1.0auth required pam_sepermit.so#auth substack password-auth. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

Aquí, auth substack password-auth se comenta porque las contraseñas necesitan ser deshabilitadas. MFA no puede ser forzado si algunas cuentas están destinadas a tener MFA deshabilitado, así que deje la opción nullok en la línea final.

Después de establecer esta configuración, simplemente ejecute google-authenticator como cualquier usuario que necesite MFA, y no lo ejecute para los usuarios donde sólo se utilizarán las claves SSH.

Consejo 4 – Automatizar la instalación con la gestión de la configuración

Muchos administradores de sistemas utilizan herramientas de gestión de la configuración, como Puppet, Chef o Ansible, para gestionar sus sistemas. Si desea utilizar un sistema como este para instalar configurar una clave secreta cuando se crea la cuenta de un nuevo usuario, hay un método para hacerlo.

google-authenticator admite interruptores de línea de comandos para establecer todas las opciones en un solo comando no interactivo. Para ver todas las opciones, puede escribir google-authenticator --help. A continuación se muestra el comando que configuraría todo como se indica en el Paso 1:

google-authenticator -t -d -f -r 3 -R 30 -W

Esto responde a todas las preguntas que contestamos manualmente, lo guarda en un archivo, y luego emite la clave secreta, el código QR y los códigos de recuperación. (Si añade la bandera -q, no habrá ninguna salida.) Si utiliza este comando de forma automatizada, asegúrese de capturar la clave secreta y/o los códigos de recuperación y ponerlos a disposición del usuario.

Consejo 5 – Forzar MFA para todos los usuarios

Si quiere forzar MFA para todos los usuarios incluso en el primer inicio de sesión, o si prefiere no confiar en que sus usuarios generen sus propias claves, hay una forma fácil de hacerlo. Puede simplemente utilizar el mismo archivo .google-authenticator para cada usuario, ya que no hay datos específicos del usuario almacenados en el archivo.

Para hacer esto, después de que el archivo de configuración se crea inicialmente, un usuario con privilegios necesita copiar el archivo a la raíz de cada directorio personal y cambiar sus permisos al usuario apropiado. También puede copiar el archivo en /etc/skel/ para que se copie automáticamente en el directorio raíz de un nuevo usuario al crearlo.

Atención: Esto puede ser un riesgo de seguridad porque todos están compartiendo el mismo segundo factor. Esto significa que si se filtra, es como si cada usuario tuviera un solo factor. Tenlo en cuenta si quieres utilizar este método.

Otro método para forzar la creación de la clave secreta de un usuario es utilizar un script bash que:

1. Cree un token TOTP,
2. Les pida que se descarguen la aplicación Google Authenticator y escaneen el código QR que se les mostrará, y
3. Ejecute la aplicación google-authenticator por ellos después de comprobar si el archivo .google-authenticator ya existe.

Para asegurarte de que el script se ejecuta cuando un usuario inicia sesión, puedes nombrarlo .bash_login y colocarlo en la raíz de su directorio personal.

Conclusión

Dicho esto, al tener dos factores (una clave SSH + un token MFA) a través de dos canales (tu ordenador + tu teléfono), has hecho muy difícil que un agente externo pueda forzar su entrada en tu máquina a través de SSH y has aumentado enormemente la seguridad de tu máquina.