¿Deshabilitando la autenticación a través de las claves DSA en OpenSSH?

Question

¿Deshabilitando la autenticación a través de las claves DSA en OpenSSH?

#1 de Thomas Pornin (12 votos)
#2 de DougC (4 votos)
#3 de Max Sherman (-1 votos)

8

¿Cómo puedo deshabilitar la autenticación DSA y ECDSA en mi servidor con OpenSSH 5.9? Revisar el material de documentación y realizar una búsqueda en la web no produjo ningún resultado, solo un informe de error anterior para el paquete Debian aquí (y aquellos vinculados en la parte inferior de ese error) pero no hay conclusión.

Suponiendo que no es posible desactivar esos dos métodos dentro de /etc/ssh/sshd_config , ¿es suficiente? (Sintaxis de Bash): for i in /etc/ssh/ssh_host_{ecdsa,dsa}_key*; do echo -n ""|sudo tee "$i"; sudo chattr +i "$i"; done (a continuación con saltos de línea para facilitar la lectura):

for i in /etc/ssh/ssh_host_{ecdsa,dsa}_key*;
do
  echo -n ""|sudo tee "$i"
  sudo chattr +i "$i"
done

I.e. para invalidar las claves de host y luego hacerlas inmutables, por lo que no es posible realizar intentos de sshd para regenerar las claves de host de DSA y ECDSA.

La razón por la que quiero deshabilitar DSA es porque hay fuentes que reclaman debilidades en el algoritmo que se han abusado activamente, como Wikipedia y este sitio web . Cavé un poco más y me parece creíble. La ventaja más pragmática y menos teórica es la velocidad de verificación de RSA sobre DSA.

TL; DR: ¿es posible configurar sshd desde OpenSSH en sshd_config para deshabilitar ECDSA y DSA? De lo contrario, ¿se puede evitar la autenticación exitosa con esos métodos configurando los archivos de la clave del host como inmutables?

authentication ssh configuration

pregunta 0xC0000022L 11.01.2013 - 18:41

fuente

3 respuestas

4

EDITAR: Como se indica en el comentario de dave_thompson_085, esta solución requiere la versión 7.0 de OpenSSH o una versión más reciente, y no funcionará para OpenSSH 5.9 como lo solicita el póster original. Se deja como referencia para los usuarios de OpenSSH 7.0 y más nuevos con los mismos objetivos.

Según la página de manual actual de OpenBSD sshd_config (5), es posible restringir el uso de DSA / ECDSA excluyéndolo de HostKeyAlgorithms

enlace

En la sección HostKey :

Tenga en cuenta que sshd (8) rechazará el uso de un archivo si es accesible para grupos / usuarios y que la opción HostKeyAlgorithms restringe cuál de las claves realmente usa sshd (8).

Entonces, al especificar otros algoritmos (puede obtener una lista usando "ssh -Q key") puede eliminar su uso. Por ejemplo.

HostKeyAlgorithms [email protected],[email protected],ssh-ed25519,ssh-rsa

Debo tener en cuenta que la cita anterior no se encuentra en todas las versiones anteriores de la página del manual, por lo que es posible que esto no funcione en su versión.

respondido por el DougC 11.05.2017 - 22:36

fuente

-1

Parece que hay una opción que es legal para sshd_config:

DSAAuthentication no

hace la mitad de lo que estás buscando. No sé si hay un equivalente para ECDSA. Encontré esa opción aquí .

respondido por el Max Sherman 11.01.2013 - 18:55

fuente

Lea otras preguntas en las etiquetas authentication ssh configuration

Seguridad del correo electrónico [duplicado] ¿Deben los sistemas de SMS advertir a los usuarios de posibles ataques de suplantación de identidad?

score 12 · Accepted Answer

Primero cuestionaré sus razones para desactivar DSA y ECDSA:

No hay debilidad conocida en ninguno de los dos que los hace "más vulnerables" que el simple RSA.
Ha habido implementaciones de DSA o ECDSA mal hechas; sin embargo, también ha habido implementaciones de RSA mal hechas, y en algunos casos resultó en una pérdida de clave RSA (por ejemplo, ataque de Bleichenbacher ).
Mientras que (EC) DSA requiere una fuente nueva de buena aleatoriedad, la generación de claves DSA (EC) es mucho más fácil de realizar que la generación de claves RSA. Las claves RSA mal generadas aparecen para que suceda mucho en la práctica . Este artículo incluye una cita interesante sobre Arjen Lenstra (en quien personalmente confiaría mucho más en cuestiones de seguridad que casi todos los demás):

Dijo que otras fórmulas como Diffie-Hellman y DSA no son tan vulnerables porque la duplicación de un factor hace que el titular de una clave sea vulnerable solo a la persona que posee el certificado correspondiente. "Si tienes una colisión, solo afectas a otra persona. Puedes lastimarla y te puede lastimar a ti, pero no lo has hecho público para todos y su madre".

Si no tiene calidad aleatoria en su servidor, de todos modos está condenado.
En cuanto al rendimiento , la verificación de firma DSA no es más cara que la Intercambio de claves Diffie-Hellman que tiene lugar de todos modos al comienzo de cada conexión. Estamos hablando de alrededor de un milisegundo aquí en una PC básica; Sugiero hacer medidas reales antes de declarar a algunos algoritmos criptográficos culpables de lentitud. Y ECDSA será típicamente diez veces más rápido que DSA.

Dicho esto, si realmente está intentando desactivar el soporte DSA (EC) en su servidor SSH, le sugiero que vuelva a compilar OpenSSH ( comenzando con la fuente de la versión empaquetada en su sistema operativo específico) después de desactivar DSA y ECDSA en ella (busque key.c , función key_verify() : es suficiente para modificarla de modo que la verificación DSA (EC) siempre falle, y usted nunca aceptará ninguna autenticación basada en DSA (EC)).

(No parece haber una opción para desactivar selectivamente el soporte para algoritmos asimétricos. Se considerará que su servidor permite DSA implícitamente si tiene una clave DSA, lo que de alguna manera tiene sentido. En cuanto a la autenticación del cliente, en el modelo SSH , esta es una decisión que depende de cada usuario , que decida incluir o no incluir su clave pública RSA / DSA / ECDSA en su .ssh/authorized_keys . Esto podría ser un caso para la educación del usuario, después de todos.)