Cómo configurar la autenticación multifactor para SSH en Ubuntu 18.04

El autor seleccionó el Fondo de Ayuda COVID-19 para recibir una donación como parte del programa Write for DOnations.

Introducción

SSH utiliza contraseñas para la autenticación de forma predeterminada, y la mayoría de las instrucciones de refuerzo de SSH recomiendan utilizar una clave SSH en su lugar. Sin embargo, una clave SSH sigue siendo solo un factor único, aunque un factor mucho más seguro. El canal es la terminal de su computadora que envía los datos a través de un túnel cifrado a la máquina remota. Pero, al igual que un hacker puede adivinar una contraseña, puede robar una clave SSH y, en cualquier caso, con ese único dato, un atacante puede obtener acceso a sus sistemas remotos.

En este tutorial, configuraremos la autenticación multifactor para combatir esto. La autenticación multifactor (MFA) o la autenticación de dos factores (2FA) requiere más de un factor para autenticar o iniciar sesión. Esto significa que un actor malintencionado tendría que comprometer varias cosas, como su computadora y su teléfono, para ingresar. Existen varios tipos de factores que se utilizan en la autenticación:

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, generalmente un número de seis dígitos que se recicla cada 30 segundos.

En este artículo, se explicará cómo habilitar la autenticación SSH mediante una aplicación OATH-TOTP además de una clave SSH. Para iniciar sesión en su servidor a través de SSH, se necesitarán dos factores en dos canales, lo que lo hace más seguro que una contraseña o una clave SSH por sí solas. Además, repasaremos algunos casos de uso adicionales para MFA y algunos consejos y trucos útiles.

Y si busca más orientación sobre cómo proteger las conexiones SSH, consulte estos tutoriales sobre cómo proteger OpenSSH y cómo proteger el cliente OpenSSH.

Prerrequisitos

Para seguir este tutorial, necesitarás:

• Un servidor Ubuntu 18.04 con un usuario sudo no root, clave SSH y firewall habilitado, que puede configurar siguiendo este tutorial de configuración inicial del servidor.
• Un teléfono inteligente o tableta con una aplicación OATH-TOTP instalada, como Google Authenticator (iOS, Android).
• Como alternativa, también puede utilizar una aplicación de línea de comandos de Linux llamada "oathtool" para generar un código OATH-TOTP. Está disponible en varios repositorios de distribución.
• Si desea proteger su conexión SSH, hay varios pasos útiles delineados en este artículo de Conceptos básicos de SSH, como incluir usuarios en la lista blanca, deshabilitar el inicio de sesión root y cambiar el puerto que usa SSH.

Paso 1: Instalación del PAM de Google

En este paso, instalaremos y configuraremos el PAM de Google.

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

Primero, actualice el caché del repositorio de Ubuntu:

sudo apt-get update

A continuación, instale el PAM:

sudo apt-get install libpam-google-authenticator

Una vez instalado el PAM, utilizaremos una aplicación auxiliar que viene con el PAM para generar una clave TOTP para el usuario que necesita un segundo factor. Esta clave se genera usuario por usuario, no en todo el sistema. Esto significa que cada usuario que desee utilizar una aplicación de autenticación TOTP deberá iniciar sesión y ejecutar la aplicación auxiliar para obtener su clave; no puede 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).

Ejecute la aplicación de inicialización:

google-authenticator

Después de ejecutar el comando, la aplicación le hará algunas preguntas. La primera pregunta es si los tokens de autenticación deben basarse en el tiempo:

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

Este PAM permite tokens basados ​​en tiempo o secuenciales. El uso de tokens basados ​​en secuencias significa que el código comienza en un punto determinado y luego aumenta después de cada uso. El uso de tokens basados ​​en tiempo significa que el código cambia después de un período de tiempo determinado. Nos quedaremos con los tokens basados ​​en tiempo porque eso es lo que anticipan las aplicaciones como Google Authenticator, así que responda ysí.

Después de responder a esta pregunta, aparecerán muchos resultados, incluido un código QR de gran tamaño. Use la aplicación de autenticación en su teléfono para escanear el código QR o ingrese manualmente la clave secreta. Si el código QR es demasiado grande para escanearlo, puede usar la URL que se encuentra sobre el código QR para obtener una versión más pequeña. Una vez que se haya agregado, verá un código de seis dígitos que cambia cada 30 segundos en su aplicación.

