(Modifié le 05/08/2019)

Secure Shell (SSH )

SSH: Execute Remote Command or Script – Linux

Echange de clés

OpenSSH supporte 8 protocoles d’échange de clés :

1 curve25519-sha256: ECDH avec Curve25519 et SHA2

2 diffie-hellman-group1-sha1: DH 1024 bits avec SHA1

3 diffie-hellman-group14-sha1: DH 2048 bits avec SHA1

4 diffie-hellman-group-exchange-sha1: Custom DH avec SHA1

5 diffie-hellman-group-exchange-sha256: Custom DH avec SHA2

6 ecdh-sha2-nistp256: ECDH avec NIST P-256 et SHA2

7 ecdh-sha2-nistp384: ECDH avec NIST P-384 et SHA2

8 ecdh-sha2-nistp521: ECDH avec NIST P-521 et SHA2

  • Eliminer les protocoles 6 à 8 parce que le NIST est considéré comme nuisible
  • La taille en bits du modulo utilisé par DH : ce qui élimine le protocole 2. 1024 bits ne sont pas suffisants.
  • La sûreté de la fonction de hachage : ce qui élimine les protocoles 2 à 4 car SHA1 est cassé.

Le protocole 1 est le meilleur mais pour des raisons de compatibilité on garde le protocole 5.

Ajouter une ligne au fichier serveur /etc/ssh/sshd_config

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Et deux lignes au fichier client /etc/ssh/ssh_config

Host *
    KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Pour activer le protocole 5, ouvrir le fichier /etc/ssh/moduli ,s’il existe, et supprimez les lignes où la cinquième colonne est inférieure à 2000 :

$ awk '$5 > 2000' /etc/ssh/moduli > "${HOME}/moduli"
$ wc -l "${HOME}/moduli" # Assure-vous que le fichier généré ne soit pas vide
$ mv "${HOME}/moduli" /etc/ssh/moduli

fichier /etc/ssh/moduli inexistant , création

ssh-keygen -G /etc/ssh/moduli.all -b 4096
ssh-keygen -T /etc/ssh/moduli.safe -f /etc/ssh/moduli.all
mv /etc/ssh/moduli.safe /etc/ssh/moduli
rm /etc/ssh/moduli.all

ATTENTION Opération très longue en temps

Authentification

L’échange de clés permet de s’assurer que le serveur et le client ont partagé un secret sans que personne d’autre ne le sache. Mais il nous faut aussi s’assurer qu’ils ont bien partagé ce secret entre eux UNIQUEMENT.

Authentification du SERVEUR

Le serveur prouve son identité au client en signant la clé résultant de l’échange de clés. Il y a quatre algorithmes pour l’authentification d’une clé publique :

1 DSA avec SHA1

2 ECDSA avec SHA256, SHA384 ou SHA512 (selon la taille de la clé)

3 Ed25519 avec SHA512

4 RSA avec SHA1

Les clés DSA font 1024 bits, on désactive.Le numéro 2 implique le NIST et devrait être aussi désactivé. Autre inconvénient de DSA et ECDSA, ils utilisent l’aléatoire de la machine pour chaque signature. Si cet aléatoire n’est pas d’une grande qualité, il est possible de retrouver la clé. Heureusement, RSA avec SHA1 n’est pas un problème ici puisque la valeur à signer est déjà un hachage SHA2 (voir la section précédente). La fonction de hachage SHA1(SHA2(x)) est aussi sûre que SHA2 seule (le résultat est moins long, certes, mais il n’est pas vulnérable pour autant).

Modifier le fichier serveur /etc/ssh/sshd_config

Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

A la prochaine connexion, accepter les nouvelles empreintes

La configuration ci-dessus désactive aussi la v1 du protocole SSH, troué de partout et qui de toute manière ne devrait JAMAIS être activée. Nous pouvons aussi supprimer les clés inutilisées et générées par OpenSSH lors de son installation afin de regénérer des clés RSA et Ed25519 plus longues et plus robustes.

