Configuration SSH sécurisée

13 déc. 2016, 13:12

@vohu a ouvert un post Trucs & Astuces, il y a quelques temps, pour promouvoir l'usage de SSH !
Très bonne initiative ... et je ne reprendrais pas ces informations.

Ce post a pour propos d'attirer l'attention sur les bonnes pratiques actuelles pour la gestion correcte de configuration de SSH et de l'outil "ssh-keygen", sur lesquelles j'avais déjà commencé à attirer l'attention en réponse.

----

De la bonne configuration des fichiers de config SSH.

Côté serveur : fichier de config /etc/ssh/sshd_config ... le fichier ssh_config lui sert à obliger les stations qui chercheraient à se connecter
Côté station : fichier de config ~/.ssh/ssh_config

En résumé :

1. Côté client/serveur : utiliser de préférence les modes de chiffrement Ciphers suivant :

chacha20-poly1305@openssh.com, dès la version 6.5, par défaut dans la 6.9
à défaut, l'un des deux chiffrements suivants : aes128-gcm@openssh.com, aes256-gcm@openssh.com

2. côté client/serveur : utiliser de préférence les modes MAC EtM, :

de préférence hmac-sha2-512-etm@openssh.com, dès que disponible ;
à défaut les modes suivants : hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256

3. côté client/serveur : utiliser les algorithmes KexAlgorithms suivants : curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
4. côté client/serveur : utiliser le chiffrement ED25519 pour générer vos nouvelles clés, et/ou les mettre à jour ! (pour savoir comment les générer, lire mon premier mémo.)
5. côté client : utiliser l'option 'UseRoaming no' !

(à utiliser impérativement pour toutes les versions <= 7.2 - option désactivée définitivement à partir de cette version 7.2)

6. côté client : utiliser l'option "IdentityPersist" qui définit le temps de vie de la clé enregistrée (en nombre de secondes, ou "true", pour infini.)

Du bon usage de l'outil "ssh-keygen" :

1. On n'utilise plus les chiffrements DSA, ECDSA : byebye !!!
2. On utilise correctement RSA, à mimina avec l'option '-o' utilisant le durcissement PKBDF, et des clés minimales de 4096 bits, voire plus[*] tel que, par exemple :

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -o
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -o -a 64

3. Mieux on utilise directement le chiffrement ED25519 - disponible dès la version 6.5 -, avec l'option '-o' utilisant le durcissement PKBDF[*]tel que, par exemple :

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -o -a 64

Pour mémo, l'option '-a' spécifie le nombre de tours désirés ; si non spécifiée, le durcissement PKBDF sera utilisé en faisant 16 tours de chiffrement. La valeur 64 est la recommandation actuelle pour les paranoïaques.

/!\ Attention : plus la clé durcie est créée avec un nombre de bits important, et un nombre de tours considérables, plus le temps de connexion au serveur sera allongé - ce temps est nécessaire et nécessité pour que la machine "décode" votre clé - cela a donc un impact non négligeable sur le temps de connexion, et donc sur l'usage d'option, telle que "LoginGraceTime" ... la recommandation actuelle est de 60 secondes. Si pour vos besoins, vous avez baissé à moins de secondes, il va falloir remonter cette valeur ... etc ... etc ... /!\
Ainsi là où avant vous arriviez à vous connecter en quelques petites secondes, la probabilité que ce soit en plusieurs dizaines de secondes est une réalité !

----

Les informations ci-dessus sont le résumé de mon article très complet : SSH Configuration et clés plus sécurisées
À ce propos, je diffuse un outil de création correcte des clés GPG sur mon dépôt Git, et celui d'ici :p

J'attire l'attention aussi sur ceux-là :

Gestion des connexions SSH avec Home chiffré !
Gestion du SSH ChrootDirectory
état des lieux SSH v6, v7

Malheureusement, je me rends compte au-travers de différents contacts, qu'on a encore de mauvais réflexes, voire qu'on distille incorrectement les informations.

vohu · 13 déc. 2016, 18:22

Ce qui pourrait être sympa, c'est de faire le lien avec gpg-agent qui apparemment peut remplacer ssh-agent

