¿Qué seguridad SSH es más fuerte? 2 Factor o clave pública

23

Para la autenticación SSH, ¿cuál es más segura?
Autenticación de 2 factores mediante un token USB / Google Authenticator (basado en el tiempo)
O
Clave pública / privada con contraseña

¿O podrían usarse ambos al mismo tiempo? Si es posible, ¿existen inconvenientes en el uso de una autenticación multifactor como esta?

También, ¿podría alguien publicar un ejemplo o un enlace para mostrar cómo podría implementar tanto la clave pública como Factor 2 juntos si es posible? ¡Gracias!

    
pregunta Lelouch Lamperouge 19.12.2012 - 04:32
fuente

3 respuestas

25

Este no es un problema "uno es mejor que el otro". Ambos aumentan la carga de un atacante para entrar en tu sistema:

  • Usar (y aplicar) las teclas aumenta la "calidad de la contraseña" ("mypassword123" frente a "long_binary_asymetric_keypair_here"). Los humanos son muy malos para recordar frases de contraseña largas con buena entropía.

  • El uso de 2Factor auth garantiza que un atacante tendría que tener 2 propiedades bajo control: un mecanismo de contraseña (contraseñas habituales, PK) y otra que no está (generalmente) en la misma ubicación física que la primera . Con el modo 2Factor, el sistema contra el que intenta autentificarse lo desafiará por segunda vez después de haber tenido éxito en el primer desafío. Pero si ambos desafíos son tontos / simples / fáciles de romper, todo el factor 2 no tiene sentido.

Por lo tanto, ambos mecanismos se complementan entre sí.

Buen tutorial sobre la parte 2Factor:

enlace

Combine eso con cualquier otro tutorial que explique cómo usar las teclas ssh (y hay LOTES en las redes). El flujo de la autenticación es el siguiente:

  1. El cliente activa el mecanismo para desbloquear la clave ssh privada (contraseña) en su máquina
  2. Contactos del cliente Servidor para garantizar la coincidencia de claves públicas y privadas. A partir de aquí, en el servidor ssh, básicamente, ya no participamos en la autenticación.
  3. El servidor enruta al cliente al segundo desafío
  4. El cliente responde correctamente al segundo desafío
  5. El cliente obtiene acceso al shell en el servidor
respondido por el akira 19.12.2012 - 07:40
fuente
5

Además de la otra respuesta, también puedo agregar que la autenticación basada en clave de publicación puede ser un factor doble en sí mismo si su clave privada está en una tarjeta inteligente (por ejemplo, la tarjeta OpenPGP). En mi experiencia, agregar el autenticador de google en el nivel ssh hace que la vida del administrador sea demasiado incómoda: tienes que ingresar el código cada vez que necesites scp. Mi enfoque preferido es la clave ssh en la tarjeta OpenPGP y el autenticador de google al hacer sudo.

Estos dos enlaces te serán útiles:

  1. Configuración de la tarjeta OpenPGP para manejar su autenticación ssh .
  2. Configuración de la infraestructura centralizada de autenticador de google .
respondido por el mricon 19.12.2012 - 16:00
fuente
-1

La compensación entre la dificultad que supone mantener una autenticación de dos factores o de clave pública y el grado de seguridad que cada uno proporciona depende de cómo / quién la esté utilizando. Si el uso se encuentra entre un número limitado de administradores de sistemas de servidores que están familiarizados con la seguridad, de modo que no contaminen ninguno de los procesos al permitir que el acceso a su acceso (PC, computadora portátil, dispositivo móvil) se vea comprometido, entonces cualquiera de estos puede probar seguro.

Los diversos informes, artículos y blogs que he leído indican que el medio más frecuente para vencer la autenticación de dos factores o el cifrado de clave pública es obtener acceso al acceso inseguro del cliente: una PC que se encuentra en o sin la protección de contraseña que se usa para obtener acceso a la raíz (u otras áreas). Las contraseñas se pueden almacenar en el dispositivo en un administrador de contraseñas o se ingresan automáticamente mediante un navegador web o se anotan en un papel en un escritorio.

Otro medio de compromiso es cuando las contraseñas y las claves no se cambian después de que un empleado / asociado se retire.

La mayoría de los ataques de fuerza bruta, fuerza bruta distribuida y otros ataques externos son efectivamente frustrados por los métodos de autenticación de dos factores o de clave pública. Esto se mejora si se usan contraseñas razonablemente difíciles y se requiere el acceso de clave pública cifrada con contraseña (una forma de autenticación de dos factores en sí).

Se pueden usar otros métodos, como el uso de un puerto SSH no estándar, aunque existe un argumento válido en contra de ese método. Otro método es el uso de puertos rotativos / aleatorios no estándar o el uso de la función Port-knocking en la que tres o más puertos deben ser golpeados / tocados secuencialmente antes de otorgar acceso a un SSH seleccionado u otros puertos. Los puertos de desactivación de puertos también pueden rotarse periódicamente.

Los últimos métodos no suelen estar justificados porque es mucho más probable que se produzcan infracciones de seguridad dentro de una organización que ha implementado métodos de autenticación de dos factores y / o de clave pública. Si la naturaleza del trabajo / los servidores requiere los niveles más altos de seguridad, las capas adicionales de seguridad pueden tener sentido.

Volví a ver la película "The Imitation Game" 2014 anoche. Se trata del craqueo de la máquina de encriptación Nazi Enigma que requería determinar entre algunos cientos de millones de posibles selecciones manuales. El código fue roto por la máquina de computación electromecánica de Brit Alen Turing solo después de que se encontraron con términos repetidos en las comunicaciones que podían adivinar "¡Heil Hitler!" y otros términos en los informes meteorológicos diarios. Esto explica en gran medida la seguridad de los servidores Linux y otros sistemas seguros: solo son tan seguros como las prácticas de las personas que los usan.

    
respondido por el Cloud4G 07.09.2017 - 20:45
fuente

Lea otras preguntas en las etiquetas