¿Puede la autenticación con clave pública sin contraseña ssh estar bien si se combina con una VPN?

Esta es una típica pregunta de defensa en profundidad. ¿Por qué necesito X si ya tengo Y y Z en su lugar?

La respuesta común es que su seguridad es generalmente tan buena como su enlace más débil. En su caso, su único mecanismo de seguridad parece ser su VPN. Este es tu eslabón más fuerte y más débil. En su opinión, es suficiente protección y no es necesaria ninguna protección adicional.

Quizás tienes razón. Podría ser lo suficientemente bueno. En casa, solo tengo una cerradura en mi puerta. Sé que dos cerraduras serían más fuertes, pero el costo / la molestia de instalar otra cerradura y el uso de dos llaves no vale la pena. No tengo mucho que valga la pena robar de todos modos. Pero si mi bloqueo o su VPN se ven comprometidos, entonces nos quedamos con poca o ninguna protección. La seguridad de la VPN puede verse comprometida en una variedad de escenarios, algunos de ellos son tan triviales como alguien que accidentalmente realiza un cambio de configuración estúpido que deja abierta su VPN, por ejemplo. Además, incluso si la VPN es 100% impermeable, un empleado puede decidir que es una buena idea conectar un enrutador inalámbrico a su red para que puedan usar su iPhone con mayor facilidad, dejando una oportunidad de ingresar a su red sin la VPN. Por supuesto, depende de su organización, la configuración, etc. El principio básico es el mismo.

Debería considerar la fortaleza / debilidad de su protección contra el costo / valor de sus datos. Luego agregue el 'costo residual' de agregar y administrar otra capa de protección y vea si vale la pena para usted. Instalar otra puerta de enlace de VPN, por lo que tiene dos VPN, puede ser costoso e ineficiente. Sin embargo, agregar contraseñas a sus claves privadas ssh puede ser lo suficientemente fácil y barato como para que valga la pena.

Hay dos formas principales para que un atacante obtenga el archivo de clave privada:

• Al comprometer la máquina cliente, en cuyo caso el atacante generalmente también puede obtener la contraseña.
• Comprometiendo una copia de seguridad de la máquina cliente, o robando esa máquina.

Si está comparando la autenticación de clave privada con la autenticación de contraseña, solo el segundo caso es relevante. Una contraseña segura en el archivo de clave privada es de hecho necesaria para la seguridad en el segundo caso.

Puede reducir el riesgo excluyendo el archivo de clave privada de las copias de seguridad, pero parece que tiene poco control sobre las máquinas cliente, y el robo siempre es una posibilidad. También puede reducir el riesgo si tiene una manera de desactivar una clave rápidamente. Si una penetración en su red requiere una conexión VPN además de la clave SSH, esto aumenta la ventana de tiempo para desactivar la clave antes de que se pueda hacer cualquier daño.

Tenga en cuenta que una contraseña tampoco es una panacea. Los clientes de SSH tienden a hacer que la autenticación de contraseña sea difícil de automatizar, pero los usuarios lo suficientemente molestos escribirán la contraseña en un archivo de texto sin formato de todos modos, e incluso pueden exponerla en un archivo de configuración o script en algún lugar. El uso de un archivo de clave privada tiene la ventaja de que la información confidencial se concentra en un archivo que los usuarios no tienden a copiar.

Otra consideración que es ventajosa para las claves privadas es que tienden a ser más fáciles de revocar, desde un punto de vista social. Nunca se agradece decirle a un usuario que tiene que cambiar su contraseña, y no tiene forma de asegurarse de que no cambiará de Password123 a Password456 . (A menos que fuerce las contraseñas, en cuyo caso sabrá que las han escrito en alguna parte).

Además, si la VPN tiene la misma contraseña que SSH, para la mayoría de los intentos, SSH no realiza ninguna autenticación adicional. Por lo tanto, SSH con autenticación de clave representa una capa adicional de seguridad en este escenario (independientemente de si la clave está bien protegida), mientras que SSH con la misma contraseña no lo hace. Si la alternativa es que la contraseña lo lleve a través de la puerta trasera y la puerta frontal, tener la puerta trasera protegida por un mecanismo diferente es una ventaja.