cd /etc/ssh
rm ssh_host_*key*
ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null
ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null

Authentification du CLIENT

Le client doit prouver son identité au serveur. Il existe principalement 2 méthodes

Méthode 1 : authentification par mot de passe

Elle peut laisser fuiter les mots de passe en cas de compromission de serveur et est vulnérable aux attaques par bruteforce.

A désactiver dans les meilleurs délais

SERVEUR : Désactiver la connexion par mot de passe ,modifier le fichier /etc/ssh/sshd_config

PasswordAuthentication no
ChallengeResponseAuthentication no

CLIENT : Désactiver la connexion par mot de passe ,modifier le fichier /etc/ssh/ssh_config

Host *
    PasswordAuthentication no
    ChallengeResponseAuthentication no

Méthode 2 : utilisation d’une clé publique

SERVEUR : ,modifier le fichier /etc/ssh/sshd_config

PubkeyAuthentication yes

CLIENT : ,modifier le fichier /etc/ssh/ssh_config

Host *
    PubkeyAuthentication yes
    HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa

Les clés

Génération

Utiliser la commande suivante

ssh-keygen -t ed25519 -o -a 100
ssh-keygen -t rsa -b 4096 -o -a 100

Déploiement

Le déploiement des clés publiques .pub

ssh-copy-id -i .ssh/id_ed25519.pub utilisateur@serveur

Authentification ciblée

Même avec l’authentification par clé publique, vous devriez autoriser les connections SSH uniquement depuis un nombre restreint d’utilisateurs. Ceux susceptibles d’accéder aux serveur via SSH. La directive AllowUsers dans /etc/ssh/sshd_config vous permet de spécifier quels sont les utilisateurs autorisés à se connecter via SSH.

Mais cela peut s’avérer compliqué si vous avez à gérer un nombre important d’utilisateurs. D’autant plus que si vous supprimez l’un d’entre eux, celui-ci ne sera pas retiré de /etc/ssh/sshd_config, ce qui alourdit encore plus la maintenance.

Une solution possible est de se tourner vers AllowGroups à la place, et d’ajouter un groupe ssh-users sur votre machine par exemple, en modifiant **/etc/ssh/sshd_config **:

AllowGroups ssh-users

Pour créer le groupe et lui ajouter un utilisateur :

sudo groupadd ssh-users
sudo usermod -a -G ssh-users utilisateur

Chiffrement symétrique

Le chiffrement symétrique est utilisé par SSH pour chiffrer les échanges entre client et serveur une fois l’échange de clé initial et l’authentification terminés. Il existe un nombre d’algorithmes à notre disposition

1 3des-cbc

2 aes128-cbc

3 aes192-cbc

4 aes256-cbc

5 aes-128-ctr

6 aes-192-ctr

7 aes-256-ctr

8 aes128-gcm@openssh.com

9 aes256-gcm@openssh.com

10 arcfour

11 arcfour128

12 arcfour256

13 blowfish-cbc

14 cast128-cbc

15 chacha20-poly1305@openssh.com

  • Sûreté de l’algorithme : ici 1 et 10 à 12 sont éliminés. DES et RC4 sont tous les deux cassés, il faut les désactiver dans tous les cas
  • Taille de clé : minimum 128 bits
  • Taille de bloc : minimum 128 bits. 13 et 14 sont éliminés car leur taille de bloc ne dépasse pas 64 bits
  • Le mode de chiffrement (recommandation)
    • préférer les modes AE (Authenticated Encryption)
    • N’utiliser CTR que pour des raisons de compatibilité. CTR avec Encrypt-then-MAC doit normalement être sûr (nous y reviendrons un peu plus bas).
  • chacha20-poly1305@openssh doit être privilégié à AES-GCM parce que le protocole SSH ne chiffre pas la taille du message lorsqu’il est utilisé avec GCM (ou EtM). Ceci pouvant être source d’attaque, notamment via l’analyse de trafic.

SERVEUR : modifier le fichier /etc/ssh/sshd_config

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