Nota : Asegúrate de guardar la clave secreta, el código de verificación y los códigos de recuperación en un lugar seguro, como un administrador 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 le informan al PAM sobre cómo debe funcionar. Las analizaremos una por una:

OutputDo you want me to update your "~/.google_authenticator" file (y/n) y

Esto escribe la clave y las opciones en el .google_authenticatorarchivo. Si dice que no, el programa se cierra y no se escribe nada, lo que significa que el autenticador no funcionará:

OutputDo 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

Si responde "sí" en este caso, evitará un ataque de repetición al hacer que cada código caduque inmediatamente después de su uso. Esto evita que un atacante capture un código que acaba de usar e inicie sesión con él:

OutputBy default, a new token is generated every 30 seconds by the mobile app.In order to compensate for possible time-skew between the client and the server,we allow an extra token before and after the current time. This allows for atime skew of up to 30 seconds between the authentication server and client. Suppose youexperience problems with poor time synchronization. In that case, you can increase the windowfrom its default size of 3 permitted codes (one previous code, the currentcode, the next code) to 17 permitted codes (the eight previous codes, the currentcode, and the eight next codes). This will permit a time skew of up to 4 minutesbetween client and server.Do you want to do so? (y/n) n

Si responde "sí", podrá introducir hasta 17 códigos válidos en un intervalo de cuatro minutos. Si responde "no", podrá introducir hasta 3 códigos válidos en un intervalo de 1:30 minutos. A menos que tenga problemas con el intervalo de 1:30 minutos, responder "no" es la opción más segura. Puede cambiar esta configuración más adelante en el .google_authenticatorarchivo almacenado en la raíz de su directorio de inicio:

OutputIf 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 three login attempts every 30s.Do you want to enable rate-limiting (y/n) y

La limitación de velocidad significa que un atacante remoto solo puede intentar una cierta cantidad de intentos antes de verse obligado a esperar un tiempo antes de poder volver a intentarlo. Si no ha configurado previamente la limitación de velocidad directamente en SSH, hacerlo ahora es una excelente técnica de protección.

Nota : Una vez que hayas finalizado esta configuración, si deseas realizar una copia de seguridad de tu clave secreta, puedes copiar el ~/.google-authenticatorarchivo en una ubicación de confianza. Desde allí, puedes implementarlo en sistemas adicionales o volver a implementarlo 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. Necesitaremos informar a SSH sobre el PAM y luego configurar SSH para usarlo.

Paso 2: Configuración de OpenSSH para utilizar MFA/2FA

Dado que realizaremos cambios 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 realizar pruebas. Esto es para evitar quedarse fuera del servidor si se produjo un error en la configuración SSH. Una vez que todo funcione, podrá cerrar las sesiones de forma segura. Otra precaución de seguridad es crear una copia de seguridad de los archivos del sistema que va a editar, de modo que si algo sale mal, pueda volver al archivo original y comenzar de nuevo con una configuración limpia.

Para comenzar, haga una copia de seguridad del sshdarchivo de configuración:

sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.bak

Ahora abre el archivo usando nanotu editor de texto favorito:

sudo nano /etc/pam.d/sshd

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

/etc/pam.d/sshd

. . .# Standard Un*x password updating.@include common-passwordauth required pam_google_authenticator.so nullokauth required pam_permit.so

La nullokpalabra al final de la última línea le dice al PAM que este método de autenticación es opcional. Esto permite que los usuarios sin un token OATH-TOTP puedan iniciar sesión de todos modos usando solo su clave SSH. Una vez que todos los usuarios tengan un token OATH-TOTP, puede eliminar nullokesta línea para que la MFA sea obligatoria. La segunda línea pam_permit.soes necesaria para permitir la autenticación si un usuario no usa un token MFA para iniciar sesión. Al iniciar sesión, cada método necesita un ÉXITO para permitir la autenticación. Si un usuario no usa la herramienta de autenticación MFA, al utilizar la nullokopción se devuelve un IGNORAR para la autenticación del teclado interactivo. pam_permit.soLuego, se devuelve ÉXITO y se permite que la autenticación continúe.

Guarde y cierre el archivo.

A continuación, configuraremos SSH para admitir este tipo de autenticación.

Primero haga una copia de seguridad del archivo:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Ahora abra el archivo de configuración SSH para editarlo:

sudo nano /etc/ssh/sshd_config

Busque ChallengeResponseAuthenticationy establezca su valor en yes:

/etc/ssh/sshd_config

. . .# Change to yes to enable challenge-response passwords (beware issues with# some PAM modules and threads)ChallengeResponseAuthentication yes. . .

