SSH: autenticación de dos factores

30

Actualmente tengo un Ubuntu Server 12.04 con OpenSSH junto con Samba y algunos otros servicios. En este momento tengo configurada la autenticación de clave pública, y me pregunto si es posible configurar la autenticación de dos factores. He estado buscando en Google Authenticator que actualmente uso con mi cuenta de Gmail.

He encontrado un módulo PAM que parece que será compatible, sin embargo, parece que estás obligado a usar una contraseña y el código generado.

Me pregunto si hay una manera de usar la aplicación Google Authenticator (o algo similar) junto con mi clave pública para autenticarme en mi servidor SSH.

— Burro de hormigón
fuente

La mayoría de los comentarios parecen ser informes de errores que mencionan que es imposible usar PAM y la autenticación de clave pública con OpenSSH. También encontré partes que mencionan que es redundante ya que estoy usando una frase de paso con mi clave. Con todas las soluciones que aparentemente solo permiten Google Authenticator y una contraseña, no una clave pública. Podría estar perdiéndolo por completo, pero simplemente no veo cómo implementar ambos.

— Concrete Donkey

No estoy seguro de por qué esto tiene un -1, esta es una pregunta muy interesante y también me gustaría saber la respuesta (no es probable que la use, pero aun así, es bueno esconderla en los bancos de conocimiento)

— Mark Henderson

@Pierre ¿Estás tratando de requerir tanto la autenticación de clave pública, y una OTP Google?

— mgorven

@mgorven Sí, estaba tratando de configurar tanto la clave pública como la OTP de Google. He escuchado a algunas personas decir que es suficiente ya que tener una frase de contraseña en la clave cuenta como dos factores, pero me preocupa que el malware robe la clave no cifrada de la memoria. Prefiero tener dos dispositivos completamente separados utilizados para la autenticación, estoy un poco paranoico.

— Concrete Donkey

Está destinado a implementarse oficialmente en 6.2: bugzilla.mindrot.org/show_bug.cgi?id=983#c59

— Tobias Kienzler

8

Red Hat ha agregado un parche a OpenSSH en RHEL (y, por lo tanto, CentOS) 6.3 para requerir múltiples mecanismos de autenticación, por lo que puede hacer algo como esto:

RequiredAuthentications2 publickey,keyboard-interactive

Consulte las notas de la versión para obtener muchos más detalles.

Desafortunadamente, esta característica no parece estar en OpenSSH aguas arriba ni en Ubuntu 12.04, así que a menos que desee encontrar el parche y recompilar OpenSSH, me temo que no tiene suerte.

— mgorven
fuente

Debo decir que aprecio el esfuerzo que hizo para encontrarme una respuesta, ciertamente intenté revisar algunas páginas de resultados de Google, pero todo implicaba que lo que mencionó tenía que usar una contraseña y un OTP solamente. Probablemente crearé una VM CentOS para jugar con la función.

— Concrete Donkey

@Pierre No es que mucho esfuerzo, que sabía de esta función antes ;-)

— mgorven

He encontrado el error correspondiente y algunas notas más . El error incluye el parche como un archivo adjunto.

— Robie Basak

Y aquí hay un error de openssh ascendente . Parece que la funcionalidad similar estará próximamente en openssh.

— Robie Basak

openssh 6.2 ha aterrizado en la versión de desarrollo de Ubuntu, así que salvo para cualquier desastre, este soporte estará en la versión 13.10 esperada. Utiliza el flujo ascendente AuthenticationMethodspara especificar múltiples métodos requeridos, de modo que puede requerir una clave ssh y PAM, con PAM haciendo el final del Autenticador de Google.

— Robie Basak

8

Estás buscando Duo Security

— Ajith
fuente

1

Esta. Sí. ¡Amo esta cosa!

— LVLAaron

Definitivamente: Duo es fácil de configurar para Unix / Linux (enlace en respuesta), OpenVPN ( duosecurity.com/docs/openvpn_as ) o cualquier servicio de dos factores basado en OATH TOTP, o la gestión de contraseñas de LastPass. Cualquier servicio que sea compatible con Google Authenticator (que usa TOTP) se puede usar con la aplicación móvil de Duo o un token de hardware compatible con TOTP.

— RichVel

5

Puede usar tanto el módulo PAM de Google Authenticator como las claves públicas, pero solo se usará uno a la vez para una autenticación determinada. Es decir, si un usuario inicia sesión con una clave pública autorizada, no se requerirá ningún token.

O, para decirlo de otra manera: los tokens solo son necesarios para las autenticaciones de contraseña, no las claves SSH.

Por cierto, esta limitación no proviene del módulo Google Authenticator, sino de SSH, que solo implementa la autenticación de dos factores (vía ChallengeResponseAuthentication) para PAM, pero no llama a PAM cuando se proporciona una clave pública válida.

— Phaphink
fuente

