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
;
- Wheezy :
- 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
;
- Wheezy :
- 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
.
- Wheezy :
É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 :
- les infos techniques brutes et un peu de pédagogie en les catégorisant et en les explicitant (en anglais) ;
- une interface Web jolie et explicite ;
- 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
etcurve25519-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
etdiffie-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
etrijndael-cbc@lysator.liu.se
, -
3des-cbc
est considéré vraiment faible,blowfish-cbc
etcast128-cbc
faibles et lesarcfour
non sûrs ;
- les six de Jessie/Stretch sont considérés sûrs, ainsi que les
- 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
ethmac-sha1-96
sont considérés faibles, -
hmac-md5
ethmac-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 :
- les infos techniques brutes et un peu de pédagogie en les catégorisant (en français) ;
- une interface Web jolie et explicite ;
- 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
etKexAlgorithms
. Par exempleCiphers 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 Walter . Évalué à 1.
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 Benoît Sibaud (site web personnel) . Évalué à 5. Dernière modification le 18 juin 2017 à 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 ?
[^] # Re: Test offline
Posté par Aeris (site web personnel) . Évalué à 2.
En même temps, vu la complexité astronomique nécessaire pour accéder aux infos d’un serveur distant, ça ne devrait pas prendre longtemps pour coder un truc propre et empaquetable :)
[^] # Re: Test offline
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Je n'avais pas fait gaffe que tes outils étaient disponibles. J'ai complété la dépêche du coup.
# Tests fragiles
Posté par Sufflope (site web personnel) . Évalué à 4. Dernière modification le 18 juin 2017 à 22:35.
Amusant.
Depuis que j'ai mis une configuration de nazi dans mon sshd_config :
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 Aeris (site web personnel) . Évalué à 1.
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 Naabster . Évalué à 2.
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 Yves (site web personnel) . Évalué à 4.
Le changement de port est inutile. Sur mon serveur, j'en ai deux :
CQFD ;-)
# Secure Secure Shell
Posté par Anonyme . Évalué à 5. Dernière modification le 19 juin 2017 à 15:55.
Pour refaire ma config je m’étais basé sur cet article (qui date de 2015 mais qui a été mis à jour depuis) :
[^] # Re: Secure Secure Shell
Posté par Yves (site web personnel) . Évalué à 2.
Idem. Excellent article. Ne pas oublier de surveiller le dépôt Git pour d'éventuelles actualisations.
# Recompiler SSH sans le support SSL
Posté par Dabowl_75 . Évalué à 1.
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é.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.