OpenSSH : configuration des algorithmes de cryptographie

40
18
juin
2017
Administration système

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).

Bannière openssh

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

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.).

Capture

  • 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).

capture CryptCheck

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.

Capture cryptcheck en CLI

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).
  • # Test offline

    Posté par . Évalué à 1 (+1/-0).

    Bonjour,
    pour un test privé de ssh : https://github.com/evict/SSHScan
    l'équivalent pour ssl : https://testssl.sh/

    Les tests online ne servent pas à repérer les cibles potentiels ?
    ++

    • [^] # Re: Test offline

      Posté par (page perso) . Évalué à 5 (+2/-0). Dernière modification le 18/06/17 à 14:57.

      Merci pour le lien vers SSHScan (licence MIT). J'ai complété la dépêche avec.

      Pour TLS, je pensais faire une autre dépêche à part, il y a pas mal de sites pour le test et aussi le script de testssl.sh.

      Question naïve : quelqu'un sait pourquoi ça ne fait pas directement partie du client openssh ? Pourquoi ne pas avoir une option permettant de tester un serveur distant (sous réserve d'avoir un openssh lui-même récent évidemment) et signaler les algorithmes faibles proposés ?

  • # Tests fragiles

    Posté par (page perso) . Évalué à 4 (+2/-0). Dernière modification le 18/06/17 à 22:35.

    Amusant.

    Depuis que j'ai mis une configuration de nazi dans mon sshd_config :

    Ciphers chacha20-poly1305@openssh.com
    KexAlgorithms curve25519-sha256@libssh.org
    MACs umac-128-etm@openssh.com
    

    les deux outils indiqués foirent, l'un en bouclant à l'infini sur une page qui se rafraichit pour rien (CryptCheck) et l'autre (ainsi qu'un troisième trouvé par un moteur de recherche) en me disant explicitement que mon serveur SSH n'est pas joignable (si si merci il est bien lancé je vous remercie).

    Alors, difficile à joindre dans une langue qu'il accepte, je veux bien, mais injoignable, non désolé le problème est chez vous :-).

    • [^] # Re: Tests fragiles

      Posté par (page perso) . Évalué à 1 (+0/-0).

      Pour Cryptcheck, c’est plus un problème de scheduler qu’autre chose.
      C’est 100% compatible toute version de OpenSSL et toute configuration :D

  • # Bits Génération !

    Posté par (page perso) . Évalué à 2 (+1/-0).

    Merci pour la découverte de Rebex que je ne connaissais pas.

    Je ferais juste une petite remarque concernant les paramètres permettant de définir le nombre de bits de la clef éphémère ainsi que sa durée de régénération.. N'étant valable que pour la version 1 (qui est toute trouée) du protocole SSH, les lignes de configuration :

    • KeyRegenerationInterval 3600
    • ServerKeyBits 1024 # en Jessie/Stretch et 768 en Wheezy

    Sont inutiles car la version a utiliser est défini au début du fichier Protocol 2.

    De plus, une petite modification du port par défaut peu être une bonne pratique pour éviter les attaques de bases

    • [^] # Re: Changement de port

      Posté par (page perso) . Évalué à 4 (+3/-0).

      Le changement de port est inutile. Sur mon serveur, j'en ai deux :

      • le port 22 masqué par port-knocking, juste pour moi ; RÀS…
      • un autre port pour l'accès SSH (Gitolite) auquel aucun utilisateur système n'est autorisé à se connecter. Et pourtant ce port se fait spammer à mort !

      CQFD ;-)

  • # Secure Secure Shell

    Posté par (page perso) . Évalué à 4 (+2/-0). Dernière modification le 19/06/17 à 15:55.

    Pour refaire ma config je m’étais basé sur cet article (qui date de 2015 mais qui a été mis à jour depuis) :

  • # Recompiler SSH sans le support SSL

    Posté par . Évalué à 1 (+0/-0).

    J'avais écrit un journal il y a quelques temps sur ce sujet :

    https://linuxfr.org/users/dabowl_75/journaux/openssh-no-longer-has-to-depend-on-openssl

    Bien que SSH n'a jamais été véritablement inquiété par les failles SSL, cette dépendance entraîne toujours une maintenance plus ou pénible lorsqu'on gère les mises à jour sur un gros un parc.

    L'avantage, ou l'inconvénient de se passer de SSL est que cela implique de se servir de ce qu'il y a d'embarqué dans SSH comme la crypto à courbe elliptique.

    Certains outils sont déjà prêts à gérer ce type de clef, comme Putty / Puttygen.

    Je trouve que cela simplifie grandement la maintenance de SSH sur un parc.
    Moins de dépendance, plus de simplicité.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.