Non le CA est compris dans ton authorized_keys, ou dans un paramètre de conf de ton serveur SSH : TrustedUserCAKeys
Comme le soulignait notre ami un peu plus haut, c'est possible à partir de la version 5.4 d'openssh : référence
Tu n'as pas la flexibilité d'une chaîne de certification complète à la mode TLS (en particulier pas de révocation), mais tu as quand même la possibilité de configurer tous tes serveurs pour qu'ils utilisent un même CA, et de signer à posteriori toutes les clés qui ont besoin d'avoir un accès. Ce qui te fait l'économie d'un déploiement systématique sur tous tes serveurs de toute nouvelle clé.
Après une autre solution centralisée est de stocker les clés publiques de tes users dans un champs LDAP spécifique (sshPublicKey), dans la mesure bien sûr où tu utises un serveur LDAP pour l'authentication. Tu as ensuite la possiblité de gérer ces clés par un GUI de type fusiondirectory ou assimilé.Un exemple de configuration utilisant LDAP
Une autre manière centralisée, est que tes users voient hébergés leur home (ou un répertoire configuré comme hébergeant tes authorized_keys) sur un partage NFS, mais ça a d'autres inconvénient comme le partage de l'historique bash par exemple (si c'est le home que tu partages).
Ces 2 dernières solutions (NFS et LDAP) ont l'inconvénient de conditionner l'accès aux machines à leur accessibilité aux machines centrales (serveur NFS ou LDAP) et leur bonne configuration : à utiliser avec précaution surtout si on désactive l'authentification par mot de passe et qu'on a pas un accès physique ou KVM ...
[^] # Re: une CA SSH
Posté par ZeDuke . En réponse au message Sécurité - bonnes pratiques pour la gestion des clés SSH pour une infra de prod. Évalué à 1.
Non le CA est compris dans ton authorized_keys, ou dans un paramètre de conf de ton serveur SSH : TrustedUserCAKeys
Comme le soulignait notre ami un peu plus haut, c'est possible à partir de la version 5.4 d'openssh : référence
Tu n'as pas la flexibilité d'une chaîne de certification complète à la mode TLS (en particulier pas de révocation), mais tu as quand même la possibilité de configurer tous tes serveurs pour qu'ils utilisent un même CA, et de signer à posteriori toutes les clés qui ont besoin d'avoir un accès. Ce qui te fait l'économie d'un déploiement systématique sur tous tes serveurs de toute nouvelle clé.
Un exemple utilisant l'authorized_keys
Après une autre solution centralisée est de stocker les clés publiques de tes users dans un champs LDAP spécifique (sshPublicKey), dans la mesure bien sûr où tu utises un serveur LDAP pour l'authentication. Tu as ensuite la possiblité de gérer ces clés par un GUI de type fusiondirectory ou assimilé.Un exemple de configuration utilisant LDAP
Une autre manière centralisée, est que tes users voient hébergés leur home (ou un répertoire configuré comme hébergeant tes authorized_keys) sur un partage NFS, mais ça a d'autres inconvénient comme le partage de l'historique bash par exemple (si c'est le home que tu partages).
Ces 2 dernières solutions (NFS et LDAP) ont l'inconvénient de conditionner l'accès aux machines à leur accessibilité aux machines centrales (serveur NFS ou LDAP) et leur bonne configuration : à utiliser avec précaution surtout si on désactive l'authentification par mot de passe et qu'on a pas un accès physique ou KVM ...