CLIENT : modifier le fichier /etc/ssh/ssh_config

Host *
    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Codes d’authentification de message

Le chiffrement fournit la confidentialité, un code d’authentification de message (Message authentication code, MAC) va nous fournir l’intégrité. C’est-à-dire l’assurance que le message qui a été envoyé entre deux pairs n’a pas été modifié en chemin. Et nous avons besoin des deux. **Si nous avons choisi l’AE ci-dessus, inutile d’utiliser un MAC supplémentaire car l’intégrité est déjà garantie. **

  • Pour le cas de CTR, nous devons en plus choisir un algorithme pour calculer et attacher le MAC à chaque message.

    • Encrypt-then-MAC : le message est chiffré, puis le MAC est calculé à partir de celui-ci (une fois chiffré donc)
    • MAC-then-Encrypt : le MAC est calculé à partir du message en clair, puis le tout est chiffré
    • Encrypt-and-MAC : le message est chiffré, puis le MAC calculé à partir du message en clair est attaché

ATTENTION ! Utiliser Encrypt-then-MAC et rien d’autre.

L’utilisation de MAC-then-Encrypt a conduit à suffisamment d’attaques sur TLS alors que Encrypt-then-MAC n’en a pas présenté autant sur SSH. La raison à cela est que si jamais vous recevez le message d’un attaquant, plus vous allez le manipuler et plus vous aller lui laisser de chances d’obtenir des informations. Dans le cas de Encrypt-then-MAC, le MAC est vérifé et s’il est incorrect, rejeté. Une étape, aucun moyen d’obtenir des informations. Alors que dans le cas de MAC-then-Encrypt, comme le MAC est calculé à partir du message en clair il va falloir déchiffrer le message afin de vérifier le MAC. Un échec de déchiffrement (dû à un mauvais padding CBC par exemple) pourrait prendre moins de temps qu’il n’en faut pour la génération de l’échec de vérification du MAC, et donner du temps à l’attaquant pour accéder à des informations. Le problème est le même avec Encrypt-and-MAC .

Les choix possibles :

1 hmac-md5

2 hmac-md5-96

3 hmac-ripemd160

4 hmac-sha1

5 hmac-sha1-96

6 hmac-sha2-256

7 hmac-sha2-512

8 umac-64

9 umac-128@openssh.com

10 hmac-md5-etm@openssh com

11 hmac-md5-96-etm@openssh com

12 hmac-ripemd160-etm@openssh.com

13 hmac-sha1-etm@openssh com

14 hmac-sha1-96-etm@openssh com

15 hmac-sha2-256-etm@openssh.com

16 hmac-sha2-512-etm@openssh.com

17 umac-64-etm@openssh com

18 umac-128-etm@openssh.com

  • Sûreté et solidité de l’algorithme : pas de MD5 ni de SHA1
  • La taille du tag : au moins 128 bits, ce qui élimine umac-64-etm
  • La taille de clé : minimum 128 bits

Extrait pour configuration serveur /etc/ssh/sshd_config :

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

Et pour le client /etc/ssh/ssh_config :

Host *
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

Précautions

La fonctionnalité UseRoaming présente une vulnérabilité , il faut la désactiver (client) dans /etc/ssh/ssh_config :

Host *
   UseRoaming no

il est important de garder les clés à l’abri des regards indiscrets.

Conclusion

C’est certainement une bonne idée de tester tous les changements apportés. ssh -v apporte un certain nombre de détails, notamment les algorithmes utilisés, pratique pour déboguer rapidement. Soyez très prudent lorsque vous changez la configuration SSH d’une machine distante. Faites en sorte de toujours garder une session active, sans jamais redémarrer sshd avant d’être sûr de soit. Vous pouvez par ailleurs demander à OpenSSH de recharger la configuration sans redémarrer en utilisant un SIGHUP. Pour être à l’abri de tout risque, vous pouvez aussi démarrer temporairement un serveur SSH sur un nouveau port le temps de faire vos tests