SSH n'autorise pas l'utilisation d'une clé avec des autorisations lisibles par groupe

J'ai un serveur de développement git qui se déploie sur un serveur actif lorsque la livebranche est poussée vers. Chaque utilisateur a sa propre connexion et donc le post-receivehook qui fait le déploiement en direct est exécuté sous son propre utilisateur.

Parce que je ne veux pas avoir à conserver les clés publiques des utilisateurs en tant que clés autorisées sur le serveur live distant, j'ai constitué un ensemble de clés qui appartiennent au système git à ajouter aux serveurs live distants (dans le post-receivecrochet que j'utilise $GIT_SSHpour définir la clé privée avec l' -ioption).

Mon problème est que, en raison de tous les utilisateurs qui pourraient vouloir déployer pour vivre, la clé privée du système git doit être au moins lisible par groupe et SSH n'aime vraiment pas cela.

Voici un exemple de l'erreur:

XXXX@XXXX /srv/git/identity % ssh -i id_rsa XXXXX@XXXXX
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0640 for 'id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: id_rsa

J'ai regardé autour de moi en espérant trouver quelque chose pour forcer ssh à simplement passer avec la connexion, mais je n'ai trouvé que des gens disant aveuglément que vous ne devriez tout simplement pas autoriser l'accès à autre chose qu'à un seul utilisateur.

Voici une belle façon simple et sécurisée.

Créez un nouvel utilisateur pour le transfert ssh, je l'appellerai git-sync. Créez un utilisateur similaire sur le serveur avec l'appartenance à un groupe pour le référentiel git. Ajoutez la clé publique de sync-user dans ce fichier authorized_keys2 des utilisateurs. Je suppose que les utilisateurs de git sont tous membres du gitgroup. Assurez-vous que l'utilisateur git-sync est également membre de ce groupe.

Modifiez maintenant votre fichier / etc / sudoers pour inclure une ligne comme:

%gitgroup ALL=(git-sync) NOPASSWD: /usr/bin/git

Cela permettra à tout membre du groupe gitgroup d'exécuter la commande / usr / bin / bit en tant que git-sync sans mot de passe.

Maintenant, mettez quelque chose comme ça dans votre crochet post-réception:

sudo -u git-sync /usr/bin/git push origin

Vous POUVEZ utiliser des fichiers d'identité lisibles par groupe, À MOINS QUE vous ne soyez le propriétaire de la clé. Donc, définissez simplement le fichier d'identité comme appartenant, par exemple, à l'utilisateur root, puis tous vos utilisateurs du référentiel git sont prêts à fonctionner.

Un bon avantage est que vous n'avez pas besoin de sudo - la solution sera plus simple.

Notez que cela se reproduira dans le problème d'origine si vous utilisez root pour pousser vers votre dépôt git.

Permissions 0640 for 'id_rsa' are too open.

La clé privée doit rester privée. Vous ne devez permettre à personne de le lire.

Parce que je ne veux pas avoir à conserver les clés publiques des utilisateurs en tant que clés autorisées sur le serveur live distant, j'ai constitué un ensemble de clés qui appartiennent au système git à ajouter aux serveurs live distants (dans le post-receivecrochet que j'utilise $GIT_SSHpour définir la clé privée avec l' -ioption).

1. configurer une paire de clés pour ssh du développeur vers le serveur de production

2. dans le post-receivescript de hook, essayez quelque chose comme ceci:

   if [ "live" == "$branch" ]; then
       ssh -t user@prod "git --work-tree=... --git-dir=... checkout -f"
   fi