On 6/12/21 6:36 PM, Alexandre IOOSS wrote:
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
Ça intéresse sûrement aussi l'équipe de re2o.
--
Alexandre