OpenSSH avec des clés publiques de la base de données

Est-il possible de récupérer les clés publiques d'une base de données au lieu du fichier authorized_keys?

Je voudrais utiliser une telle configuration pour gérer l'accès ssh à des choses comme les référentiels git pour plusieurs utilisateurs sans avoir à recréer le fichier authorized_keys chaque fois qu'une clé publique est modifiée ou ajoutée.

J'ai trouvé cette question en essayant d'y répondre moi-même. Après quelques recherches et expérimentations, j'ai trouvé quelques autres options pour cela. Je vais sauter la partie sur la distribution des clés comme alternative puisque Matt Simmons a couvert cela. De plus, je sais qu'il y a des moments où ce n'est pas suffisant. Par exemple, si vous êtes GitHub et devez stocker des millions de clés publiques sur un seul utilisateur, la mise à jour continue des fichiers SSH authorized_keys et leur conservation synchronisée sur des dizaines de dizaines de centaines de boîtes périphériques n'est pas faisable ou souhaitable.

Donc,

1. Tout d'abord, RedHat (et ses variantes) ont un correctif pris en charge pour OpenSSH qui ajoute les options AuthorizedKeysCommandet AuthorizedKeysCommandRunAs. Le correctif a été fusionné en amont dans openssh 6.2. Pour citer la page de manuel :

   AuthorizedKeysCommand

   Spécifie un programme à utiliser pour la recherche des clés publiques de l'utilisateur. Le programme sera appelé avec son premier argument le nom de l'utilisateur autorisé, et devrait produire sur les lignes AuthorizedKeys de sortie standard (voir AUTHORIZED_KEYS dans sshd (8)). Par défaut (ou lorsqu'il est défini sur la chaîne vide), aucune exécution de AuthorizedKeysCommand n'est effectuée. Si AuthorizedKeysCommand n'autorise pas correctement l'utilisateur, l'autorisation passe par AuthorizedKeysFile. Notez que cette option n'a d'effet que lorsque PubkeyAuthentication est activé.

   AuthorizedKeysCommandRunAs

   Spécifie l'utilisateur sous le compte duquel la AuthorizedKeysCommand est exécutée. Une chaîne vide (la valeur par défaut) signifie que l'utilisateur autorisé est utilisé.

   Dans mes expériences ce soir, j'ai découvert que cela ne fonctionnait pas en raison des politiques SELinux par défaut. Vous pouvez contourner ce problème en désactivant l'application SELinux avec setenforce 0. Étant donné que le tournage de SELinux est probablement une mauvaise idée, vous pouvez à la place générer la bonne politique. Dans mon cas, c'était aussi simple que d' essayer de se connecter avec l' AuthorizedKeysCommandoption configurée /etc/ssh/sshd_configpuis d'utiliser audit2allow -a -M local && semodule -i local.pp. Cela examine essentiellement les journaux d'audit et trouve les éléments qui ont été empêchés et génère des exceptions pour eux. Si vous êtes susceptible de contenir d'autres éléments susceptibles d'être mis sur liste blanche, vous devriez probablement en savoir plus audit2allowpour vous assurer que les nouvelles politiques sont correctes.

2. Il existe d'autres correctifs (probablement moins testés et fiables) pour ajouter des fonctionnalités similaires. Par exemple, il existe, openssh-script-auth . Vous pouvez également trouver le patch utilisé par RedHat et l'appliquer directement. Un rapide accès à Google révèle https://launchpadlibrarian.net/89063205/openssh-5.3p1-authorized-keys-command.patch et https://launchpadlibrarian.net/105938151/openssh-authorized-keys-command.patch qui sont basé sur les versions RH mais qui ont été mises à jour pour les versions plus récentes d'OpenSSH.

3. Patch OpenSSH pour effectuer des recherches de clés directement à partir de certains magasins (par exemple, comme l'ont fait GitHub et CodeBaseHQ et d'autres). GitHub n'a pas ouvert ce correctif, à ma connaissance, mais je sais que dans le passé, j'ai rencontré des versions pour la recherche de clés MySQL et PostgreSQL. J'ai essayé de les retrouver tout à l'heure mais je n'ai pas eu beaucoup de chance.

4. Il existe également des options basées sur FUSE. Par exemple, il y a LPKFuse qui vous permet de servir les clés publiques de LDAP en changeant l' AuthorizedKeysFileemplacement en un sur le système de fichiers LPKFuse. Le LPKFuse FS crée des fichiers virtuels dont le contenu est soutenu par des champs d'un serveur d'annuaire.

Dans l'ensemble, je pense que l'option # 1 est de loin la meilleure car elle est officiellement prise en charge par RedHat. De plus, il vous permet de mettre toute logique que vous aimez dans ce script (y compris parler à une base de données) dans la langue de votre choix.

OpenSSH n'a pas cette capacité, pour autant que je sache. Votre meilleur pari peut être d'avoir un script régénérant automatiquement le fichier tous les soirs (ou aussi souvent que nécessaire).

Aussi, vous voudrez peut-être voir cette question: Un système pour distribuer les clés publiques SSH

Je crois que dans les nouvelles versions d'OpenSHH, vous pouvez stocker des clés dans une entrée LDAP des utilisateurs. Si vous utilisez déjà LDAP ou AD pour la gestion des comptes, vous devriez également pouvoir en tirer parti pour la gestion des clés.