¿Hacer cumplir las contraseñas clave SSH?


9

Estoy buscando eliminar inicios de sesión basados ​​en contraseña para SSH. Sin embargo, no quiero permitir claves ssh sin contraseña, ya que eso sería aún peor.

¿Cómo puedo asegurarme de que solo se puedan conectar las claves SSH que tienen contraseñas?

Si esto no se puede hacer, ¿existen alternativas, como administrar centralmente la generación de claves SSH y evitar que los usuarios generen y / o usen sus propias claves? Algo como PKI, supongo.

Respuestas:


20

La frase de contraseña que se puede establecer en la clave privada no está relacionada con el servidor SSH o la conexión con él. Establecer una frase de contraseña para la clave privada es simplemente una medida de seguridad que el propietario de la clave puede tomar para evitar que un tercero acceda a su shell remoto en caso de que la clave privada sea robada.

Lamentablemente, no puede obligar a los usuarios a proteger sus claves privadas con frases de contraseña. A veces, se requieren claves privadas sin protección para automatizar el acceso al servidor SSH remoto. Un buen hábito que recomiendo encarecidamente para estos casos es aconsejar a los usuarios que hagan hash el archivo known_hosts (almacenado en ~ / .ssh / known_hosts ), que mantiene información sobre los hosts remotos a los que se conecta el usuario, utilizando el siguiente comando:

ssh-keygen -H -f ~/.ssh/known_hosts

De esta manera, incluso si un tercero obtuviera acceso a una clave privada desprotegida, sería extremadamente difícil averiguar para qué hosts remotos es válida esta clave. Por supuesto, borrar el historial del shell es obligatorio para que esta técnica tenga algún valor.

Además, otra cosa que siempre debe tener en cuenta es no permitir que root inicie sesión de forma remota agregando lo siguiente en la configuración de su servidor SSH (sshd_config):

PermitRootLogin no

Por otro lado, si desea evitar que los usuarios usen claves para autenticarse, pero en lugar de usar contraseñas, debe agregar lo siguiente a su sshd_config :

PasswordAuthentication yes
PubkeyAuthentication no

8

No es posible.

Los usuarios pueden hacer cualquier cosa con sus archivos de clave, convertirlos en sin contraseña, incluso si lo generó, por ejemplo.


3

No puedes Una vez que el usuario tiene los datos clave en su poder, no puede evitar que eliminen la frase de contraseña. Deberá buscar otras formas de realizar su autenticación.


2

Para obtener el control de las claves de usuario, todas las claves deben moverse a un directorio propiedad de la raíz donde las claves sean legibles pero el usuario final no las pueda modificar. Esto se puede hacer actualizando sshd_config.

Una vez que los archivos de claves están en una ubicación controlada, necesitará una interfaz de administración para actualizar (y aplicar la política de contraseñas) seguido de la distribución de las claves a los hosts requeridos. Puedes rodar uno tú mismo o echar un vistazo a productos como FoxT / Tectia, etc.


... que rompe los beneficios de la clave pública
Patwie

0

Una mitigación sería usar el complemento del módulo PAM de Google autenticador. Generalmente disponible dentro de los paquetes oficiales.

Esto hará que 2FA esté disponible a través de un código de 6 dígitos en su teléfono inteligente.

Instrucciones aquí: Cómo configurar la autenticación multifactor para SSH en Ubuntu 16.04


1
Debe tener en cuenta que esto no responde directamente a la pregunta, sino que es una (buena) alternativa.
ceejayoz

1
@ceejayoz Tienes razón. Agregué "Una mitigación sería usar ..." al comienzo de la respuesta en este momento para dejar en claro que es una alternativa.
Albahaca

-1

SIMPLE, simplemente extiende el protocolo SSH para que el cliente SSH o el agente SSH informe / establezca un indicador para decir si la clave privada original estaba encriptada o no (quizás el lado del servidor puede incluso plantear una consulta), ya que el lado del cliente tiene visibilidad de la clave privada e incluso solicita la frase de contraseña cuando la clave está encriptada.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.