[Re2o] Fwd: Intégration des clés publiques OpenSSH dans un arbre LDAP

Vous en avez assez de copier manuellement votre clé SSH publique ? Ce mail résume la discussion entre des membres actifs pour utiliser un LDAP comme solution de stockage des clés SSH publiques des comptes administrateurs. Problème : Le schéma LDAP par défaut sous Debian ne permet pas de stocker une clé publique SSH. Solution 1 : utiliser un certificat x509 que l'on stocke dans l'entrée "userCertificate;binary" de l'utilisateur. Cela ne permet pas d'utiliser des clés SSH ed25519 et nécessite quelques commandes OpenSSL côté client pour générer la clé. On a en plus la gestion des expirations des clés. Solution 2 : abuser d'un champ dans le LDAP et placer les clés publiques en format classique. Problème : Configurer OpenSSH pour qu'il utilise ces clés publiques. Solution 1 : Utiliser l'option "AuthorizedKeysCommand" pour qu'OpenSSH lance un script pour interroger le LDAP. Cela ajoute de la latence au SSH, et ne semble pas très robuste. Solution 2 : Utiliser l'option "AuthorizedKeysFile" et synchroniser toutes les clés publiques dans `/var/cache/ssh/authorized_keys/NOM_UTILISATEUR`. Il faut les bonnes permissions sur ces fichiers, ce qui peut mener à une calvitie prématurée lors de la mise en place. Les secondes solutions marchent et ont été déployés sur une machine virtuelle pour un test au Crans. Pour Aurore : vous pouvez peut-être abuser du champs "description" dans le profil sur re2o et l'exporter vers votre LDAP (solution temporaire). Merci à esum et Jeltz d'avoir passé du temps à réfléchir sur cette problématique. ======================================================================= Mise en place :  1. Éditer `/etc/ssh/sshd_config` et changer : ``` AuthorizedKeysFile .ssh/authorized_keys /var/cache/ssh/authorized_keys/%u ```  2. Placer un script qui va aller chercher les clés publiques dans le LDAP et les écrire dans /var/cache/ssh/authorized_keys/UTILISATEUR. Il est de bon goût de placer un fichier vide si l'utilisateur n'a pas de clé.  3. Placer un timer systemd ou un cron qui va régulièrement appeler ce script en root. On peut réduire ses capabilities, mais il a besoin de changer les propriétaires des fichiers placés, sinon openssh refusera d'utiliser ces fichiers de clés publiques. Le script en question est en cours de test côté Crans, on l'enverra probablement en réponse à ce mail quand il marchera bien. Bonne soirée, _______________________________________________ Tech.aurore mailing list -- tech.aurore(a)lists.crans.org To unsubscribe send an email to tech.aurore-leave(a)lists.crans.org