Guarde y cierre el archivo, luego reinicie SSH para volver a cargar los archivos de configuración. Reiniciar el sshdservicio no cerrará nuestras conexiones abiertas actuales, lo que significa que no correrá el riesgo de bloquearse con este comando:

sudo systemctl restart sshd.service

Para comprobar que todo funciona hasta ahora, abre OTRA terminal e intenta iniciar sesión mediante SSH. Es muy importante que mantengas abierta tu sesión SSH actual y pruebes con una sesión adicional, o te quedarás bloqueado en algún momento y tendrás que usar la consola web para volver a ingresar.

Nota: Si ya ha creado una clave SSH y la está utilizando, notará que no tuvo que escribir la contraseña de usuario ni el código de verificación de MFA. Esto se debe a que una clave SSH anula todas las demás opciones de autenticación de forma predeterminada. De lo contrario, debería haber recibido un mensaje con la contraseña y el código de verificación.

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

Paso 3: Hacer que SSH sea consciente de la MFA

La MFA sigue sin funcionar si estás usando una clave SSH. Para que SSH reconozca la MFA, vuelve a abrir el sshdarchivo de configuración:

sudo nano /etc/ssh/sshd_config

Agregue la siguiente línea al final del archivo. Esto le indica a SSH qué métodos de autenticación son necesarios. Le indicamos a SSH que los usuarios necesitan una clave SSH y una contraseña o un código de verificación (o los tres):

/etc/ssh/sshd_config

. . .AuthenticationMethods publickey,password publickey,keyboard-interactive

Guarde y cierre el archivo.

sshdA continuación, abra nuevamente el archivo de configuración PAM :

sudo nano /etc/pam.d/sshd

Busque la línea @include common-authy coméntela agregando un #carácter como primer carácter de la línea. Esto le indica a PAM que no solicite una contraseña:

/etc/pam.d/sshd

. . .# Standard Un*x authentication.#@include common-auth. . .

Guarde y cierre el archivo, luego reinicie SSH:

sudo systemctl restart sshd.service

Ahora, intenta iniciar sesión en el servidor nuevamente con una sesión/ventana de terminal diferente. A diferencia de la última vez, SSH debería solicitar tu código de verificación. Introdúcelo y habrás completado el inicio de sesión. Aunque no hay ninguna indicación de que se haya utilizado tu clave SSH, tu intento de inicio de sesión utilizó dos factores. Si quieres verificarlo, puedes agregar -v(para que sea más detallado) después del comando SSH.

El -vinterruptor producirá una salida como esta:

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 rsa-sha2-512 blen 279Authenticated with partial success.debug1: Authentications that can continue: password,keyboard-interactivedebug1: Next authentication method: keyboard-interactiveVerification code:

Hacia el final del resultado, verás que SSH usa tu clave SSH y luego solicita el código de verificación. Ahora puedes iniciar sesión a través de SSH con una clave SSH y una contraseña de un solo uso. Si quieres aplicar los tres tipos de autenticación, puedes seguir el siguiente paso.

Felicitaciones, ha agregado exitosamente un segundo factor al iniciar sesión de forma remota en su servidor a través de SSH. Si esto es lo que deseaba (usar su clave SSH y un token TOTP para habilitar MFA para SSH, para la mayoría de las personas esta es la configuración óptima), entonces ya está.

A continuación se presentan algunos consejos y trucos para la recuperación, uso automatizado y más.

Paso 4: Agregar un tercer factor (opcional)

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

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

Aunque enumeramos tres factores diferentes, las opciones que elegimos hasta ahora solo 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 sshdarchivo de configuración PAM:

sudo nano /etc/pam.d/sshd

Localice la línea que comentó anteriormente, #@include common-authy elimine el #carácter para descomentarla. Guarde y cierre el archivo. Ahora, reinicie SSH nuevamente:

sudo systemctl restart sshd.service

Al habilitar la opción @include common-auth, PAM solicitará una contraseña además de verificar si hay una clave SSH y solicitar un código de verificación, lo que funcionaba anteriormente. Ahora podemos usar algo que conocemos (contraseña) y dos tipos diferentes de cosas que tenemos (clave SSH y código de verificación) en dos canales diferentes (su computadora para la clave SSH y su teléfono para el token TOTP).

Paso 5: Recuperar el acceso a Google MFA (opcional)

