Quel est le besoin actuel de clés d'hôte ssh dsa?

Quand j'ai commencé à m'occuper des serveurs * nix, les serveurs openssh étaient fournis avec les clés d'hôte dsa et rsa, les clients openssh préférant la clé rsa. De nos jours, les serveurs openssh ont des clés d'hôte dsa, rsa ainsi que ecdsa, les clients openssh préférant la clé d'hôte ecdsa.

Dans quelle mesure ai-je encore besoin / souhaite-t-il que openssh soit configuré pour fournir des clés d'hôte dsa?

Je me demande surtout en ce qui concerne les implémentations client non-openssh.

Je ne peux pas penser à quelque chose de largement utilisé qui ne prend pas en charge au moins RSA, et vraiment si vous utilisez un émulateur de terminal sur Windows (par exemple) qui ne prend en charge que DSA, vous devez cesser de l'utiliser et télécharger du mastic, ou le mettre à jour.

L'option est là pour assurer la compatibilité. Cependant, cela ajoute également à votre surface de sécurité; un attaquant pourrait affaiblir votre cryptographie en convaincant un client de ne déclarer que la prise en charge de DSA. Ce scénario est plutôt tiré par les cheveux. Si cela vous concerne, vous devez désactiver DSA.

Le seul scénario que j'imagine qui entraînerait probablement un compromis sérieux serait si l'un de vos utilisateurs utilisait une paire de clés DSA sur un ordinateur non fiable ou compromis qui négociait toujours DSA et générait des valeurs éphémères en double pour créer des signatures DSA; le résultat serait que la clé de l'utilisateur pourrait être compromise, mais il ne semble pas que ce soit le chemin de moindre résistance pour un attaquant. À moins que votre système ne soit utilisé par des espions internationaux, vous n'avez probablement pas à vous en préoccuper. Consultez cette question sur l'un de nos sites partenaires : /security//q/29262/12223 .

Il n'y a pas vraiment de moyen direct de désactiver DSA. Le bogue Debian 528046 le propose et fournit un correctif (pour une option PubKeyTypes), et a rencontré le support, mais n'a pas été mis à exécution depuis 2009, sans aucune preuve de quoi que ce soit en amont.

Votre réponse se trouve probablement ici:

/security/5096/rsa-vs-dsa-for-ssh-authentication-keys

La plupart des recommandations concernent les clés RSA pour diverses raisons, donc les clés DSA sont largement là pour la compatibilité descendante. DSA a été introduit lors de la sortie de SSH2, car à l'époque RSA était encore breveté et DSA était plus ouvert. Cela a changé depuis.

Pour toutes ces raisons, les clés DSA sont pratiquement inutiles. Ils fonctionneront et ssh-keygen les produira même si vous le demandez, mais quelqu'un doit le demander spécifiquement et cela signifie qu'il peut utiliser RSA si vous le forcez. Pour autant que je sache, rien n'a été fait uniquement par DSA. Les clés DSA sont autorisées à interdire.

La seule raison pour laquelle je peux proposer une sécurité est que si la factorisation principale tombe mais que le journal discret ne tombe pas, alors RSA tombe mais DSA reste. Dans ce cas, vous demanderiez comment désactiver RSA. Si le log discret tombe, le RSA et le DSA tombent. Cependant, si votre ssh nécessite toujours exactement 1024 bits pour DSA, corrigez cela maintenant.