Sécuriser SSH
Le titre semble paradoxal (sécuriser Secure SHell), néanmoins on peut améliorer la configuration fournie par défaut.
Ce tutoriel est tenu à jour régulièrement. Dernière révision : 21 janvier 2017.
Ce qui va suivre est prévu pour Debian jessie. Si ce n’est pas votre distribution, vous pouvez vérifier quels choix sont disponibles pour KexAlgorithms, Ciphers et MACs avec votre version de SSH, en faisant man sshd_config.
Les commandes préfixées d’un # sont à lancer en root. Les commandes préfixées d’un % sont à lancer en simple utilisateur.
Côté serveur
La configuration se situe dans /etc/ssh/sshd_config.
Version du protocole
Pour commencer, il faut désactiver le protocole 1 si ce n’est pas déjà fait. Utiliser le protocole 1 aujourd’hui, ça revient quasiment à utiliser telnet.
Protocol 2
Le type de clé
ECDSA repose sur des nombres choisis de manière arbitraire et présente donc un risque de backdoor. Les clés DSA sont limitées à 1024 bits, ce qui n’est plus suffisant depuis quelques années. On va utiliser l’algo ED25519, la meilleure option à ce jour.
Une seule ligne HostKey doit rester :
HostKey /etc/ssh/ssh_host_ed25519_key
On supprime les anciennes clés et on génère une nouvelle clé pour le serveur :
# rm -i /etc/ssh/ssh_host_*key*
# ssh-keygen -t ed25519 -N "" -f /etc/ssh/ssh_host_ed25519_key
Si vous avez encore des systèmes en wheezy, la meilleure option c’est une clé RSA solide, avec une taille de 4096 bits :
# ssh-keygen -t rsa -b 4096 -N "" -f /etc/ssh/ssh_host_rsa_key
L’échange des clés
ECDH peut fuiter des infos lors de la synchronisation, et SHA1 est complètement dépassé. On choisit donc curve25519.
KexAlgorithms curve25519-sha256@libssh.org
L’algo de chiffrement
L’algo chacha20-poly1305 est la meilleure option à l’heure actuelle.
Ciphers chacha20-poly1305@openssh.com
Il faut aussi se soucier des algos MAC (message authentication code), qui s’occupent de l’intégrité des données.
MACs hmac-sha2-512-etm@openssh.com
Autres précautions
SSH se base sur un modèle TOFU (Trust On First Use). Si vous n’êtes pas certain du réseau utilisé lors de la première connexion, il vaut mieux ajouter manuellement les fingerprints dans ~/.ssh/known_hosts, pour éviter un MITM sur cette première connexion.
Le port 22 fait l’objet de scans automatiques, ce qui remplit les logs de lignes sans intérêt. Vous pouvez changer SSH de port et le spécifier dans ~/.ssh/config pour que cela soit transparent.
Si vous avez installé le système avant wheezy, il aura gardé l’accès root activé, si vous n’avez pas installé la nouvelle version de sshd_config fournie par le paquet.
PermitRootLogin no
Limitez l’accès SSH aux comptes que vous spécifiez :
AllowUsers utilisateur1 utilisateur2
Attention, quand vous ajoutez un nouvel utilisateur sur le système, il faudra l’ajouter dans cette liste si vous voulez qu’il puisse se connecter avec SSH. Ce dernier ne vous fournira pas un message d’erreur explicite, il faudra y penser.
Une fois les modifications terminées, on relance SSH :
# service ssh restart
Bien évidemment, à la prochaine connexion SSH vers ce serveur, vous aurez le message suivant :
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
En temps normal, c’est très mauvais signe, mais dans notre cas c’est normal puisqu’on vient de regénérer la clé du serveur. Il suffit d’éditer ~/.ssh/known_hosts pour supprimer les lignes correspondant à l’ancienne clé, qui sont indiquées dans la suite du message. Ensuite, soit vous ajoutez manuellement la nouvelle clé à la fin de ~/.ssh/known_hosts, soit vous relancez la même commande SSH et vous acceptez la nouvelle clé (mais vous courez un risque de MitM pour cette connexion).
Côté client
On va mettre en place la même configuration côté client. Ainsi, elle s’appliquera aussi aux connexions vers les serveurs que vous n’administrez pas, quand c’est possible. Éditez /etc/ssh/ssh_config :
Host *
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256
Host serveur-qui-utilise-encore-sha1
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1
Ciphers aes256-ctr
MACs hmac-sha2-512,hmac-sha2-256,umac-64@openssh.com,hmac-sha1
Il faudra ajouter des exceptions pour les serveurs qui ne proposent que les vieux algos. Ou bien vous pouvez passer outre sur la ligne de commande, avec :
% ssh -m hmac-sha1 hôte
Pourquoi tout ça ?
L’espionnage industriel reste sous-évalué. Pourtant, on sait que les compagnies américaines bénéficient de l’aide des agences gouvernementales pour faire de l’espionnage industriel. Un député a assez bien résumé la situation : « Nos principaux partenaires sont d'abord nos principaux prédateurs ».
Il faut changer de politique et chiffrer par défaut. On ne doit passer en clair que si on a une contrainte de performance, et encore faut-il que ça soit sur des données non sensibles.
