Solution 1 :
Vous pouvez utiliser le AuthorizedKeysFile directive dans /etc/ssh/sshd_config pour ce faire. L'emplacement par défaut est .ssh/authorized_keys mais vous pouvez utiliser quelque chose qui contient un chemin absolu, par exemple
AuthorizedKeysFile /path/to/your/keyfile
les pages de manuel disent ceci
AuthorizedKeysFile
Spécifie le fichier qui contient les clés publiques pouvant être utilisées pour l'authentification de l'utilisateur. AuthorizedKeysFile peut contenir des jetons de la forme %T qui sont remplacés lors de la configuration de la connexion. Les jetons suivants sont définis :%% est remplacé par un '%' littéral, %h est remplacé par le répertoire personnel de l'utilisateur en cours d'authentification et %u est remplacé par le nom d'utilisateur de cet utilisateur. Après expansion, AuthorizedKeysFile est considéré comme un chemin absolu ou relatif au répertoire personnel de l'utilisateur. La valeur par défaut est ".ssh/authorized_keys".
Solution 2 :
Modifier :Vous devriez voter pour la réponse de @ Iain ci-dessus. Il est complet et précis. Ma réponse ci-dessous est orientée vers le partage privé touches - clairement un malentendu de ma part. Je vais laisser cette réponse ici, car je considère qu'il s'agit d'une information précieuse, mais pas pour cette question spécifique.
Je ne connais pas votre cas d'utilisation, mais je suis tenté de dire "vous vous trompez".
Chaque utilisateur doit avoir son propre kepair. De cette façon, lorsqu'un utilisateur quitte, est transféré, promu à un rôle de gestion, ou toute autre chose qui nécessite la révocation des droits, vous révoquez simplement cette clé. Cela rend également l'audit efficace beaucoup, beaucoup plus difficile.
Si vous avez besoin que les utilisateurs puissent se faire passer pour d'autres utilisateurs, ils doivent être configurés pour le faire avec sudo . Avoir des clés SSH partagées n'est normalement pas une bonne idée.
Solution 3 :
Vos administrateurs doivent utiliser une combinaison appropriée (pour votre environnement) de sudo et su .
ssh n'est pas le bon outil pour cela.
Modification contradictoire (Désolé, on dirait que j'ai souffert de la cécité des titres. Merci Zoredache) :
Mettez tous les comptes de service dans le même group , utilisez ce groupe dans le cadre d'un Match bloquer en sshd_config spécifiez le AuthorisedKeysFile vous voulez qu'ils soient tous utilisés. (Le groupe de correspondance est tel que tous les comptes ne sont pas affectés.) Ils n'auront cependant plus de fichiers AuthorisedKeysFiles individuels. openssh-lpk peut permettre aux comptes individuels d'avoir leurs propres clés en plus, mais je n'en suis pas sûr.