Tu précises dans le sshd_config la commande que tu veux exécuter, il suffit qu'il retourne une ou plusieurs clés au format texte habituel (comme dans le fichier authorized_keys) ou aucune bien sûr.
La commande est soit exécutée par l'utilisateur qui tente d'ouvrir la session, soit par celui précisé dans AuthorizedKeysCommandUser. Tu peux passer des arguments au script selon le format habituel de sshd_config (%u ...).
C'est supporté par openssh depuis la 6.1, partiellement par rhel6 (qui ne connait pas AuthorizedKeysCommandUser ce qui fait penser a une intégration arrivé) et par debian depuis au moins Jessy.
IMHO l'avantage sur un parc important est la rapidité avec laquelle on peut publier ou supprimer une clé.
Typiquement avant on faisait ça avec puppet, mais le volume de changements, le nombre d'intervenants et l'exigence de validation du code fait qu'un changement met en moyenne une semaine a arriver partout. Ce qui est inadapté pour un référentiel de compte.
Nous gérons tout ça avec freeipa / sssd. Ça marche sur centos, debian, freebsd et ça permet aussi de faire du Kerberos.
Dans le cadre de ton software tu peux très bien imaginer un script qui récupère le nom de l'utilisateur courent et lance un curl. Tu peux même gérer un cache local assez simplement
[^] # Re: AuthorizedKeysCommand
Posté par Joris Dedieu (site web personnel) . En réponse au journal Gestion de clés ssh publiques (~/.ssh/authorized_keys). Évalué à 4.
Tu précises dans le sshd_config la commande que tu veux exécuter, il suffit qu'il retourne une ou plusieurs clés au format texte habituel (comme dans le fichier authorized_keys) ou aucune bien sûr.
La commande est soit exécutée par l'utilisateur qui tente d'ouvrir la session, soit par celui précisé dans AuthorizedKeysCommandUser. Tu peux passer des arguments au script selon le format habituel de sshd_config (%u ...).
C'est supporté par openssh depuis la 6.1, partiellement par rhel6 (qui ne connait pas AuthorizedKeysCommandUser ce qui fait penser a une intégration arrivé) et par debian depuis au moins Jessy.
IMHO l'avantage sur un parc important est la rapidité avec laquelle on peut publier ou supprimer une clé.
Typiquement avant on faisait ça avec puppet, mais le volume de changements, le nombre d'intervenants et l'exigence de validation du code fait qu'un changement met en moyenne une semaine a arriver partout. Ce qui est inadapté pour un référentiel de compte.
Nous gérons tout ça avec freeipa / sssd. Ça marche sur centos, debian, freebsd et ça permet aussi de faire du Kerberos.
Dans le cadre de ton software tu peux très bien imaginer un script qui récupère le nom de l'utilisateur courent et lance un curl. Tu peux même gérer un cache local assez simplement