Su pregunta gira alrededor del almacenamiento de claves privadas, no del mecanismo de autenticación ssh.

Entonces, a las respuestas:

1. Sí, el mecanismo y el protocolo de clave pública / privada ssh parece ser seguro.
2. Sí, la clave privada se debe cifrar mediante una frase de contraseña compleja (especialmente importante si se almacena en la máquina cliente).
3. Esto no detiene todos los ataques, solo algunos.
4. Por lo tanto, se requieren defensas en capas.
5. Este no es un tema especialmente importante con respecto a los otros problemas que probablemente se ignorarán en la arquitectura de seguridad (y no, no trabajo en el mismo lugar donde lo hace, solo lo extrapolando).

En primer lugar, las claves SSH son categóricamente mejores que las contraseñas ssh:

• No se puede razonablemente con fuerza bruta adivinar una clave SSH. Con las contraseñas, puede obtener un golpe de suerte adivinando "changeme" o "12345" o "nicole". Las claves, por otro lado, consisten en 2048 bits pseudoaleatorios. Ni siquiera vale la pena intentarlo.

• Las claves SSH utilizan criptografía asimétrica para evitar la revelación de secretos . Si se conecta usando la autenticación de contraseña a un servidor SSH malicioso, les revelará su nombre de usuario y contraseña, que podrían utilizar para todo tipo de ataques. Realizar un ataque contra alguien que usa autenticación basada en clave es mucho más difícil. ( Ni siquiera estoy seguro de que sea posible; ¿hay algún ejemplo de esto?)

• El acceso a las claves SSH se puede revocar o ampliar por usuario en lugar de por cuenta.

• Las claves SSH se pueden usar para implementar seguridad adicional o restricciones por usuario más allá de lo que está disponible a través de contraseñas.

• Puede usar la misma clave para acceder a múltiples servidores sin una reducción significativa en la seguridad.

• Las claves SSH te permiten hacer cosas realmente geniales como reenvío de agente , que es absolutamente la cosa más genial de la historia (no me quejes de las implicaciones de seguridad de los servidores hostiles; es increíble. La-la-la-la no escucha).

Con respecto a las claves de cliente cifradas o no cifradas; Eso es una cuestión de gusto personal y política. Si no hay ninguna posibilidad de que su clave privada se filtre, entonces el descifrado está bien. Pero realmente, con la clave agentes , no hay razón para no cifrarlo , y la seguridad adicional es bienvenida.

Finalmente, y es probable que esto sea relevante aquí, SSH con autenticación basada en clave es más seguro que la mayoría de los sistemas VPN , específicamente porque las VPN populares generalmente usan autenticación basada en contraseña y no tiene protección incorporada contra ataques de hombre en el medio. ^{Nota: algunas VPN utilizan autenticación bidireccional basada en clave. Esos son al menos tan seguros como SSH.}

Entonces, el hecho de que posiblemente estés usando una mejor seguridad dentro de la VPN que la que usas para construir la VPN en sí es sutilmente irónico. Y su defensa de la autenticación basada en clave basada en la seguridad de la VPN incluida es aún más.

Nota:
Gran parte de lo anterior está orientado en torno a la idea de usar claves ssh para sesiones interactivas en lugar de sistemas automatizados, como copias de seguridad programadas, etc. Pero la comparación con otras tecnologías sigue sin tener en cuenta. Cualquier reducción en la seguridad con un sistema de no intervención (sin contraseña) con respecto a la seguridad de la clave se aplica tanto al almacenamiento de su contraseña o clave de VPN en el sistema como al almacenamiento de su clave SSH sin cifrar. El almacenamiento de credenciales nunca es seguro, pero una clave SSH almacenada siempre es más segura que una contraseña almacenada debido a la tecnología asimétrica y la resistencia al ataque basado en la red.