Question configure OpenSSH pour qu'il préfère la clé publique, retourne à un mot de passe vide


Je souhaite configurer OpenSSH 6.2p2 pour un compte de service (nous l'appellerons "serviceacct") avec un mot de passe vide qui permet d'effectuer les opérations suivantes:

  1. Commencez par essayer l'authentification par clé publique. s'il réussit, exécutez la commande forcée spécifiée dans le fichier allowed_keys.
  2. Utilisez une authentification par mot de passe vide et exécutez la commande forcée spécifiée ailleurs.

Cela donnerait essentiellement un comportement pour les utilisateurs connus et un autre pour les utilisateurs anonymes.

Dans un monde idéal, ces paramètres dans sshd_config feraient ce que je veux:

PubkeyAuthentication yes
PasswordAuthentication yes
Match User serviceacct
  PermitEmptyPasswords yes
  ForceCommand /my/program

Mais je rencontre quelques problèmes:

  1. ForceCommand /my/program remplace la commande forcée définie dans le fichier allowed_keys.
  2. L'utilisation d'un mot de passe vide semble avoir priorité sur l'authentification par clé publique.

Existe-t-il un moyen de contourner ces deux problèmes, à moins de modifier le serveur OpenSSH? Une solution évidente à laquelle je peux penser consiste à utiliser simplement deux comptes de service: un pour les utilisateurs connus utilisant uniquement l'authentification par clé publique et un autre pour les utilisateurs anonymes n'utilisant qu'une authentification par mot de passe vide. J'essaie d'éviter d'avoir deux comptes d'utilisateurs si possible.

Edit - Pourquoi j'aimerais ce comportement

Je construis un service qui héberge différents types de référentiels de systèmes de contrôle de versions (Subversion, Git et Mercurial). Pensez GitHub ou Bitbucket, mais hébergé localement (c'est la clé, car certains de nos travaux ne peuvent pas quitter notre site). On peut dire que la méthode d’accès la plus simple commune à chacun de ces systèmes de contrôle de version est SSH.

Chaque référentiel a des règles d'accès configurables pour les utilisateurs connus et anonymes. J'aimerais pouvoir prendre en charge les utilisateurs connus et anonymes utilisant la même URL pour tous les systèmes de contrôle de version. Étant donné que l'utilisateur qui héberge le référentiel fait partie de l'URL (par exemple, ssh://user@host/path), ayant deux utilisateurs différents - un pour les utilisateurs connus et un pour les utilisateurs anonymes - nécessiterait deux URL différentes.

Il y a un aspect technique que je devrais clarifier: j'utilise en fait le AuthorizedKeysCommand directive dans sshd_config, qui indique à sshd d’utiliser le résultat d’un programme externe au lieu de lire le fichier ~ / .ssh / allowed_keys.


5
2017-10-03 18:43


origine


J'ai du mal à trouver une raison pour laquelle vous voudriez peut-être faire cela. Pouvez-vous expliquer votre cas d'utilisation réel (c'est-à-dire nous dire quelque chose de plus que "je veux ce comportement" - comme Pourquoi: Quel problème pratique essayez-vous de résoudre en faisant cela)? - voretaq7
Avez-vous déjà compris cela? J'espère faire la même chose. - Mike Boers
C’est une excellente question, à laquelle j’ai du mal à trouver une réponse. Je peux comprendre pourquoi cela peut sembler insensé (permettre à un utilisateur de remplacer une commande de force définie de manière centralisée dans son propre fichier allowed_keys), cependant, cela est tout à fait logique pour un concept de compte de service. Je veux permettre aux nouveaux utilisateurs de se connecter sans mot de passe lorsqu'un script d'enregistrement serait déclenché et demanderait leur clé publique. C'est une question de 3 ans sans réponse - je crains que la réponse soit que cela ne puisse pas être fait. - starfry


Réponses: