GuiGui's Show

Résumé : « ssh-rsa », l'algorithme de signature et de vérification de la clé publique de type RSA d'un serveur SSH, est déprécié à cause des récentes attaques pratiques contre SHA-1, l'algorithme d'intégrité utilisé en interne. Il sera désactivé dans une version future d'OpenSSH. Il est temps de le désactiver au profit de rsa-sha2-* qui utilisent SHA-256 ou SHA-512 : HostKeyAlgorithms -ssh-rsa dans sshd_config. Attention : ça casse les vieux bouzins qui se connectent au serveur genre un OpenWRT Backfire.

Pour valider mes nouvelles configurations TLS renforcées, j'ai utilisé le testeur TLS/SSH Cryptcheck. Quand j'ai testé mes serveurs SSH, tout était OK… ou presque :

• Échange de clé de session EDH (diffie-hellman-group-exchange-sha256). Oui, je pourrais utiliser EECDH, mais je préfère EDH car je comprends le problème mathématiquee isoluble (en un temps fini) sous-jacent et que la seule alternative crédible est Curve25519, que je trouve trop déployée (on est en train de fabriquer une monoculture) ;
  
  
• Chiffrement + intégrité (aes256-gcm@openssh.com). Si tu ne peux pas utiliser GCM (chiffrement intègre), n'oublie pas de configurer un algorithme d'intégrité un peu chiadé donc de type Encrypt Then Pad Then Mac (etm) genre hmac-sha2-256-etm@openssh.com ou hmac-sha2-512-etm@openssh.com ;
  
  
• Absence de compression ;
  
  
• Clés : ssh-rsa est en orange.

Au début, je me dis qu'Aeris est dans le mouvement qui consiste à dire que les courbes elliptiques sont potentiellement plus robustes que RSA même si l'on en sait trop rien. Mais, dans ce cas, pourquoi existe-t-il aussi rsa-sha2-256 et rsa-sha2-512 ? RSA est un format de clé, non ?

J'ai trouvé la réponse chez tonton Bortzmeyer. Je cite : « (Petit point au passage, dans SSH, le format de la clé ne désigne que la clé elle-même, alors que l'algorithme désigne un format de clé et des procédures de signature et de vérification, qui impliquent un algorithme de condensation. Ainsi, ssh-keygen -t rsa va générer une clé RSA, indépendamment de l'algorithme qui sera utilisé lors d'une session SSH. Le registre IANA indique désormais séparement le format et l'algorithme.) ».

D'accord ! ssh-rsa = RSA + SHA-1. Or, la robustesse de SHA-1 a pris de sacrés coups ces dernières années (attaque de collisions pour moins de 50 000 $). C'est pour ça qu'Aeris a choisi de le marquer au fer rouge. Fin mai 2020, dans les notes de la version 8.3, le projett OpenSSH a annoncé que ssh-rsa sera désactivé dans une future version.

Cette vérification concerne la clé avec laquelle le serveur se présente afin que le client l'authentifie, pas les clés des utilisateurs du serveur. Dans mon cas, il s'agit d'une clé de type RSA 4096 bits.

Je pourrais configurer mon serveur SSH pour utiliser une clé de type ed25519, mais, comme je l'ai déjà écrit, je trouve que les algorithmes de l'équipe de chercheurs autour de djb sont trop utilisées partout sans discernement, ce qui peut créer un dangereux monopole de fait / une dangereux monoculture. Une clé ECDSA avec des paramètres normalisés au NIST, organisme état-unien peu transparent, ne me tente pas plus.

Il me reste une possibilité : désactiver ssh-rsa et utiliser les algorithmes de signature et de vérifications RSA dépourvus de SHA-1 que sont rsa-sha2-256 et rsa-sha2-512.

Pour ce faire, j'ajoute ceci dans mon fichier /etc/ssh/sshd_config : HostKeyAlgorithms rsa-sha2-512. Attention : si ton serveur SSH peut se présenter avec d'autres formats de clés (ed25519, ecdsa, etc.), active les algorithmes correspondants en les concatenant avec une virgule. Tu peux aussi désactiver uniquement ssh-rsa : HostKeyAlgorithms -ssh-rsa (note le « - »).

Attention : si tu as de vieux bouzins qui doivent se connecter à ton serveur SSH (genre un OpenWRT Backfire), ils ne doivent sûrement pas prendre en charge rsa-sha2-*. ;)

Au final, la configuration de mon serveur SSH est :

# Le serveur se présente avec une clé de type RSA
HostKey /etc/ssh/ssh_host_rsa_key
# Pour vérifier la clé du serveur, le client doit utiliser tel algo
HostKeyAlgorithms rsa-sha2-512
# Échange de clé EDH
KexAlgorithms diffie-hellman-group-exchange-sha256
# Chiffrement symétrique AEAD
Ciphers aes256-gcm@openssh.com
# Intégrité encrypt-then-pad-then-mac. 
# Inutile : on utilise GCM, donc pas besoin d'un autre algo d'intégrité que celui intégré.
MACs hmac-sha2-512-etm@openssh.com
# On désactive la compression, même si le client la réclame (ssh -C)
Compression no

La même, mais qui permet la connexion d'un OpenWRT Backfire :

# Le serveur se présente avec une clé de type RSA
HostKey /etc/ssh/ssh_host_rsa_key
# Pour vérifier la clé du serveur, le client doit utiliser tels algos (ssh-rsa pour OpenWRT…)
HostKeyAlgorithms rsa-sha2-512,ssh-rsa
# Échange de clé EDH (diffie-hellman-group14-sha1 pour OpenWRT)
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
# Chiffrement symétrique (aes256-ctr pour OpenWRT)
Ciphers aes256-gcm@openssh.com,aes256-ctr
# Intégrité (hmac-sha1 pour OpenWRT, hmac-sha2-512-etm@openssh.com au cas où on utiliserait aes256-ctr)
MACs hmac-sha2-512-etm@openssh.com,hmac-sha1
# On désactive la compression, même si le client la réclame (ssh -C)
Compression no