Esto era correcto, pero ahora ha cambiado. openssh 6.2 agrega un AuthenticationMethodsparámetro de configuración que puede voltear esto. Ahora puedes requerir ambos.

— Robie Basak

3

Esta pregunta es de 2012. Desde entonces, SSH ha cambiado y se ha implementado el protocolo SSH2.

En versiones más recientes de SSH (> = 6.2), man sshd_config menciona:

AuthenticationMethods
       Specifies the authentication methods that must be successfully completed for a user to be
       granted access.  This option must be followed by one or more comma-separated lists of
       authentication method names.  Successful authentication requires completion of every method
       in at least one of these lists.

       For example, an argument of ``publickey,password publickey,keyboard-interactive'' would
       require the user to complete public key authentication, followed by either password or key-
       board interactive authentication.  Only methods that are next in one or more lists are
       offered at each stage, so for this example, it would not be possible to attempt password or
       keyboard-interactive authentication before public key.

       This option is only available for SSH protocol 2 and will yield a fatal error if enabled if
       protocol 1 is also enabled.  Note that each authentication method listed should also be
       explicitly enabled in the configuration.  The default is not to require multiple authentica-
       tion; successful completion of a single authentication method is sufficient.

Esta página http://lwn.net/Articles/544640/ también menciona la posibilidad de usar una clave pública y una autenticación PAM al mismo tiempo.

— liquidez
fuente

2

Sé que esta pregunta es un poco obsoleta, pero por el bien de las futuras personas (incluido yo mismo) que están buscando una solución, también se habla de usar la opción ForceCommand en el archivo sshd_config para ejecutar un script que luego realiza la autenticación. Hay un script de ejemplo que aquí se puede modificar un poco para sus necesidades, aunque en ese ejemplo que llama desde el archivo authorized_keys en vez de hacerlo en todo el sistema con ForceCommand de sshd_config.

— Asombroso
fuente

1

Obtenga una YubiKey y siga esta guía http://berrange.com/posts/2011/12/18/multi-factor-ssh-authentication-using-yubikey-and-ssh-public-keys-together/

AFAIK, esta es la mejor manera de implementar Yubikey en su servidor para acceso SSH. La guía anterior le permite utilizar la clave pública + yubikey, mientras que si utiliza la guía oficial ( http://code.google.com/p/yubico-pam/wiki/YubikeyAndSSHViaPAM ), no funciona con public- llave.

Saludos, Vip

— vagarwal
fuente

0

Si configura una frase de contraseña en su clave privada, entonces ya tiene autenticación de dos factores. Para iniciar sesión, las personas necesitarían:

algo que tienes: tu clave privada
algo que sabes: la frase de contraseña de tu clave privada

— Bart B
fuente

3

Dos contraseñas no hacen autenticación de dos factores. La clave en sí misma no es un "algo que tienes" válido porque no es una cosa, solo una información. La cosa debe ser no copiable, o al menos no trivialmente copiable, para ser utilizada como factor de autenticación.

— MadHatter apoya a Monica el

2

No estoy de acuerdo por completo. Si las claves y los certificados no son "algo que tienes", ¿qué son? Definitivamente no son "algo que sabes" (¿tienes la costumbre de aprender de tu clave SSH?), Y absolutamente no son "algo que eres". Esas son las únicas tres opciones, por lo que, por un proceso de eliminación, sin duda son "algo que tienes".

— Bart B

1

Estoy de acuerdo; para mí, el problema está en la máxima (algo que tienes | sabes | son). La idea de la autenticación de dos factores es requerir miembros de dos clases con diferentes propiedades; algo que sabes es fácil de llevar, pero alguien más puede saberlo al mismo tiempo que tú lo sabes; entonces agregamos un segundo factor diferente. El "algo que tienes" solo es diferente si es incopiable (o difícil de copiar). De lo contrario, seguro, no es algo que conoces, pero no es cualitativamente diferente de algo que sabes , porque alguien más puede tenerlo al mismo tiempo que tú.

— MadHatter apoya a Monica el

2

Definitivamente estoy de acuerdo en que un par de claves protegido por contraseña es una gran mejora en la seguridad sobre el nombre de usuario directo + contraseña. Lamentablemente, no estoy de acuerdo en que ese par cuente como un factor doble, y probablemente tendremos que estar de acuerdo en no estar de acuerdo con eso.

— MadHatter apoya a Monica el

3

Si tiene una clave privada cifrada con frase de contraseña, solo demuestra una cosa al servidor: que su cliente conoce la clave privada. No prueba al servidor que conoces tu frase de contraseña; el servidor ni siquiera sabe acerca de la existencia de su frase de contraseña. Por lo tanto, es solo "algo que sabes" (ya que tu cliente lo sabe) y solo un factor. Si un atacante se apodera de una sola cosa (su clave privada), entonces está comprometido. Ese es un factor. Argumentar que su frase de contraseña y clave privada cuentan como dos factores es solo un ejercicio de sofistería. Lo que cuenta es lo que sucede en el cable.

— Robie Basak