13 déc. 2016, 19:09

vohu a écrit :Ce qui pourrait être sympa, c'est de faire le lien avec gpg-agent qui apparemment peut remplacer ssh-agent

Ahhh, et, tu aurais lu cela où ?

Sympa: peut-être !
Sécurisé : rien n'est moins sûr !
Faut que je lise la documentation ci-dessous, et fasse si possible quelques recherches à ce propos .

----

Ce serait apparemment l'option 'enable-ssh-support' à enregistrer dans le fichier de config de gpg qui permettrait à GPG de gérer les clés SSH, voire d'assurer l'authentification. Soit !
Je ne suis pas sûr que j'y attacherais autant de confiance ... mais pourquoi pas ?!

http://www.bootc.net/archives/2013/06/0 ... ent-setup/
https://www.unix-ag.uni-kl.de/~guenther ... r-ssh.html
https://incenp.org/notes/2014/gnupg-for ... ation.html

15 déc. 2016, 11:24

La complicité, et donc la fiabilité, d'un système de chiffrement dépend de la valeur de ce qu'on a à protéger.
J'ai du mal à voir le niveau de complexité que tes recommandations ajoutent par rapport à la config par défaut des différents outils.
Si je veux faire simple, et que je regarde les versions proposées:
- wheezy: 6.0
- wheezy backports: 6.6
- jessie: 6.7
- stretch: 7.3
- sid : 7.3

Mais ce n'est pas aussi simple, car les anciennes versions sont ont des patches de sécurité qui sont ajoutés.
Concrètement, pour des données personnelles pas particulièrement sensible, et si on veut rester sur la config par défaut, quelle version minimale recommandes tu ?

15 déc. 2016, 12:41

À minima la 6.5, parce qu'elle ajoute le support PKBDF, autant à RSA, qu'à ED25519, et la préférence recommandée est l'usage de ce dernier couplé à PKBDF, bien sûr ...

Le propos est d'utiliser les bons algorithmes qui ne sont pas connus pour être "faillibles" et de bien les utiliser ...

=> Si tu veux faire bien, tu utilises RSA, 4096 bits, PKBDF.
Il n'y a aucune objection à continuer d'utiliser RSA ; faut seulement bien le faire et arrêter de conseiller, style juste : 'ssh-keygen -t RSA' <= ce n'est plus bon !

Dans ce sens, de deux choses l'une :
- soit tu as déjà précédemment créer une clé RSA, tu peux très simplement la mettre-à-jour pour la durcir avec la commande suivante : ssh-keygen -o -p -f id_rsa -a 64, ce qui est déjà un bon début. Si ta clé est inférieure à 2048, tu en crées une nouvelle - et surtout tu jettes les clés (EC)DSA.
- soit tu en crées un nouvelle avec le nombre de bits minimum recommandés, à ce jour 4096, en veillant à utiliser le durcissement PKBDF - tel que je l'ai expliqué ;)

=> Et, si tu veux vraiment faire sérieusement les choses, tu utilises l'algo ED25519, avec l'option de durcissement PKBDF.

Mais il est IMPÉRATIF de bien configurer les fichiers de config, autant sur le serveur, que son perso, sur sa station !

Désolé, si je ne suis pas clair ...

----

Pour info, sur les serveurs que je gérais précédemment, j'ai fais le nécessaire. J'avais upgrader ma clé RSA 2048 bits pour la durcir ... ce qui me permettaient d'assurer la transition sur ces serveurs, histoire de m'assurer, et de prendre le temps nécessaire à celui-ci.
Puis j'ai créé ma clé ED22519, durcie, en mode extrême - vu ma puissance machine, c'est-à-dire bien plus que 64 "tours de clés". J'ai transféré la clé publique sur les "anciens" serveurs, en veillant à faire privilégier celle-ci.
Et, sur les nouveaux serveurs, je ne transmets plus que la clé publique ED25519 durcie. Petit-à-petit, je fais disparaître l'usage de mes clés RSA au profit de ED25519. ;)

15 déc. 2016, 13:18

Ajout d'une information importante concernant le temps de connexion rallongé !