Le logiciel OpenSSH permet d’avoir un shell sécurisé sur un serveur distant ou du transfert de fichiers de ou vers un serveur. Divers algorithmes de cryptographie sont utilisés pour le chiffrement, la génération ou l’échange de clefs. Et ces algorithmes peuvent s’affaiblir, être remplacés par de meilleurs algorithmes, connaître des portes dérobées, nécessiter des clefs plus grandes, etc. Ils sont implémentés (au sens ajouter ou enlever) par les développeurs d’OpenSSH (et de bibliothèques de cryptographie sous‐jacentes), ils sont empaquetés par une distribution (qui peut changer certains réglages à la production du paquet ou bien faire certains choix sur la configuration par défaut), et ils sont mis à jour par les équipes sécurité (d’OpenSSH et de la distribution).

Jetons un œil sur les paquets openssh-server de la distribution Debian (actuellement les versions sont 6.0p1-4+deb7u4 en Wheezy (l’ancienne ancienne version stable), 6.7p1-5+deb8u3 en Jessie (l’ancienne version stable) et 7.4p1-10 en Stretch (la version stable actuelle depuis le 17 juin 2017) : nous verrons quels sont les algorithmes pris en charge, quels sont ceux par défaut et quel niveau de sûreté leur accorder (suivant les tests des sites Rebex et CryptCheck, et les outils SSHScan et CryptCheck que nous allons utiliser).

Sommaire

• • Configuration par défaut après installation sur Debian
  • Algorithmes par défaut (selon la page de man de sshd_config) :
  • Évolution du logiciel et correctifs de la distribution
  • Test via le site Rebex
  • Test via le site CryptCheck
  • Test avec le client OpenSSH
  • Test avec SSHScan
  • Test avec l’outil ligne de commande CryptCheck
  • Conclusions

Configuration par défaut après installation sur Debian

La configuration /etc/ssh/sshd_config par défaut après une installation est la suivante :

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key # absent en Stretch
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key # absent en Wheezy
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 1024 # en Jessie/Stretch et 768 en Wheezy
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin without-password # en Jessie/Stretch et yes en Wheezy
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

Algorithmes par défaut (selon la page de man de sshd_config) :

• algorithmes de chiffrement :
  • Wheezy : aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,
  • Jessie/Stretch : chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com ;
• algorithmes d’échange de clef :
  • Wheezy : ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,
  • Jessie : curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,
  • Stretch : curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 ;
• algorithmes MAC :
  • Wheezy : hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-sha1-96,hmac-md5-96,hmac-sha2-256,hmac-sha256-96,hmac-sha2-512,hmac-sha2-512-96,
  • Jessie/Stretch : umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1.

Évolution du logiciel et correctifs de la distribution

Une partie des modifications vient de la distribution : par exemple, dans le paquet openssh-server présent dans Stretch (en l’occurrence dans le fichier openssh_7.4p1-10.debian.tar.xz), on peut trouver la modification de configuration no-dsa-host-key-by-default.patch qui enlève la génération d’une clef DSA ; plus, bien sûr, les correctifs de sécurité concernant openssh.

Mais la majorité des changements concernant les algorithmes vient de l’équipe openssh elle‐même :

• la version 6.7 a notamment retiré du choix par défaut les algorithmes CBC et arcfour* ;
• la 7.2 a retiré du choix par défaut blowfish-cbc, cast128-cbc, arcfour, rijndael-cbc et ceux basés sur MD5 et HMAC tronqué, et ajouté la prise en charge de RSA avec SHA-256/512 ;
• la 7.4 a retiré du choix par défaut 3des-cbc ;
• et la récente 7.5 va plus loin en retirant le protocole SSH v1, les algorithmes Blowfish, RC4 et RIPE-MD160 HMAC, en refusant les clefs RSA plus petites que 1 024 bits et en retirant du choix par défaut les derniers CBC.

Test via le site Rebex

Le site de test Rebex fournit pour un serveur SSH accessible publiquement :

1. les infos techniques brutes et un peu de pédagogie en les catégorisant et en les explicitant (en anglais) ;
2. une interface Web jolie et explicite ;
3. une veille technologique et de la pédagogie en classifiant les algorithmes (non sûr, faible, sûr) et en fournissant des explications et des liens (SHA-1 devient obsolète, possible porte dérobée NSA, etc.).

• algorithmes d’échange de clefs :
  • diffie-hellman-group-exchange-sha256 et curve25519-sha256@libssh.org sont considérés sûrs,
  • les trois ecdh-sha2-nistp256/384/521 classés « sûrs, mais possible porte dérobée NSA »,
  • diffie-hellman-group14-sha1 et diffie-hellman-group-exchange-sha1 sont considérés faibles,
  • diffie-hellman-group1-sha1 est considéré non sûr ;
• algorithmes de clefs du serveur :
  • ssh-ed25519 est considéré sûr,
  • ecdsa-sha2-nistp256 est considéré « sûr mais possible porte dérobée NSA »,
  • ssh-rsa est considéré « sûr mais SHA-1 devient obsolète »,
  • ssh-dss « faible et SHA-1 devient obsolète » ;
• algorithmes de chiffrement :
  • les six de Jessie/Stretch sont considérés sûrs, ainsi que les aes128/192/256-cbc et rijndael-cbc@lysator.liu.se,
  • 3des-cbc est considéré vraiment faible, blowfish-cbc et cast128-cbc faibles et les arcfour non sûrs ;
• algorithmes MAC :
  • umac-128-etm@openssh.com, hmac-sha2-256-etm@openssh.com, hmac-sha2-512-etm@openssh.com, umac-128@openssh.com, hmac-sha2-256, hmac-sha2-512, hmac-ripemd160, hmac-ripemd160@openssh.com sont considérés sûrs,
  • umac-64-etm@openssh.com, hmac-sha1-etm@openssh.com, umac-64@openssh.com, hmac-sha1, hmac-sha2-256-96 et hmac-sha1-96 sont considérés faibles,
  • hmac-md5 et hmac-md5-96 sont considérés non sûrs.

Test via le site CryptCheck

Le site de test CryptCheck fournit toujours pour un serveur SSH accessible publiquement :

1. les infos techniques brutes et un peu de pédagogie en les catégorisant (en français) ;
2. une interface Web jolie et explicite ;
3. une veille technologique (mais sans explication particulière hormis le détail des algorithmes).

On peut noter que hmac-sha1-etm@openssh.com apparaît en vert/sûr côté CryptCheck, alors qu’il apparaît en orange/faible côté Rebex. L’appréciation des algorithmes suivant les différents acteurs (OpenSSH, Debian, Rebex ou CryptCheck) peut être différente.

Modification post‐publication : après discussion avec l’auteur via IRC, le site classe désormais diffie-hellman-group14-sha1, hmac-sha1-etm@openssh.com et hmac-sha1 en rouge. Merci aeris.

Test avec le client OpenSSH

Par rapport aux deux sites précédents, il est possible de récupérer les infos techniques brutes facilement soi‐même avec un simple client OpenSSH (mais sans la belle interface, les couleurs et les explications) :

$ ssh -vv example.com -p 22
…
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4+deb7u6
…
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256
debug2: host key algorithms: ssh-rsa
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes192-cbc,aes256-cbc
…
debug2: MACs stoc: hmac-ripemd160,hmac-sha2-256,hmac-sha2-512,hmac-sha2-512-96
debug2: compression ctos: none,zlib@openssh.com

Test avec SSHScan

Le projet SSHScan fournit un outil de test en ligne de commande sous licence MIT (merci à Walter de l’avoir pointé en commentaire).

$ python sshscan.py -t example.com
…
    [+] Detected the following ciphers: 
…
    [+] Detected the following KEX algorithms: 
…
    [+] Detected the following MACs: 
…
    [+] Detected the following HostKey algorithms: 
            ssh-rsa                              ssh-dss                              
…
    [+] No weak ciphers detected!
    [+] Detected the following weak KEX algorithms: 
            diffie-hellman-group14-sha1          ecdh-sha2-nistp384                   
            ecdh-sha2-nistp256                   ecdh-sha2-nistp521                   


    [+] Detected the following weak MACs: 
            hmac-sha1                            hmac-sha1-etm@openssh.com            
            umac-64                              umac-64-etm@openssh.com              


    [+] Detected the following weak HostKey algorithms: 
            ssh-dss                                                                   


    [+] Compression has been enabled!

Test avec l’outil ligne de commande CryptCheck

L’outil utilisé pour le site CryptCheck est disponible sous AGPL v3+. Merci à Aeris qui l’a signalé dans ce commentaire.

Conclusions

Voici donc ce que l’on peut déduire de cette analyse :

• tenir son openssh-server (et ses dépendances) à jour vis‐à‐vis des correctifs de sécurité ;
• profiter des changements de distribution pour renouveler les clefs SSH des serveurs avec une longueur et des algorithmes adaptés, plutôt que de les conserver telles que ;
• la configuration de la distribution était peut‐être très bien lors de sa sortie, mais elle va nécessiter d’être révisée plus tard si l’on veut renforcer la sécurité ;
• Mozilla fournit un guide de configuration (l’ANSSI aussi) pour faire le tri entre les algorithmes et ne garder que les meilleurs (choisir les bons paramètres HostKey, Ciphers, MACs et KexAlgorithms. Par exemple Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr. Contrairement au choix des algorithmes TLS pour Apache et nginx, on ne peut pas interdire des algorithmes (on avait, par exemple, des interdictions sous la forme !aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5), il faut explicitement lister ceux que l’on veut ;
• le manuel de sécurisation Debian (Securing Debian Manual) ne couvre pas actuellement cet aspect ;
• prendre un moment pour imaginer la galère que ça va être pour les objets connectés et autres périphériques réseau qui embarqueraient des serveurs SSH, qui resteront probablement non maintenus et non reconfigurés pendant des années ;
• je me suis attardé sur la configuration des serveurs SSH, mais la même question se pose pour les clients SSH (et Mozilla fournit aussi les infos dans son guide) ;
• les testeurs en ligne Rebex ou CryptCheck sont rapides et pratiques, mais si vous connaissez un outil en ligne de commande (comme SSHScan et CryptCheck signalés dans les commentaires), voire empaqueté Debian, qui permet la même chose, ça m’intéresse (pour tester des serveurs avant de les mettre en ligne ou des serveurs non accessibles publiquement, par exemple, et pour éviter de réimplémenter sa propre analyse de ssh -vv).