Al igual que con cualquier sistema que protejas y protejas, te haces responsable de gestionar esa seguridad. En este caso, eso significa no perder tu clave SSH o tu clave secreta TOTP y asegurarte de tener acceso a tu aplicación TOTP. Sin embargo, a veces suceden cosas y puedes perder el control de las claves o aplicaciones que necesitas para acceder.

Perder su clave secreta TOTP

Si pierde su clave secreta TOTP, puede dividir el proceso de recuperación en un par de pasos. El primero es volver a ingresar sin saber el código de verificación y el segundo es encontrar la clave secreta o regenerarla para iniciar sesión con MFA de manera normal. Esto suele suceder si obtiene un teléfono nuevo y no transfiere sus claves secretas a una nueva aplicación de autenticación.

Para ingresar después de perder la clave secreta TOTP en un Droplet de DigitalOcean, puede usar la consola virtual desde su panel de control para iniciar sesión con su nombre de usuario y contraseña. Esto funciona porque solo protegemos su cuenta de usuario con MFA para conexiones SSH. Las conexiones que no son SSH, como un inicio de sesión de consola, no usan el módulo PAM de Google Authenticator.

Si estás en un sistema que no es Droplet, tienes dos opciones para recuperar el acceso:

1. Acceso de consola (local/no ssh) al sistema (normalmente físico o a través de algo como iDrac)
2. Tengo un usuario diferente que no tiene MFA habilitado

La segunda opción es la menos segura, ya que el objetivo de usar MFA es fortalecer todas las conexiones SSH, pero es una opción a prueba de fallos si pierde el acceso a su aplicación de autenticación MFA.

Una vez que haya iniciado sesión, hay dos formas de ayudar a obtener el secreto TOTP:

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

En el directorio de inicio de cada usuario, la clave secreta y la configuración de Google Authenticator se guardan en un ~/.google-authenticatorarchivo. La primera línea de este archivo es una clave secreta. Una forma rápida de obtener la clave es ejecutar el siguiente comando, que muestra la primera línea del google-authenticatorarchivo (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

Una vez que hayas recuperado tu clave existente, puedes escribirla manualmente en tu aplicación de autenticación o completar los detalles relevantes en la URL a continuación y hacer que Google genere un código QR para que lo escanees. Deberás agregar tu nombre de usuario, nombre de host, la clave secreta del .google-authenticatorarchivo y luego cualquier nombre que elijas para "entry-name-in-auth-app" para identificar fácilmente esta clave frente a un token TOTP diferente:

https://www.google.com/chart?chs=200x200chld=M|0cht=qrchl=otpauth://totp/username@hostname%3Fsecret%3D16-char-secret%26issuer%3Dentry-name-in-auth-app

Si existe un motivo para no usar la clave existente (por ejemplo, no poder compartir fácilmente la clave secreta con el usuario afectado de forma segura), puede eliminar el ~/.google-authenticatorarchivo directamente. Esto permitirá que el usuario vuelva a iniciar sesión utilizando solo un factor, suponiendo que no haya aplicado la autenticación multifactor eliminando la nullokopción. Luego, puede ejecutar la función google-authenticatorpara generar una nueva clave.

Pérdida de acceso a la aplicación TOTP

Si necesita iniciar sesión en su servidor pero no tiene acceso a su aplicación TOTP para obtener su código de verificación, puede iniciar sesión con los códigos de recuperación que se mostraron cuando creó su clave secreta por primera vez y que son las últimas cinco líneas del .google-authenticatorarchivo. Tenga en cuenta que estos códigos de recuperación son de un solo uso. Sin embargo, para que esto funcione, debe hacer que sus códigos de recuperación estén disponibles cuando no tenga acceso a la aplicación TOTP.

Paso 6: Cambiar la configuración de autenticación (opcional)

Si desea cambiar la configuración de MFA después de la configuración inicial, en lugar de generar una nueva configuración con la configuración actualizada, puede simplemente editar el ~/.google-authenticatorarchivo. Las opciones de este archivo aparecen de la siguiente manera:

Diseño de .google-authenticator

secret keyoptionsrecovery codes

Las opciones establecidas en este archivo tienen una línea en la sección de opciones; si respondió “no” a una opción particular durante la configuración inicial, el programa excluye la correspondiente.

Aquí hay algunos cambios que puedes realizar en este archivo:

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

Paso 7: Cómo evitar la autenticación multifactor en algunas cuentas (opcional)

Puede darse una situación en la que un solo usuario o unas pocas cuentas de servicio (es decir, cuentas utilizadas por aplicaciones, no por personas) necesiten acceso SSH sin tener habilitada la MFA. Por ejemplo, es posible que algunas aplicaciones que utilizan SSH, como algunos clientes FTP, no admitan la MFA. Si una aplicación no tiene una forma de solicitar el código de verificación, la solicitud puede quedar bloqueada hasta que se agote el tiempo de espera de la conexión SSH.

Para controlar qué factores utilizar para un usuario, puede editar el archivo /etc/pam.d/sshd.

Para permitir MFA para algunas cuentas y SSH solo para otras, asegúrese de que las siguientes configuraciones /etc/pam.d/sshdestén activas:

/etc/pam.d/sshd

# PAM configuration for the Secure Shell service# Standard Un*x authentication.#@include common-auth. . .# Standard Un*x password updating.@include common-passwordauth required pam_google_authenticator.so nullok

Aquí, @include common-authse comenta porque las contraseñas deben estar deshabilitadas. No se puede forzar la autenticación multifactor si algunas cuentas tienen la autenticación multifactor deshabilitada, por lo que se debe dejar la nullokopción en la última línea.

Después de establecer esta configuración, ejecútela google-authenticatorpara cualquier usuario que necesite MFA y no la ejecute para usuarios que solo usarán claves SSH.

Paso 8: Automatizar la configuración con la gestión de configuración (opcional)

Muchos administradores de sistemas utilizan herramientas de gestión de configuración, como Puppet, Chef o Ansible, para administrar sus sistemas. Puedes utilizar un sistema como este para instalar y configurar una clave secreta cada vez que un nuevo usuario crea una cuenta.

google-authenticatoradmite opciones de línea de comandos para configurar 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 describe en el Paso 1:

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

Las opciones a las que se hace referencia anteriormente son las siguientes:

• -t = Contador basado en tiempo
• -d = No permitir la reutilización de tokens
• -f = Forzar la escritura de la configuración en el archivo sin preguntarle al usuario
• -r = ¿Cuántos intentos para ingresar el código correcto?
• -R = Cuánto tiempo en segundos puede un usuario intentar ingresar el código correcto
• -w = ¿Cuántos códigos pueden ser válidos a la vez? (esto hace referencia a la ventana de códigos válidos de 1:30 min a 4 min)

Esto configura completamente el autenticador, lo guarda en un archivo y luego genera la clave secreta, el código QR y los códigos de recuperación. (Si agrega el indicador -q, no habrá ningún resultado). Si usa este comando de manera automática, asegúrese de que su script capture la clave secreta o los códigos de recuperación y los ponga a disposición del usuario.

Paso 9: Forzar la autenticación multifactor para todos los usuarios (opcional)

Si desea forzar la autenticación multifactor para todos los usuarios, incluso en el primer inicio de sesión, o prefiere no depender de que sus usuarios generen sus claves, existe una forma rápida de hacerlo. Puede utilizar el mismo .google-authenticatorarchivo para cada usuario, ya que no hay datos específicos de cada usuario almacenados en el archivo.

Para ello, después de crear el archivo de configuración, un usuario privilegiado debe copiar el archivo en la raíz de cada directorio de inicio y cambiar sus permisos al usuario correspondiente. También puede copiar el archivo en /etc/skel/, lo que copiará automáticamente el archivo en el directorio de inicio de cada nuevo usuario al momento de su creación.

Advertencia: Esto puede suponer un riesgo de seguridad porque todos comparten el mismo segundo factor. Esto significa que, si se filtra, es como si cada usuario tuviera un solo factor. Ten esto en cuenta si quieres utilizar este enfoque.

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

1. Crea un token TOTP,
2. Les solicita que descarguen la aplicación Google Authenticator y escaneen el código QR que se mostrará, y
3. Ejecuta la google-authenticatoraplicación para ellos después de verificar si el .google-authenticatorarchivo ya existe.

Para asegurarse de que el script se ejecute cuando un usuario inicia sesión, puede nombrarlo .bash_loginy colocarlo en la raíz de su directorio de inicio.

Conclusión

En este tutorial, agregó dos factores (una clave SSH + un token MFA) a través de dos canales (su computadora + su teléfono) a su servidor. Hizo que fuera muy difícil para un agente externo ingresar a su máquina por la fuerza a través de SSH y aumentó enormemente la seguridad de su máquina.

Y recuerda, si buscas más orientación sobre cómo proteger las conexiones SSH, consulta estos tutoriales sobre cómo proteger OpenSSH y cómo proteger el cliente OpenSSH.